OSPF ASON Routing vs OSPF IP Routing

Hi Dimitri,

    One thing not clear to me is the co-existence of the OSPF ASON and
    IP routing. The draft does not elaborate on this topic especially -
    does an OSPF instance dedicated to ASON routing need to advertise
    LSA types 1-5 ? Is it allowed to NOT include these LSAs ?

    Would appreciate your response.

    Thanks,
    Snigdho

Envelope-to: ccamp-data@psg.com
Delivery-date: Mon, 31 Jul 2006 15:59:38 +0000
Message-ID: <44CE285C.5030707@us.fujitsu.com>
Date: Mon, 31 Jul 2006 10:57:16 -0500
From: Snigdho Bardalai <Snigdho.Bardalai@us.fujitsu.com>
Organization: Fujitsu Network Communications
User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7.8) Gecko/20050512
MIME-Version: 1.0
To: Dimitri.Papadimitriou@alcatel.be
CC: Adrian Farrel <adrian@olddog.co.uk>, ccamp@ops.ietf.org
Subject: OSPF ASON Routing vs OSPF IP Routing
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi Dimitri,

    One thing not clear to me is the co-existence of the OSPF ASON and
    IP routing. The draft does not elaborate on this topic especially -
    does an OSPF instance dedicated to ASON routing need to advertise
    LSA types 1-5 ? Is it allowed to NOT include these LSAs ?

    Would appreciate your response.

    Thanks,
    Snigdho

Envelope-to: ccamp-data@psg.com
Delivery-date: Sun, 30 Jul 2006 12:56:57 +0000
From: "Jim Jones" <jim.d.jones@alcatel.com>
To: "'Brungard, Deborah A, ALABS'" <dbrungard@att.com>
Cc: <ccamp@ops.ietf.org>, "'Adrian Farrel'" <adrian@olddog.co.uk>, "'Ross Callon'" <rcallon@juniper.net>, "'Fenner, William C \(Bill\), ALABS'" <wfenner@att.com>
Subject: RE: Response to OIF on OSPF ENNI
Date: Sun, 30 Jul 2006 07:54:38 -0500
Message-ID: <002001c6b3d7$51c8ea20$6701a8c0@ad3.ad.alcatel.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0021_01C6B3AD.68F468C0"
Thread-index: Acas0Ha/aYxFikOBS5m873SVRoVJxgAACLxQAT1f0GAAMH2cUABTvnvQ

This is a multi-part message in MIME format.

------=_NextPart_000_0021_01C6B3AD.68F468C0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Dear Deborah and Adrian,

Thank you for the detailed reply. I will upload this as a contribution to
the OIF website so we may discuss it in our upcoming meeting.

Best Regards,
Jim Jones
OIF Technical Committee Chair

  _____  

From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf
Of Brungard, Deborah A, ALABS
Sent: Friday, July 28, 2006 4:09 PM
To: Jim Jones
Cc: ccamp@ops.ietf.org; Adrian Farrel; Ross Callon; Fenner, William C
(Bill), ALABS
Subject: Response to OIF on OSPF ENNI

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-eval-
03.txt>
ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-eval-0
3.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.

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

Adrian Farrel and Deborah Brungard,

CCAMP co-chairs

------=_NextPart_000_0021_01C6B3AD.68F468C0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns:o =3D "urn:schemas-microsoft-com:office:office" xmlns:st1 =
=3D=20
"urn:schemas-microsoft-com:office:smarttags"><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1555" name=3DGENERATOR></HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft>Dear Deborah and Adrian,</DIV>
<DIV dir=3Dltr align=3Dleft>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft>Thank you for the detailed reply. I will upload =
this as a=20
contribution to the OIF website so we may discuss it in our upcoming=20
meeting.</DIV>
<DIV dir=3Dltr align=3Dleft>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft>Best Regards,</DIV>
<DIV dir=3Dltr align=3Dleft>Jim Jones</DIV>
<DIV dir=3Dltr align=3Dleft>OIF Technical Committee =
Chair</DIV> 
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
<HR tabIndex=3D-1>
From: owner-ccamp@ops.ietf.org=20
[mailto:owner-ccamp@ops.ietf.org] On Behalf Of Brungard, Deborah =
A,=20
ALABS Sent: Friday, July 28, 2006 4:09 PM To: Jim=20
Jones Cc: ccamp@ops.ietf.org; Adrian Farrel; Ross Callon; =
Fenner,=20
William C (Bill), ALABS Subject: Response to OIF on OSPF=20
ENNI </DIV>
<DIV></DIV>
<DIV dir=3Dltr align=3Dleft>
Dear Jim,
<o:p>&nbsp;</o:p>
We thank you for sending us the OIF ENNI =
document in=20
response to our request. While we appreciate the document being provided =
for=20
information, it is concerning that this document has not been previously =
shared=20
with CCAMP or the OSPF WG considering the document contains significant=20
modifications to the operation of OSPF and reflects OIF work over the =
last=20
several years. CCAMP has been cooperating on GMPLS ASON with =
ITU-T&#8217;s SG15 for=20
several years and our Design Teams included OIF participants. Even =
though a=20
reply was not requested, we are replying, as we strongly recommend that =
the=20
document not be published for public information in its current =
form.
<o:p>&nbsp;</o:p>
Of most concern to CCAMP is that it does not =
appear to be=20
aligned with ITU-T&#8217;s and CCAMP&#8217;s cooperation on RFC 4258 =
(Requirements for=20
Generalized Multi-Protocol Label Switching (GMPLS) Routing for the =
Automatically=20
Switched Optical Network (ASON)) or the to-be-published document, =
<A=20
href=3D"ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpls-ason-rou=
ting-eval-03.txt"><FONT=20
face=3D"Times New Roman"=20
size=3D3>ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpls-ason-ro=
uting-eval-03.txt</A><FONT=20
face=3D"Times New Roman" color=3D#000000 size=3D3>, which is the basis =
for our=20
on-going routing solutions work. Considering notable OIF participants =
are=20
authors of both these IETF documents (and the same participants are =
contributors=20
and the Editor for the OIF document), the non-alignment is perplexing. =
We use=20
the term &#8220;appear&#8221; as after much discussion over the CCAMP =
mailing list, we could=20
not determine the relationship with CCAMP&#8217;s documents. OIF&#8217;s =
Liaison to CCAMP,=20
Lyndon Ong, did re-affirm the statement in the document, on OIF&#8217;s =
intention to=20
provide Implementation Agreements based on ITU-T and IETF&#8217;s =
Standards. In the=20
interests of avoiding divergence, we advise not to have duplicate =
requirements=20
documents. If you do have the need for an OIF document, we suggest in =
the=20
interests of time for the three groups, IETF, ITU-T, and OIF, that you =
directly=20
reference our ASON work in the corresponding GMPLS OSPF evaluation =
sections of=20
your document. If any questions on the interpretation of IETF&#8217;s =
work, we=20
recommend that you either utilize the CCAMP mail exploder or send a=20
communication.
<o:p>&nbsp;</o:p>
Specific comments include:
<SPAN=20
style=3D"mso-fareast-font-family: 'Times New Roman'"><SPAN=20
style=3D"mso-list: Ignore"><FONT=20
size=3D3>1.<SPAN=20
style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
What is the intent of this document? Will it be published as an =

Implementation Agreement (IA)? The title indicates it will be an=20
Implementation Agreement on GMPLS OSPF extensions, but the main body of =
the=20
document is a list of issues with GMPLS OSPF. Further, your =
communication to us=20
stated the document was requirements on and use of OSPF-TE at the ENNI. =
These=20
three views seem to be inconsistent.
<FONT=20
face=3D"Times New Roman"><SPAN=20
style=3D"mso-fareast-font-family: 'Times New Roman'; =
mso-bidi-font-weight: bold"><SPAN=20
style=3D"mso-list: Ignore">2.<SPAN=20
style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
The =
list of=20
changes from the previous version (listed under the Table of Contents) =
includes=20
&#8220;removed =
&#8220;intra-carrier&#8221;=20
limitation<SPAN=20
style=3D"mso-bidi-font-weight: bold; mso-bidi-font-style: =
italic">&#8221; and the=20
inclusion of Figure 1 showing the OSPF ENNI for use between vendor =
domains and=20
between carrier domains. GMPLS OSPF-TE already supports inter-vendor =
operations.=20
IETF&#8217;s GMPLS ASON routing focus has been on the use of a =
link-state based=20
protocol to support a hierarchical routing architecture (G.7715.1) =
within a=20
carrier&#8217;s domain. Requirements for using a link state protocol as =
an=20
inter-domain protocol between carriers are significantly different. We =
strongly=20
disagree if you intend to publish this document suggesting it can be =
used as an=20
inter-carrier OSPF ENNI Implementation Agreement. Regardless of OIF=20
inter-carrier demonstrations using this protocol, it is technically =
misleading,=20
both to your member carriers and the industry, to suggest using an IETF =
IGP=20
protocol as an inter-carrier ENNI. The title of the document and the=20
introduction need to be correctly=20
scoped.<o:p></o:p>
<FONT=20
face=3D"Times New Roman"><SPAN=20
style=3D"mso-fareast-font-family: 'Times New Roman'; =
mso-bidi-font-weight: bold"><SPAN=20
style=3D"mso-list: Ignore">3.<SPAN=20
style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
<SPAN=20
style=3D"mso-bidi-font-weight: bold; mso-bidi-font-style: italic"><FONT=20
size=3D3>While OIF&#8217;s UNI is based on an =
Informational RFC,=20
RFC3474, which was not a Standards Track Document, any new extensions to =
IETF=20
protocols now need to be reviewed by IETF under the (G)MPLS process. The =
OSPF=20
protocol elements in Appendix 1 (as noted in the document) are =
experimental. If=20
OIF sees a need for such extensions, OIF needs to bring the requirements =
to the=20
IETF. In the interests of a cooperative relationship between our =
organizations,=20
we advise against publication and public demonstrations of experimental=20
extensions to IETF protocols, based on presumed issues with IETF =
protocols, with=20
no review by IETF.<o:p></o:p>
<FONT=20
face=3D"Times New Roman"><SPAN=20
style=3D"mso-fareast-font-family: 'Times New Roman'"><SPAN=20
style=3D"mso-list: Ignore">4.<SPAN=20
style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
Section =
4.1/Table 1 and=20
the statement under the table identifying issues with GMPLS identifier=20
namespaces are not correct. GMPLS identifier namespaces do meet ASON=20
requirements for namespace separation of the transport plane and control =
plane=20
(Section 5.2 and 5.3/Evaluation). As you also identified in your liaison =
that=20
the key area needing review was the support of independence of =
functional=20
component to physical location, this appears to be a key area of=20
misunderstanding on GMPLS by OIF. While some pre-standard vendor =
implementations=20
do not support this separation, it is unfortunate if this has been =
guiding your=20
ASON work as a GMPLS issue and resulting in divergence on solutions. =
Discussion=20
on the CCAMP exploder highlighted a participant&#8217;s =
misinterpretation.<SPAN=20
style=3D"mso-spacerun: yes">&nbsp; We recommend reviewing RFC3945 =
(GMPLS=20
Architecture) to understand that the key architecture difference between =
GMPLS=20
and MPLS is the decoupling of the transport plane and control plane.=20
Additionally, RFC4394, RFC4397, and RFC4258, provide a mapping to ITU=20
terminology which may be helpful reading. To avoid these =
misunderstandings, we=20
encourage you to share your requirements with us in as early of a stage =
as=20
possible to allow us to work towards a standards track=20
solution.
<FONT=20
face=3D"Times New Roman"><SPAN=20
style=3D"mso-fareast-font-family: 'Times New Roman'"><SPAN=20
style=3D"mso-list: Ignore">5.<SPAN=20
style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
Concern was =
raised that=20
even though the codepoints in the Appendix carry the disclaimer that =
they are=20
for private and experimental use, the text in Section 1.2 positions the=20
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=20
Process on these extensions, this is very presumptuous. Again, we would=20
recommend against publication of this document in the public=20
domain.
<o:p>&nbsp;</o:p>
We request an additional round of communication =
of this=20
document to the IETF before OIF approval to allow us to work with you to =
improve=20
convergence between OIF and IETF work which, we believe, will be in the =
best=20
interests of our groups and the industry.
<o:p>&nbsp;</o:p>
Best regards,
<FONT=20
color=3D#000000><st1:PersonName =
w:st=3D"on">Adrian=20
Farrel</st1:PersonName> and Deborah Brungard,
CCAMP=20
co-chairs</DIV></BODY></HTML>

------=_NextPart_000_0021_01C6B3AD.68F468C0--

Envelope-to: ccamp-data@psg.com
Delivery-date: Fri, 28 Jul 2006 21:09:32 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6B289.FD749768"
Subject: Response to OIF on OSPF ENNI
Date: Fri, 28 Jul 2006 16:08:34 -0500
Message-ID: <449B2580D802A443A923DABF3EAB82AF0C7AF87D@OCCLUST04EVS1.ugd.att.com>
Thread-Topic: Response to OIF on OSPF ENNI
Thread-Index: Acas0Ha/aYxFikOBS5m873SVRoVJxgAACLxQAT1f0GAAMH2cUA==
From: "Brungard, Deborah A, ALABS" <dbrungard@att.com>
To: "Jim Jones" <Jim.D.Jones@alcatel.com>
Cc: <ccamp@ops.ietf.org>, "Adrian Farrel" <adrian@olddog.co.uk>, "Ross Callon" <rcallon@juniper.net>, "Fenner, William C \(Bill\), ALABS" <wfenner@att.com>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6B289.FD749768
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

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

=20

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.

=20

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

=20

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.

=20

Best regards,

Adrian Farrel and Deborah Brungard,

CCAMP co-chairs

------_=_NextPart_001_01C6B289.FD749768
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns:o =3D "urn:schemas-microsoft-com:office:office" xmlns:st1 =
=3D=20
"urn:schemas-microsoft-com:office:smarttags"><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.2914" name=3DGENERATOR></HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft>
Dear Jim,
<o:p>&nbsp;</o:p>
We thank you for sending us the OIF ENNI =
document in=20
response to our request. While we appreciate the document being provided =
for=20
information, it is concerning that this document has not been previously =
shared=20
with CCAMP or the OSPF WG considering the document contains significant=20
modifications to the operation of OSPF and reflects OIF work over the =
last=20
several years. CCAMP has been cooperating on GMPLS ASON with =
ITU-T&#8217;s SG15 for=20
several years and our Design Teams included OIF participants. Even =
though a=20
reply was not requested, we are replying, as we strongly recommend that =
the=20
document not be published for public information in its current =
form.
<o:p>&nbsp;</o:p>
Of most concern to CCAMP is that it does not =
appear to be=20
aligned with ITU-T&#8217;s and CCAMP&#8217;s cooperation on RFC 4258 =
(Requirements for=20
Generalized Multi-Protocol Label Switching (GMPLS) Routing for the =
Automatically=20
Switched Optical Network (ASON)) or the to-be-published document, =
<A=20
href=3D"ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpls-ason-rou=
ting-eval-03.txt"><FONT=20
face=3D"Times New Roman"=20
size=3D3>ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpls-ason-ro=
uting-eval-03.txt</A><FONT=20
face=3D"Times New Roman" color=3D#000000 size=3D3>, which is the basis =
for our=20
on-going routing solutions work. Considering notable OIF participants =
are=20
authors of both these IETF documents (and the same participants are =
contributors=20
and the Editor for the OIF document), the non-alignment is perplexing. =
We use=20
the term &#8220;appear&#8221; as after much discussion over the CCAMP =
mailing list, we could=20
not determine the relationship with CCAMP&#8217;s documents. OIF&#8217;s =
Liaison to CCAMP,=20
Lyndon Ong, did re-affirm the statement in the document, on OIF&#8217;s =
intention to=20
provide Implementation Agreements based on ITU-T and IETF&#8217;s =
Standards. In the=20
interests of avoiding divergence, we advise not to have duplicate =
requirements=20
documents. If you do have the need for an OIF document, we suggest in =
the=20
interests of time for the three groups, IETF, ITU-T, and OIF, that you =
directly=20
reference our ASON work in the corresponding GMPLS OSPF evaluation =
sections of=20
your document. If any questions on the interpretation of IETF&#8217;s =
work, we=20
recommend that you either utilize the CCAMP mail exploder or send a=20
communication.
<o:p>&nbsp;</o:p>
Specific comments include:
<SPAN=20
style=3D"mso-fareast-font-family: 'Times New Roman'"><SPAN=20
style=3D"mso-list: Ignore"><FONT=20
size=3D3>1.<SPAN=20
style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
What is the intent of this document? Will it be published as an =

Implementation Agreement (IA)? The title indicates it will be an=20
Implementation Agreement on GMPLS OSPF extensions, but the main body of =
the=20
document is a list of issues with GMPLS OSPF. Further, your =
communication to us=20
stated the document was requirements on and use of OSPF-TE at the ENNI. =
These=20
three views seem to be inconsistent.
<FONT=20
face=3D"Times New Roman"><SPAN=20
style=3D"mso-fareast-font-family: 'Times New Roman'; =
mso-bidi-font-weight: bold"><SPAN=20
style=3D"mso-list: Ignore">2.<SPAN=20
style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
The =
list of=20
changes from the previous version (listed under the Table of Contents) =
includes=20
&#8220;removed =
&#8220;intra-carrier&#8221;=20
limitation<SPAN=20
style=3D"mso-bidi-font-weight: bold; mso-bidi-font-style: =
italic">&#8221; and the=20
inclusion of Figure 1 showing the OSPF ENNI for use between vendor =
domains and=20
between carrier domains. GMPLS OSPF-TE already supports inter-vendor =
operations.=20
IETF&#8217;s GMPLS ASON routing focus has been on the use of a =
link-state based=20
protocol to support a hierarchical routing architecture (G.7715.1) =
within a=20
carrier&#8217;s domain. Requirements for using a link state protocol as =
an=20
inter-domain protocol between carriers are significantly different. We =
strongly=20
disagree if you intend to publish this document suggesting it can be =
used as an=20
inter-carrier OSPF ENNI Implementation Agreement. Regardless of OIF=20
inter-carrier demonstrations using this protocol, it is technically =
misleading,=20
both to your member carriers and the industry, to suggest using an IETF =
IGP=20
protocol as an inter-carrier ENNI. The title of the document and the=20
introduction need to be correctly=20
scoped.<o:p></o:p>
<FONT=20
face=3D"Times New Roman"><SPAN=20
style=3D"mso-fareast-font-family: 'Times New Roman'; =
mso-bidi-font-weight: bold"><SPAN=20
style=3D"mso-list: Ignore">3.<SPAN=20
style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
<SPAN=20
style=3D"mso-bidi-font-weight: bold; mso-bidi-font-style: italic"><FONT=20
size=3D3>While OIF&#8217;s UNI is based on an =
Informational RFC,=20
RFC3474, which was not a Standards Track Document, any new extensions to =
IETF=20
protocols now need to be reviewed by IETF under the (G)MPLS process. The =
OSPF=20
protocol elements in Appendix 1 (as noted in the document) are =
experimental. If=20
OIF sees a need for such extensions, OIF needs to bring the requirements =
to the=20
IETF. In the interests of a cooperative relationship between our =
organizations,=20
we advise against publication and public demonstrations of experimental=20
extensions to IETF protocols, based on presumed issues with IETF =
protocols, with=20
no review by IETF.<o:p></o:p>
<FONT=20
face=3D"Times New Roman"><SPAN=20
style=3D"mso-fareast-font-family: 'Times New Roman'"><SPAN=20
style=3D"mso-list: Ignore">4.<SPAN=20
style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
Section =
4.1/Table 1 and=20
the statement under the table identifying issues with GMPLS identifier=20
namespaces are not correct. GMPLS identifier namespaces do meet ASON=20
requirements for namespace separation of the transport plane and control =
plane=20
(Section 5.2 and 5.3/Evaluation). As you also identified in your liaison =
that=20
the key area needing review was the support of independence of =
functional=20
component to physical location, this appears to be a key area of=20
misunderstanding on GMPLS by OIF. While some pre-standard vendor =
implementations=20
do not support this separation, it is unfortunate if this has been =
guiding your=20
ASON work as a GMPLS issue and resulting in divergence on solutions. =
Discussion=20
on the CCAMP exploder highlighted a participant&#8217;s =
misinterpretation.<SPAN=20
style=3D"mso-spacerun: yes">&nbsp; We recommend reviewing RFC3945 =
(GMPLS=20
Architecture) to understand that the key architecture difference between =
GMPLS=20
and MPLS is the decoupling of the transport plane and control plane.=20
Additionally, RFC4394, RFC4397, and RFC4258, provide a mapping to ITU=20
terminology which may be helpful reading. To avoid these =
misunderstandings, we=20
encourage you to share your requirements with us in as early of a stage =
as=20
possible to allow us to work towards a standards track=20
solution.
<FONT=20
face=3D"Times New Roman"><SPAN=20
style=3D"mso-fareast-font-family: 'Times New Roman'"><SPAN=20
style=3D"mso-list: Ignore">5.<SPAN=20
style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
Concern was =
raised that=20
even though the codepoints in the Appendix carry the disclaimer that =
they are=20
for private and experimental use, the text in Section 1.2 positions the=20
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=20
Process on these extensions, this is very presumptuous. Again, we would=20
recommend against publication of this document in the public=20
domain.
<o:p>&nbsp;</o:p>
We request an additional round of communication =
of this=20
document to the IETF before OIF approval to allow us to work with you to =
improve=20
convergence between OIF and IETF work which, we believe, will be in the =
best=20
interests of our groups and the industry.
<o:p>&nbsp;</o:p>
Best regards,
<FONT=20
color=3D#000000><st1:PersonName =
w:st=3D"on">Adrian=20
Farrel</st1:PersonName> and Deborah Brungard,
CCAMP=20
co-chairs</DIV></BODY></HTML>

------_=_NextPart_001_01C6B289.FD749768--

Envelope-to: ccamp-data@psg.com
Delivery-date: Fri, 28 Jul 2006 20:09:32 +0000
Message-ID: <016501c6b281$af9e24a0$6501a8c0@movaz.com>
From: "Igor Bryskin" <ibryskin@movaz.com>
To: <Dimitri.Papadimitriou@alcatel.be>
Cc: "Adrian Farrel" <adrian@olddog.co.uk>, <ccamp@ops.ietf.org>
Subject: Re: OSPF ASON Routing Solution
Date: Fri, 28 Jul 2006 16:09:03 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Dimitri,

Thanks for the answers. Please, see in-line.

Igor

----- Original Message ----- 
From: <Dimitri.Papadimitriou@alcatel.be>
To: "Igor Bryskin" <ibryskin@movaz.com>
Cc: "Adrian Farrel" <adrian@olddog.co.uk>; <ccamp@ops.ietf.org>
Sent: Friday, July 28, 2006 3:34 PM
Subject: Re: OSPF ASON Routing Solution

> hi igor - see in-line
>
>
>
>
> "Igor Bryskin" <ibryskin@movaz.com>
> 28/07/2006 16:36
>
>         To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
>         cc:     <ccamp@ops.ietf.org>, "Adrian Farrel"
> <adrian@olddog.co.uk>
>         Subject:        Re: OSPF ASON Routing Solution
>
>
> Dimitri,
>
> I have a couple of questions. My understanding is that your draft now
> allows
> for 1:N relationship between a routing controller (OSPF speaker) and data
> switch(es) managed by the routing controller. However, I am unclear on
> what
> to be done with the Router_Address TLV? What is the relationship between
> Router Address advertised in this TLV and local TE Router identifier(s)
> advertised,say,  in type 17 Te Link Sub-TLV(s) introduced in 5.1 of the
> draft? When we considered only 1:1 relationship between routing controller
> and data switch, we always considered TE Router ID = Router Address. Is it
> still the case? If not, do you believe that Router_Address TLV is still
> necessary and for what purposes? Should it be modified to mandate
> advertising all TE Router IDs that appear as local TE Router IDs in
> locally
> generated TE Link TLVs? Or may be you believe that Router Address is
> simply
> a local routable IP address and does not have to match any of local TE
> Router IDs?
>
> [dp] in principle, the last alternative (a router_address TLV will be then
> associated and fulfill the function of RFC 3630); i am going to
> incorporate
> this in the next rev. to elevate any potential issue
>

IB>> In other words, you are saying that information advertised in the
Router_Address TLV is not needed for the TE purposes any longer.
I agree

> [dp] please remember that the RC doesn't control "data switches" but "a
> set
> of logical control plane entity that is associated to a single data plane
> (abstract) node" - cf. eval doc.
>
> Furthermore, do you consider N:1 (more than one routing controllers
> managing
> the same data switch, e.g. a controller per layer or region) or/and M:N (
> one controller managing several data switches within one layer of
> multi-layer devices) relationships? Do you believe associating multiple
> controllers (i.e. advertising Router IDs) with the same TE Router ID
> causes
> no problem ?
>
> [dp] per eval doc "The relationship between Ri and Li is simple at any
> moment
> in time: an Li may be advertised by only one Ri at any time." hence, you
> may have multiple Ri but each would advertize an non-overlapping set
>

IB>>Note that in N:1 and M;N configurations an OSPF speaker (and co-located
TE application maintaining TED) will find out that a TE LSA containing local
Te Router ID (in other words, LSA advertising local side of a TE link) was
not generated by the speaker, rather comes from the network (from some other
OSPF speaker associated with the same TE Router ID). On the other hand the
LSA will still have a distinct Advertising Router ID, hence there will be no
ambiguity.

Igor

> Thanks,
> Igor
>
> ----- Original Message ----- 
> From: "Adrian Farrel" <adrian@olddog.co.uk>
> To: "Adrian Farrel" <adrian@olddog.co.uk>; <ccamp@ops.ietf.org>
> Sent: Wednesday, July 26, 2006 9:52 AM
> Subject: Re: OSPF ASON Routing Solution
>
>
> > Having seem some discussion of the mechanisms and debate about the
> details,
> > but no objections, we will take this as a WG document.
> >
> > Dimitri, please re-submit as
> draft-ietf-ccamp-gmpls-ason-routing-ospf-00.txt
> >
> > Thanks,
> > Adrian
> > ----- Original Message ----- 
> > From: "Adrian Farrel" <adrian@olddog.co.uk>
> > To: <ccamp@ops.ietf.org>
> > Sent: Wednesday, July 19, 2006 2:27 PM
> > Subject: Re: OSPF ASON Routing Solution
> >
> >
> > > Just a refresh in case you were travelling.
> > >
> > > I am seeking objections to this draft becoming a WG document.
> > >
> > > Adrian
> > > ----- Original Message ----- 
> > > From: "Adrian Farrel" <adrian@olddog.co.uk>
> > > To: <ccamp@ops.ietf.org>
> > > Sent: Wednesday, July 12, 2006 8:10 PM
> > > Subject: OSPF ASON Routing Solution
> > >
> > >
> > >> Hi,
> > >> On Monday in CCAMP we discussed
> > >> draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt the solutions
> draft
> > >> for OSPF in ASON routing.
> > >>
> > >> There is agreement from the OSPF WG chair that we are not treading on
> > >> toes, and the meeting seemed to say that this was pretty stable.
> > >>
> > >> So a this is a quick poll to see if anyone objects to this becoming a
> WG
> > >> draft.
> > >> NB, this is a charter item and we have an obligation to work on this
> for
> > >> the ITU-T.
> > >>
> > >> Thanks,
> > >> Adrian
> > >>
> > >> PS Note that a solution does not have to be 100% perfect to become a
> WG
> > >> draft.
> >
> >
> >
>
>
>

Envelope-to: ccamp-data@psg.com
Delivery-date: Fri, 28 Jul 2006 19:50:07 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6B27E.EE8C4364"
Subject: RE: Proposed response to OIF on OSPF ENNI
Date: Fri, 28 Jul 2006 14:49:25 -0500
Message-ID: <449B2580D802A443A923DABF3EAB82AF0C7AF7F1@OCCLUST04EVS1.ugd.att.com>
Thread-Topic: Proposed response to OIF on OSPF ENNI
Thread-Index: Acas0Ha/aYxFikOBS5m873SVRoVJxgAACLxQAT1f0GAAJp+hQAAF6NmA
From: "Brungard, Deborah A, ALABS" <dbrungard@att.com>
To: "Ong, Lyndon" <Lyong@Ciena.com>, <ccamp@ops.ietf.org>
Cc: "Adrian Farrel" <adrian@olddog.co.uk>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6B27E.EE8C4364
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

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.
=20
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.
=20
Thanks Lyndon for your mails - Good weekend-
Deborah

________________________________

From: Ong, Lyndon [mailto:Lyong@Ciena.com]=20
Sent: Friday, July 28, 2006 12:28 PM
To: Brungard, Deborah A, ALABS; ccamp@ops.ietf.org
Cc: Adrian Farrel
Subject: RE: Proposed response to OIF on OSPF ENNI

Hi Deborah, Adrian,
=20
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.
=20
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.
=20
Cheers,
=20
Lyndon

________________________________

From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On
Behalf Of Brungard, Deborah A, ALABS
Sent: Thursday, July 27, 2006 2:59 PM
To: ccamp@ops.ietf.org
Cc: Adrian Farrel
Subject: RE: Proposed response to OIF on OSPF ENNI

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)
=20
We'll target COB (EST) tomorrow for finalizing-
Deborah
=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 2nd =
proposal=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D
=20
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 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.

=20

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.

=20

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

=20

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.

=20

Best regards,

Adrian Farrel and Deborah Brungard,

CCAMP co-chairs

________________________________

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

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

=20

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

=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

------_=_NextPart_001_01C6B27E.EE8C4364
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns:o =3D "urn:schemas-microsoft-com:office:office" xmlns:st1 =
=3D=20
"urn:schemas-microsoft-com:office:smarttags"><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.2914" name=3DGENERATOR></HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft>It was a difficult balance, as we do hope as =
you say=20
that&nbsp;going forward we can be&nbsp;in closer alignment, though we =
also=20
needed to&nbsp;voice our concerns on the current =
content.</DIV>
<DIV dir=3Dltr align=3Dleft>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft>On the relative roles of OIF and IETF, you can =
either=20
discuss over the list or off-line with the co-authors on the (G)MPLS =
Change=20
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&nbsp;his =
mail&nbsp;regarding=20
our concern on OIF&nbsp;modifying an IETF protocol&nbsp;without prior=20
consultation with IETF.&nbsp;This may be an OIF document,&nbsp;but it =
will not=20
be of&nbsp;limited access to members-only, it will&nbsp;be made =
available on=20
their web site for&nbsp;non-member access as an Implementation=20
Agreement.</DIV>
<DIV dir=3Dltr align=3Dleft>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft>Thanks Lyndon for your mails - Good=20
weekend-</DIV>
<DIV dir=3Dltr align=3Dleft>Deborah</DIV> 
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
<HR tabIndex=3D-1>
From: Ong, Lyndon =
[mailto:Lyong@Ciena.com]=20
 Sent: Friday, July 28, 2006 12:28 PM To: Brungard, =
Deborah=20
A, ALABS; ccamp@ops.ietf.org Cc: Adrian =
Farrel Subject: RE:=20
Proposed response to OIF on OSPF ENNI </DIV>
<DIV></DIV>
<DIV dir=3Dltr align=3Dleft>Hi Deborah, Adrian,</DIV>
<DIV dir=3Dltr align=3Dleft>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft>I am still not happy with the tone of the =
liaison and some=20
nits (still don't see why an</DIV>
<DIV dir=3Dltr align=3Dleft>OIF document cannot reflect OIF work over the =
last several=20
years, for example),</DIV>
<DIV dir=3Dltr align=3Dleft>but it is probably best to get a liaison out =
now since OIF=20
meets next week.</DIV>
<DIV dir=3Dltr align=3Dleft>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft>Just for the record, I think many if not all of =
the=20
specific text points can be addressed, but</DIV>
<DIV dir=3Dltr align=3Dleft>disagree with a number of the broader =
conclusions,=20
particularly on the relative</DIV>
<DIV dir=3Dltr align=3Dleft>roles of OIF and IETF.</DIV>
<DIV dir=3Dltr align=3Dleft>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft>Cheers,</DIV>
<DIV dir=3Dltr align=3Dleft>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft>Lyndon</DIV> 
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
<HR tabIndex=3D-1>
From: owner-ccamp@ops.ietf.org=20
[mailto:owner-ccamp@ops.ietf.org] On Behalf Of Brungard, Deborah =
A,=20
ALABS Sent: Thursday, July 27, 2006 2:59 PM To:=20
ccamp@ops.ietf.org Cc: Adrian Farrel Subject: RE: =
Proposed=20
response to OIF on OSPF ENNI </DIV>
<DIV></DIV>
<DIV dir=3Dltr align=3Dleft>Thanks all for the discussion. I've updated to=20
include:</DIV>
<DIV dir=3Dltr align=3Dleft>- our discussion on "alignment" --&gt; amended =
to say "does=20
not appear to be aligned"</DIV>
<DIV dir=3Dltr align=3Dleft>- reworded item&nbsp;2 (OSPF ENNI for =
inter-carrier use)=20
and item 3 (on addressing, renumbered&nbsp;as item 4 in new =
proposal)&nbsp;to=20
reflect our discussion</DIV>
<DIV dir=3Dltr align=3Dleft>- added two items based on Dimitri's and =
Lyndon's exchange:=20
GMPLS Change Process (new item 3), and concern on the stability of=20
the&nbsp;identified&nbsp;extensions&nbsp;(item 5)</DIV>
<DIV dir=3Dltr align=3Dleft>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft>We'll target COB (EST) tomorrow for=20
finalizing-</DIV>
<DIV dir=3Dltr align=3Dleft>Deborah</DIV>
<DIV dir=3Dltr align=3Dleft>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 2nd=20
proposal=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D</DIV>
<DIV dir=3Dltr align=3Dleft>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft>
Dear Jim,
<o:p>&nbsp;</o:p>
We thank you for sending us the OIF ENNI =
document in=20
response to our request. While we appreciate the document being provided =
for=20
information, it is concerning that this document has not been previously =
shared=20
with CCAMP or the OSPF WG considering the document contains significant=20
modifications to the operation of OSPF and reflects OIF work over the =
last=20
several years. CCAMP has been cooperating on GMPLS ASON with =
ITU-T&#8217;s SG15 for=20
several years and our Design Teams included OIF participants. Even =
though a=20
reply was not requested, we are replying, as we strongly recommend that =
the=20
document not be published for public information in its current =
form.
<o:p>&nbsp;</o:p>
Of most concern to CCAMP is that it does not =
appear to be=20
aligned with ITU-T&#8217;s and CCAMP&#8217;s cooperation on RFC 4258 =
(Requirements for=20
Generalized Multi-Protocol Label Switching (GMPLS) Routing for the =
Automatically=20
Switched Optical Network (ASON)) or the to-be-published document, =
<A=20
href=3D"ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpls-ason-rou=
ting-eval-03.txt"><FONT=20
face=3D"Times New Roman"=20
size=3D3>ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpls-ason-ro=
uting-eval-03.txt</A><FONT=20
face=3D"Times New Roman" color=3D#000000 size=3D3>, which is the basis =
for our=20
on-going routing solutions work. Considering notable OIF participants =
are=20
authors of both these IETF documents (and the same participants are =
contributors=20
and the Editor for the OIF document), the non-alignment is perplexing. =
We use=20
the term &#8220;appear&#8221; as after much discussion over the CCAMP =
mailing list, we could=20
not determine the relationship with CCAMP&#8217;s documents. OIF&#8217;s =
Liaison to CCAMP,=20
Lyndon Ong, did re-affirm the statement in the document, on OIF&#8217;s =
intention to=20
provide Implementation Agreements based on ITU-T and IETF&#8217;s =
Standards. In the=20
interests of avoiding divergence, we advise not to have duplicate =
requirements=20
documents. If you do have the need for an OIF document, we suggest in =
the=20
interests of time for the three groups, IETF, ITU-T, and OIF, that you =
directly=20
reference our ASON work in the corresponding GMPLS OSPF evaluation =
sections of=20
your document. If any questions on the interpretation of IETF&#8217;s =
work, we=20
recommend that you either utilize the CCAMP mail exploder or send a=20
communication.
<o:p>&nbsp;</o:p>
Specific comments include:
<SPAN=20
style=3D"mso-fareast-font-family: 'Times New Roman'"><SPAN=20
style=3D"mso-list: Ignore"><FONT=20
size=3D3>1.<SPAN=20
style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
What is the intent of this document? Will it be published as an =

Implementation Agreement (IA)? The title indicates it will be an=20
Implementation Agreement on GMPLS OSPF extensions, but the main body of =
the=20
document is a list of issues with GMPLS OSPF. Further, your =
communication to us=20
stated the document was requirements on and use of OSPF-TE at the ENNI. =
These=20
three views seem to be inconsistent.
<FONT=20
face=3D"Times New Roman"><SPAN=20
style=3D"mso-fareast-font-family: 'Times New Roman'; =
mso-bidi-font-weight: bold"><SPAN=20
style=3D"mso-list: Ignore">2.<SPAN=20
style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
The =
list of=20
changes from the previous version (listed under the Table of Contents) =
includes=20
&#8220;removed =
&#8220;intra-carrier&#8221;=20
limitation<SPAN=20
style=3D"mso-bidi-font-weight: bold; mso-bidi-font-style: =
italic">&#8221; and the=20
inclusion of Figure 1 showing the OSPF ENNI for use between vendor =
domains and=20
between carrier domains. GMPLS OSPF-TE already supports inter-vendor =
operations.=20
IETF&#8217;s GMPLS ASON routing focus has been on the use of a =
link-state based=20
protocol to support a hierarchical routing architecture (G.7715.1) =
within a=20
carrier&#8217;s domain. Requirements for using a link state protocol as =
an=20
inter-domain protocol between carriers are significantly different. We =
strongly=20
disagree if you intend to publish this document suggesting it can be =
used as an=20
inter-carrier OSPF ENNI Implementation Agreement. Regardless of OIF=20
inter-carrier demonstrations using this protocol, it is technically =
misleading,=20
both to your member carriers and the industry, to suggest using an IETF =
IGP=20
protocol as an inter-carrier ENNI. The title of the document and the=20
introduction need to be correctly=20
scoped.<o:p></o:p>
<FONT=20
face=3D"Times New Roman"><SPAN=20
style=3D"mso-fareast-font-family: 'Times New Roman'; =
mso-bidi-font-weight: bold"><SPAN=20
style=3D"mso-list: Ignore">3.<SPAN=20
style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
<SPAN=20
style=3D"mso-bidi-font-weight: bold; mso-bidi-font-style: italic"><FONT=20
size=3D3>While OIF&#8217;s UNI is based on an =
Informational RFC,=20
RFC3474, which was not a Standards Track Document, any new extensions to =
IETF=20
protocols now need to be reviewed by IETF under the (G)MPLS process. The =
OSPF=20
protocol elements in Appendix 1 (as noted in the document) are =
experimental. If=20
OIF sees a need for such extensions, OIF needs to bring the requirements =
to the=20
IETF. In the interests of a cooperative relationship between our =
organizations,=20
we advise against publication and public demonstrations of experimental=20
extensions to IETF protocols, based on presumed issues with IETF =
protocols, with=20
no review by IETF.<o:p></o:p>
<FONT=20
face=3D"Times New Roman"><SPAN=20
style=3D"mso-fareast-font-family: 'Times New Roman'"><SPAN=20
style=3D"mso-list: Ignore">4.<SPAN=20
style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
Section =
4.1/Table 1 and=20
the statement under the table identifying issues with GMPLS identifier=20
namespaces are not correct. GMPLS identifier namespaces do meet ASON=20
requirements for namespace separation of the transport plane and control =
plane=20
(Section 5.2 and 5.3/Evaluation). As you also identified in your liaison =
that=20
the key area needing review was the support of independence of =
functional=20
component to physical location, this appears to be a key area of=20
misunderstanding on GMPLS by OIF. While some pre-standard vendor =
implementations=20
do not support this separation, it is unfortunate if this has been =
guiding your=20
ASON work as a GMPLS issue and resulting in divergence on solutions. =
Discussion=20
on the CCAMP exploder highlighted a participant&#8217;s =
misinterpretation.<SPAN=20
style=3D"mso-spacerun: yes">&nbsp; We recommend reviewing RFC3945 =
(GMPLS=20
Architecture) to understand that the key architecture difference between =
GMPLS=20
and MPLS is the decoupling of the transport plane and control plane.=20
Additionally, RFC4394, RFC4397, and RFC4258, provide a mapping to ITU=20
terminology which may be helpful reading. To avoid these =
misunderstandings, we=20
encourage you to share your requirements with us in as early of a stage =
as=20
possible to allow us to work towards a standards track=20
solution.
<FONT=20
face=3D"Times New Roman"><SPAN=20
style=3D"mso-fareast-font-family: 'Times New Roman'"><SPAN=20
style=3D"mso-list: Ignore">5.<SPAN=20
style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
Concern was =
raised that=20
even though the codepoints in the Appendix carry the disclaimer that =
they are=20
for private and experimental use, the text in Section 1.2 positions the=20
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=20
Process on these extensions, this is very presumptuous. Again, we would=20
recommend against publication of this document in the public=20
domain.</FONT></FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><o:p><FONT =
face=3D"Times New Roman"=20
color=3D#000000 size=3D3>&nbsp;</FONT></o:p></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT face=3D"Times =
New Roman"=20
color=3D#000000 size=3D3>We request an additional round of communication =
of this=20
document to the IETF before OIF approval to allow us to work with you to =
improve=20
convergence between OIF and IETF work which, we believe, will be in the =
best=20
interests of our groups and the industry.</FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><o:p><FONT =
face=3D"Times New Roman"=20
color=3D#000000 size=3D3>&nbsp;</FONT></o:p></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT face=3D"Times =
New Roman"=20
color=3D#000000 size=3D3>Best regards,</FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT size=3D3><FONT=20
color=3D#000000><FONT face=3D"Times New Roman"><st1:PersonName =
w:st=3D"on">Adrian=20
Farrel</st1:PersonName> and Deborah Brungard,</FONT></FONT></FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT face=3D"Times =
New Roman"=20
color=3D#000000 size=3D3>CCAMP =
co-chairs</FONT></P></FONT></SPAN></DIV><BR>
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
<HR tabIndex=3D-1>
<FONT face=3DTahoma size=3D2><B>From:</B> owner-ccamp@ops.ietf.org=20
[mailto:owner-ccamp@ops.ietf.org] <B>On Behalf Of </B>Brungard, Deborah =
A,=20
ALABS<BR><B>Sent:</B> Friday, July 21, 2006 10:38 AM<BR><B>To:</B>=20
ccamp@ops.ietf.org<BR><B>Cc:</B> Adrian Farrel<BR><B>Subject:</B> =
Proposed=20
response to OIF on OSPF ENNI<BR></FONT><BR></DIV>
<DIV></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D845551814-21072006>Hi,</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial><FONT size=3D2><FONT =
color=3D#0000ff><FONT=20
face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D845551814-21072006></SPAN></FONT></FONT></FONT></FONT>&nbsp;</DIV=
>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial><FONT =
color=3D#0000ff><FONT size=3D2><SPAN=20
class=3D845551814-21072006>We had a communication from OIF on their OSPF =
ENNI=20
specification. </SPAN>You can see the original files on =
</FONT></FONT></FONT><A=20
href=3D"http://www.olddog.co.uk/ccamp.htm"><U><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>http://www.olddog.co.uk/ccamp.htm</FONT></U></A><FONT =
face=3DArial><FONT=20
color=3D#0000ff><FONT size=3D2>.<SPAN class=3D845551814-21072006> Having =
assembled=20
comments from several people and our discussions in Montreal, we have =
put=20
together the following response.</SPAN></FONT></FONT></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial><FONT =
color=3D#0000ff><FONT size=3D2><SPAN=20
class=3D845551814-21072006></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
<DIV dir=3Dltr><SPAN class=3D845551814-21072006><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>Please comment on the list in the next =
week.</FONT></SPAN></DIV>
<DIV dir=3Dltr><SPAN class=3D845551814-21072006><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr><SPAN class=3D845551814-21072006><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>Thanks,</FONT></SPAN></DIV>
<DIV dir=3Dltr><SPAN class=3D845551814-21072006><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>Adrian and Deborah</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff=20
size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT face=3D"Times =
New Roman"=20
size=3D3><SPAN class=3D427551414-21072006>=3D =3D =3D =3D =3D =3D =3D =
=3D =3D =3D</SPAN></FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT face=3D"Times =
New Roman"=20
size=3D3>Dear Jim,</FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><o:p><FONT =
face=3D"Times New Roman"=20
size=3D3>&nbsp;</FONT></o:p></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT face=3D"Times =
New Roman"=20
size=3D3>We thank you for sending us the OIF ENNI document in response =
to our=20
request. While we appreciate the document being provided for =
information, it is=20
concerning that this document has not been previously shared with CCAMP =
or the=20
OSPF WG considering the document contains significant modifications to =
the=20
operation of OSPF and reflects OIF work over the last several years. =
CCAMP has=20
been working on GMPLS ASON for several years and our Design Teams =
include OIF=20
participants. Even though a reply was not requested, we are replying, as =
we=20
strongly recommend that the document not be published for public =
information in=20
its current form.</FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><o:p><FONT =
face=3D"Times New Roman"=20
size=3D3>&nbsp;</FONT></o:p></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT face=3D"Times =
New Roman"=20
size=3D3>Of most concern to CCAMP is that it is not aligned with RFC =
4258=20
(Requirements for Generalized Multi-Protocol Label Switching (GMPLS) =
Routing for=20
the Automatically Switched Optical Network (ASON)) or the =
to-be-published:=20
</FONT><A=20
href=3D"ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpls-ason-rou=
ting-eval-03.txt"><FONT=20
face=3D"Times New Roman"=20
size=3D3>ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpls-ason-ro=
uting-eval-03.txt</FONT></A><FONT=20
face=3D"Times New Roman" size=3D3>. Considering notable OIF participants =
are authors=20
of both these IETF documents (and the same participants are contributors =
and the=20
Editor for the OIF document), the non-alignment is perplexing. =
Considering the=20
IETF document is ready for publication, we suggest in the interests of =
time,=20
that you align your document with the IETF document. If any questions on =
the=20
interpretation of the IETF&#8217;s work, we recommend that you either =
utilize the=20
CCAMP mail exploder or send a communication.</FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><o:p><FONT =
face=3D"Times New Roman"=20
size=3D3>&nbsp;</FONT></o:p></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT face=3D"Times =
New Roman"=20
size=3D3>Specific comments include:</FONT></P>
<P class=3DMsoNormal=20
style=3D"MARGIN: 0in 0in 0pt 0.25in; TEXT-INDENT: -0.25in; mso-list: l0 =
level1 lfo1; tab-stops: list .25in"><SPAN=20
style=3D"mso-fareast-font-family: 'Times New Roman'"><SPAN=20
style=3D"mso-list: Ignore"><FONT face=3D"Times New Roman"><FONT=20
size=3D3>1.</FONT><SPAN=20
style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></FONT></SPAN></SPAN><FONT face=3D"Times New Roman" size=3D3>What =
is the=20
intent of this document? Will it be published as an Implementation =
Agreement=20
(IA)?<BR>The title indicates it will be an Implementation Agreement on =
GMPLS=20
OSPF extensions, but the main body of the document is a list of issues =
with=20
GMPLS OSPF. Further, your communication to us stated the document was=20
requirements on and use of OSPF-TE at the ENNI. These three views seem =
to be=20
inconsistent.</FONT></P>
<P class=3DMsoNormal=20
style=3D"MARGIN: 0in 0in 0pt 0.25in; TEXT-INDENT: -0.25in; mso-list: l0 =
level1 lfo1; tab-stops: list .25in"><FONT=20
face=3D"Times New Roman"><I><SPAN=20
style=3D"mso-fareast-font-family: 'Times New Roman'; =
mso-bidi-font-weight: bold"><SPAN=20
style=3D"mso-list: Ignore"><FONT size=3D3>2.</FONT><SPAN=20
style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></SPAN></SPAN></I><FONT size=3D3>The list of changes from the =
previous=20
version (listed under the Table of Contents) includes &#8220;<I><SPAN=20
style=3D"mso-bidi-font-weight: bold">removed &#8220;intra-carrier&#8221; =

limitation<SPAN=20
style=3D"mso-bidi-font-weight: bold; mso-bidi-font-style: italic"><FONT=20
size=3D3>&#8221; and the inclusion of =
Figure 1 showing the=20
OSPF ENNI for use between vendor domains and between carrier domains. =
GMPLS=20
OSPF-TE already supports inter-vendor operations. The IETF&#8217;s =
GMPLS ASON=20
routing focus has been on the use of a link-state based protocol to =
support a=20
hierarchical routing architecture (G.7715.1) within a carrier&#8217;s =
domain.=20
Requirements for using a link state protocol as an inter-domain protocol =
between=20
carriers are significantly different. We strongly disagree if you intend =
to=20
publish this document as an inter-carrier OSPF ENNI Implementation =
Agreement=20
claiming alignment with IETF RFCs without review (or agreement) by any =
of the=20
IETF Working Groups.<o:p></o:p>
<FONT=20
face=3D"Times New Roman"><SPAN=20
style=3D"mso-fareast-font-family: 'Times New Roman'"><SPAN=20
style=3D"mso-list: Ignore">3.<SPAN=20
style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
Section 4.1/Table 1 and the =
statement under=20
the table identifying issues with GMPLS identifier namespaces are not =
correct.=20
GMPLS identifier namespaces do meet ASON requirements for namespace =
separation=20
of the transport plane and control plane (Section 5.2 and =
5.3/Evaluation).=20
Perhaps you are confusing OSPF and GMPLS OSPF? As you also identified in =
your=20
liaison that the key area needing review was the support of independence =
of=20
functional component to physical location, this appears to be a key area =
of=20
misunderstanding on GMPLS. We recommend reviewing RFC3945 (GMPLS =
Architecture)=20
to understand that the key architecture difference between GMPLS and =
MPLS is the=20
decoupling of the transport plane and control plane. Additionally, =
RFC4394,=20
RFC4397, and RFC4258, provide a mapping to ITU terminology which may be =
helpful=20
reading.
<o:p>&nbsp;</o:p>
We request an additional round of communication of this =
document to the=20
IETF before approval to allow us to work with you to produce convergence =
between=20
OIF and IETF work which, we believe, will be in the best interests of =
the=20
industry.
<o:p>&nbsp;</o:p>
Best regards,
<FONT=20
face=3D"Times New Roman"><st1:PersonName w:st=3D"on">Adrian =
Farrel</st1:PersonName>=20
and Deborah Brungard,
CCAMP co-chairs</DIV></BODY></HTML>

------_=_NextPart_001_01C6B27E.EE8C4364--

Envelope-to: ccamp-data@psg.com
Delivery-date: Fri, 28 Jul 2006 19:36:15 +0000
To: "Igor Bryskin" <ibryskin@movaz.com>
Cc: "Adrian Farrel" <adrian@olddog.co.uk>, ccamp@ops.ietf.org
Subject: Re: OSPF ASON Routing Solution
MIME-Version: 1.0
Message-ID: <OF6A8D0B5C.57A44B93-ONC12571B9.0054F134-C12571B9.006B83C3@netfr.alcatel.fr>
From: Dimitri.Papadimitriou@alcatel.be
Date: Fri, 28 Jul 2006 21:34:19 +0200
Content-Type: text/plain; charset="US-ASCII"

hi igor - see in-line

"Igor Bryskin" <ibryskin@movaz.com>
28/07/2006 16:36

        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     <ccamp@ops.ietf.org>, "Adrian Farrel" 
<adrian@olddog.co.uk>
        Subject:        Re: OSPF ASON Routing Solution

Dimitri,

I have a couple of questions. My understanding is that your draft now 
allows
for 1:N relationship between a routing controller (OSPF speaker) and data
switch(es) managed by the routing controller. However, I am unclear on 
what
to be done with the Router_Address TLV? What is the relationship between
Router Address advertised in this TLV and local TE Router identifier(s)
advertised,say,  in type 17 Te Link Sub-TLV(s) introduced in 5.1 of the
draft? When we considered only 1:1 relationship between routing controller
and data switch, we always considered TE Router ID = Router Address. Is it
still the case? If not, do you believe that Router_Address TLV is still
necessary and for what purposes? Should it be modified to mandate
advertising all TE Router IDs that appear as local TE Router IDs in 
locally
generated TE Link TLVs? Or may be you believe that Router Address is 
simply
a local routable IP address and does not have to match any of local TE
Router IDs?

[dp] in principle, the last alternative (a router_address TLV will be then
associated and fulfill the function of RFC 3630); i am going to 
incorporate 
this in the next rev. to elevate any potential issue

[dp] please remember that the RC doesn't control "data switches" but "a 
set
of logical control plane entity that is associated to a single data plane 
(abstract) node" - cf. eval doc.

Furthermore, do you consider N:1 (more than one routing controllers 
managing
the same data switch, e.g. a controller per layer or region) or/and M:N (
one controller managing several data switches within one layer of
multi-layer devices) relationships? Do you believe associating multiple
controllers (i.e. advertising Router IDs) with the same TE Router ID 
causes
no problem ?

[dp] per eval doc "The relationship between Ri and Li is simple at any 
moment 
in time: an Li may be advertised by only one Ri at any time." hence, you 
may have multiple Ri but each would advertize an non-overlapping set

Thanks,
Igor

----- Original Message ----- 
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: "Adrian Farrel" <adrian@olddog.co.uk>; <ccamp@ops.ietf.org>
Sent: Wednesday, July 26, 2006 9:52 AM
Subject: Re: OSPF ASON Routing Solution

> Having seem some discussion of the mechanisms and debate about the
details,
> but no objections, we will take this as a WG document.
>
> Dimitri, please re-submit as
draft-ietf-ccamp-gmpls-ason-routing-ospf-00.txt
>
> Thanks,
> Adrian
> ----- Original Message ----- 
> From: "Adrian Farrel" <adrian@olddog.co.uk>
> To: <ccamp@ops.ietf.org>
> Sent: Wednesday, July 19, 2006 2:27 PM
> Subject: Re: OSPF ASON Routing Solution
>
>
> > Just a refresh in case you were travelling.
> >
> > I am seeking objections to this draft becoming a WG document.
> >
> > Adrian
> > ----- Original Message ----- 
> > From: "Adrian Farrel" <adrian@olddog.co.uk>
> > To: <ccamp@ops.ietf.org>
> > Sent: Wednesday, July 12, 2006 8:10 PM
> > Subject: OSPF ASON Routing Solution
> >
> >
> >> Hi,
> >> On Monday in CCAMP we discussed
> >> draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt the solutions 
draft
> >> for OSPF in ASON routing.
> >>
> >> There is agreement from the OSPF WG chair that we are not treading on
> >> toes, and the meeting seemed to say that this was pretty stable.
> >>
> >> So a this is a quick poll to see if anyone objects to this becoming a
WG
> >> draft.
> >> NB, this is a charter item and we have an obligation to work on this
for
> >> the ITU-T.
> >>
> >> Thanks,
> >> Adrian
> >>
> >> PS Note that a solution does not have to be 100% perfect to become a 
WG
> >> draft.
>
>
>

Envelope-to: ccamp-data@psg.com
Delivery-date: Fri, 28 Jul 2006 16:36:29 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6B262.C456D242"
Subject: RE: Proposed response to OIF on OSPF ENNI
Date: Fri, 28 Jul 2006 12:27:48 -0400
Message-ID: <0901D1988E815341A0103206A834DA07F1A59A@mdmxm02.ciena.com>
Thread-Topic: Proposed response to OIF on OSPF ENNI
Thread-Index: Acas0Ha/aYxFikOBS5m873SVRoVJxgAACLxQAT1f0GAAJp+hQA==
From: "Ong, Lyndon" <Lyong@Ciena.com>
To: "Brungard, Deborah A, ALABS" <dbrungard@att.com>, <ccamp@ops.ietf.org>
Cc: "Adrian Farrel" <adrian@olddog.co.uk>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6B262.C456D242
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Deborah, Adrian,
=20
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.
=20
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.
=20
Cheers,
=20
Lyndon

________________________________

From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On
Behalf Of Brungard, Deborah A, ALABS
Sent: Thursday, July 27, 2006 2:59 PM
To: ccamp@ops.ietf.org
Cc: Adrian Farrel
Subject: RE: Proposed response to OIF on OSPF ENNI

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)
=20
We'll target COB (EST) tomorrow for finalizing-
Deborah
=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 2nd =
proposal=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D
=20
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 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.

=20

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.

=20

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

=20

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.

=20

Best regards,

Adrian Farrel and Deborah Brungard,

CCAMP co-chairs

________________________________

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

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

=20

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

=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

------_=_NextPart_001_01C6B262.C456D242
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns:o =3D "urn:schemas-microsoft-com:office:office" xmlns:st1 =
=3D=20
"urn:schemas-microsoft-com:office:smarttags"><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.2912" name=3DGENERATOR></HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft>Hi Deborah, Adrian,</DIV>
<DIV dir=3Dltr align=3Dleft>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft>I am still not happy with the tone of the =
liaison and some=20
nits (still don't see why an</DIV>
<DIV dir=3Dltr align=3Dleft>OIF document cannot reflect OIF work over the =
last several=20
years, for example),</DIV>
<DIV dir=3Dltr align=3Dleft>but it is probably best to get a liaison out =
now since OIF=20
meets next week.</DIV>
<DIV dir=3Dltr align=3Dleft>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft>Just for the record, I think many if not all of =
the=20
specific text points can be addressed, but</DIV>
<DIV dir=3Dltr align=3Dleft>disagree with a number of the broader =
conclusions,=20
particularly on the relative</DIV>
<DIV dir=3Dltr align=3Dleft>roles of OIF and IETF.</DIV>
<DIV dir=3Dltr align=3Dleft>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft>Cheers,</DIV>
<DIV dir=3Dltr align=3Dleft>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft>Lyndon</DIV> 
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
<HR tabIndex=3D-1>
From: owner-ccamp@ops.ietf.org=20
[mailto:owner-ccamp@ops.ietf.org] On Behalf Of Brungard, Deborah =
A,=20
ALABS Sent: Thursday, July 27, 2006 2:59 PM To:=20
ccamp@ops.ietf.org Cc: Adrian Farrel Subject: RE: =
Proposed=20
response to OIF on OSPF ENNI </DIV>
<DIV></DIV>
<DIV dir=3Dltr align=3Dleft>Thanks all for the discussion. I've updated to=20
include:</DIV>
<DIV dir=3Dltr align=3Dleft>- our discussion on "alignment" --&gt; amended =
to say "does=20
not appear to be aligned"</DIV>
<DIV dir=3Dltr align=3Dleft>- reworded item&nbsp;2 (OSPF ENNI for =
inter-carrier use)=20
and item 3 (on addressing, renumbered&nbsp;as item 4 in new =
proposal)&nbsp;to=20
reflect our discussion</DIV>
<DIV dir=3Dltr align=3Dleft>- added two items based on Dimitri's and =
Lyndon's exchange:=20
GMPLS Change Process (new item 3), and concern on the stability of=20
the&nbsp;identified&nbsp;extensions&nbsp;(item 5)</DIV>
<DIV dir=3Dltr align=3Dleft>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft>We'll target COB (EST) tomorrow for=20
finalizing-</DIV>
<DIV dir=3Dltr align=3Dleft>Deborah</DIV>
<DIV dir=3Dltr align=3Dleft>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 2nd=20
proposal=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D</DIV>
<DIV dir=3Dltr align=3Dleft>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft>
Dear Jim,
<o:p>&nbsp;</o:p>
We thank you for sending us the OIF ENNI =
document in=20
response to our request. While we appreciate the document being provided =
for=20
information, it is concerning that this document has not been previously =
shared=20
with CCAMP or the OSPF WG considering the document contains significant=20
modifications to the operation of OSPF and reflects OIF work over the =
last=20
several years. CCAMP has been cooperating on GMPLS ASON with =
ITU-T&#8217;s SG15 for=20
several years and our Design Teams included OIF participants. Even =
though a=20
reply was not requested, we are replying, as we strongly recommend that =
the=20
document not be published for public information in its current =
form.
<o:p>&nbsp;</o:p>
Of most concern to CCAMP is that it does not =
appear to be=20
aligned with ITU-T&#8217;s and CCAMP&#8217;s cooperation on RFC 4258 =
(Requirements for=20
Generalized Multi-Protocol Label Switching (GMPLS) Routing for the =
Automatically=20
Switched Optical Network (ASON)) or the to-be-published document, =
<A=20
href=3D"ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpls-ason-rou=
ting-eval-03.txt"><FONT=20
face=3D"Times New Roman"=20
size=3D3>ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpls-ason-ro=
uting-eval-03.txt</A><FONT=20
face=3D"Times New Roman" color=3D#000000 size=3D3>, which is the basis =
for our=20
on-going routing solutions work. Considering notable OIF participants =
are=20
authors of both these IETF documents (and the same participants are =
contributors=20
and the Editor for the OIF document), the non-alignment is perplexing. =
We use=20
the term &#8220;appear&#8221; as after much discussion over the CCAMP =
mailing list, we could=20
not determine the relationship with CCAMP&#8217;s documents. OIF&#8217;s =
Liaison to CCAMP,=20
Lyndon Ong, did re-affirm the statement in the document, on OIF&#8217;s =
intention to=20
provide Implementation Agreements based on ITU-T and IETF&#8217;s =
Standards. In the=20
interests of avoiding divergence, we advise not to have duplicate =
requirements=20
documents. If you do have the need for an OIF document, we suggest in =
the=20
interests of time for the three groups, IETF, ITU-T, and OIF, that you =
directly=20
reference our ASON work in the corresponding GMPLS OSPF evaluation =
sections of=20
your document. If any questions on the interpretation of IETF&#8217;s =
work, we=20
recommend that you either utilize the CCAMP mail exploder or send a=20
communication.
<o:p>&nbsp;</o:p>
Specific comments include:
<SPAN=20
style=3D"mso-fareast-font-family: 'Times New Roman'"><SPAN=20
style=3D"mso-list: Ignore"><FONT=20
size=3D3>1.<SPAN=20
style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
What is the intent of this document? Will it be published as an =

Implementation Agreement (IA)? The title indicates it will be an=20
Implementation Agreement on GMPLS OSPF extensions, but the main body of =
the=20
document is a list of issues with GMPLS OSPF. Further, your =
communication to us=20
stated the document was requirements on and use of OSPF-TE at the ENNI. =
These=20
three views seem to be inconsistent.
<FONT=20
face=3D"Times New Roman"><SPAN=20
style=3D"mso-fareast-font-family: 'Times New Roman'; =
mso-bidi-font-weight: bold"><SPAN=20
style=3D"mso-list: Ignore">2.<SPAN=20
style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
The =
list of=20
changes from the previous version (listed under the Table of Contents) =
includes=20
&#8220;removed =
&#8220;intra-carrier&#8221;=20
limitation<SPAN=20
style=3D"mso-bidi-font-weight: bold; mso-bidi-font-style: =
italic">&#8221; and the=20
inclusion of Figure 1 showing the OSPF ENNI for use between vendor =
domains and=20
between carrier domains. GMPLS OSPF-TE already supports inter-vendor =
operations.=20
IETF&#8217;s GMPLS ASON routing focus has been on the use of a =
link-state based=20
protocol to support a hierarchical routing architecture (G.7715.1) =
within a=20
carrier&#8217;s domain. Requirements for using a link state protocol as =
an=20
inter-domain protocol between carriers are significantly different. We =
strongly=20
disagree if you intend to publish this document suggesting it can be =
used as an=20
inter-carrier OSPF ENNI Implementation Agreement. Regardless of OIF=20
inter-carrier demonstrations using this protocol, it is technically =
misleading,=20
both to your member carriers and the industry, to suggest using an IETF =
IGP=20
protocol as an inter-carrier ENNI. The title of the document and the=20
introduction need to be correctly=20
scoped.<o:p></o:p>
<FONT=20
face=3D"Times New Roman"><SPAN=20
style=3D"mso-fareast-font-family: 'Times New Roman'; =
mso-bidi-font-weight: bold"><SPAN=20
style=3D"mso-list: Ignore">3.<SPAN=20
style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
<SPAN=20
style=3D"mso-bidi-font-weight: bold; mso-bidi-font-style: italic"><FONT=20
size=3D3>While OIF&#8217;s UNI is based on an =
Informational RFC,=20
RFC3474, which was not a Standards Track Document, any new extensions to =
IETF=20
protocols now need to be reviewed by IETF under the (G)MPLS process. The =
OSPF=20
protocol elements in Appendix 1 (as noted in the document) are =
experimental. If=20
OIF sees a need for such extensions, OIF needs to bring the requirements =
to the=20
IETF. In the interests of a cooperative relationship between our =
organizations,=20
we advise against publication and public demonstrations of experimental=20
extensions to IETF protocols, based on presumed issues with IETF =
protocols, with=20
no review by IETF.<o:p></o:p>
<FONT=20
face=3D"Times New Roman"><SPAN=20
style=3D"mso-fareast-font-family: 'Times New Roman'"><SPAN=20
style=3D"mso-list: Ignore">4.<SPAN=20
style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
Section =
4.1/Table 1 and=20
the statement under the table identifying issues with GMPLS identifier=20
namespaces are not correct. GMPLS identifier namespaces do meet ASON=20
requirements for namespace separation of the transport plane and control =
plane=20
(Section 5.2 and 5.3/Evaluation). As you also identified in your liaison =
that=20
the key area needing review was the support of independence of =
functional=20
component to physical location, this appears to be a key area of=20
misunderstanding on GMPLS by OIF. While some pre-standard vendor =
implementations=20
do not support this separation, it is unfortunate if this has been =
guiding your=20
ASON work as a GMPLS issue and resulting in divergence on solutions. =
Discussion=20
on the CCAMP exploder highlighted a participant&#8217;s =
misinterpretation.<SPAN=20
style=3D"mso-spacerun: yes">&nbsp; We recommend reviewing RFC3945 =
(GMPLS=20
Architecture) to understand that the key architecture difference between =
GMPLS=20
and MPLS is the decoupling of the transport plane and control plane.=20
Additionally, RFC4394, RFC4397, and RFC4258, provide a mapping to ITU=20
terminology which may be helpful reading. To avoid these =
misunderstandings, we=20
encourage you to share your requirements with us in as early of a stage =
as=20
possible to allow us to work towards a standards track=20
solution.
<FONT=20
face=3D"Times New Roman"><SPAN=20
style=3D"mso-fareast-font-family: 'Times New Roman'"><SPAN=20
style=3D"mso-list: Ignore">5.<SPAN=20
style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
Concern was =
raised that=20
even though the codepoints in the Appendix carry the disclaimer that =
they are=20
for private and experimental use, the text in Section 1.2 positions the=20
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=20
Process on these extensions, this is very presumptuous. Again, we would=20
recommend against publication of this document in the public=20
domain.</FONT></FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><o:p><FONT =
face=3D"Times New Roman"=20
color=3D#000000 size=3D3>&nbsp;</FONT></o:p></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT face=3D"Times =
New Roman"=20
color=3D#000000 size=3D3>We request an additional round of communication =
of this=20
document to the IETF before OIF approval to allow us to work with you to =
improve=20
convergence between OIF and IETF work which, we believe, will be in the =
best=20
interests of our groups and the industry.</FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><o:p><FONT =
face=3D"Times New Roman"=20
color=3D#000000 size=3D3>&nbsp;</FONT></o:p></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT face=3D"Times =
New Roman"=20
color=3D#000000 size=3D3>Best regards,</FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT size=3D3><FONT=20
color=3D#000000><FONT face=3D"Times New Roman"><st1:PersonName =
w:st=3D"on">Adrian=20
Farrel</st1:PersonName> and Deborah Brungard,</FONT></FONT></FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT face=3D"Times =
New Roman"=20
color=3D#000000 size=3D3>CCAMP =
co-chairs</FONT></P></FONT></SPAN></DIV><BR>
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
<HR tabIndex=3D-1>
<FONT face=3DTahoma size=3D2><B>From:</B> owner-ccamp@ops.ietf.org=20
[mailto:owner-ccamp@ops.ietf.org] <B>On Behalf Of </B>Brungard, Deborah =
A,=20
ALABS<BR><B>Sent:</B> Friday, July 21, 2006 10:38 AM<BR><B>To:</B>=20
ccamp@ops.ietf.org<BR><B>Cc:</B> Adrian Farrel<BR><B>Subject:</B> =
Proposed=20
response to OIF on OSPF ENNI<BR></FONT><BR></DIV>
<DIV></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D845551814-21072006>Hi,</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial><FONT size=3D2><FONT =
color=3D#0000ff><FONT=20
face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D845551814-21072006></SPAN></FONT></FONT></FONT></FONT>&nbsp;</DIV=
>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial><FONT =
color=3D#0000ff><FONT size=3D2><SPAN=20
class=3D845551814-21072006>We had a communication from OIF on their OSPF =
ENNI=20
specification. </SPAN>You can see the original files on =
</FONT></FONT></FONT><A=20
href=3D"http://www.olddog.co.uk/ccamp.htm"><U><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>http://www.olddog.co.uk/ccamp.htm</FONT></U></A><FONT =
face=3DArial><FONT=20
color=3D#0000ff><FONT size=3D2>.<SPAN class=3D845551814-21072006> Having =
assembled=20
comments from several people and our discussions in Montreal, we have =
put=20
together the following response.</SPAN></FONT></FONT></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial><FONT =
color=3D#0000ff><FONT size=3D2><SPAN=20
class=3D845551814-21072006></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
<DIV dir=3Dltr><SPAN class=3D845551814-21072006><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>Please comment on the list in the next =
week.</FONT></SPAN></DIV>
<DIV dir=3Dltr><SPAN class=3D845551814-21072006><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr><SPAN class=3D845551814-21072006><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>Thanks,</FONT></SPAN></DIV>
<DIV dir=3Dltr><SPAN class=3D845551814-21072006><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>Adrian and Deborah</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff=20
size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT face=3D"Times =
New Roman"=20
size=3D3><SPAN class=3D427551414-21072006>=3D =3D =3D =3D =3D =3D =3D =
=3D =3D =3D</SPAN></FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT face=3D"Times =
New Roman"=20
size=3D3>Dear Jim,</FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><o:p><FONT =
face=3D"Times New Roman"=20
size=3D3>&nbsp;</FONT></o:p></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT face=3D"Times =
New Roman"=20
size=3D3>We thank you for sending us the OIF ENNI document in response =
to our=20
request. While we appreciate the document being provided for =
information, it is=20
concerning that this document has not been previously shared with CCAMP =
or the=20
OSPF WG considering the document contains significant modifications to =
the=20
operation of OSPF and reflects OIF work over the last several years. =
CCAMP has=20
been working on GMPLS ASON for several years and our Design Teams =
include OIF=20
participants. Even though a reply was not requested, we are replying, as =
we=20
strongly recommend that the document not be published for public =
information in=20
its current form.</FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><o:p><FONT =
face=3D"Times New Roman"=20
size=3D3>&nbsp;</FONT></o:p></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT face=3D"Times =
New Roman"=20
size=3D3>Of most concern to CCAMP is that it is not aligned with RFC =
4258=20
(Requirements for Generalized Multi-Protocol Label Switching (GMPLS) =
Routing for=20
the Automatically Switched Optical Network (ASON)) or the =
to-be-published:=20
</FONT><A=20
href=3D"ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpls-ason-rou=
ting-eval-03.txt"><FONT=20
face=3D"Times New Roman"=20
size=3D3>ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpls-ason-ro=
uting-eval-03.txt</FONT></A><FONT=20
face=3D"Times New Roman" size=3D3>. Considering notable OIF participants =
are authors=20
of both these IETF documents (and the same participants are contributors =
and the=20
Editor for the OIF document), the non-alignment is perplexing. =
Considering the=20
IETF document is ready for publication, we suggest in the interests of =
time,=20
that you align your document with the IETF document. If any questions on =
the=20
interpretation of the IETF&#8217;s work, we recommend that you either =
utilize the=20
CCAMP mail exploder or send a communication.</FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><o:p><FONT =
face=3D"Times New Roman"=20
size=3D3>&nbsp;</FONT></o:p></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT face=3D"Times =
New Roman"=20
size=3D3>Specific comments include:</FONT></P>
<P class=3DMsoNormal=20
style=3D"MARGIN: 0in 0in 0pt 0.25in; TEXT-INDENT: -0.25in; mso-list: l0 =
level1 lfo1; tab-stops: list .25in"><SPAN=20
style=3D"mso-fareast-font-family: 'Times New Roman'"><SPAN=20
style=3D"mso-list: Ignore"><FONT face=3D"Times New Roman"><FONT=20
size=3D3>1.</FONT><SPAN=20
style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></FONT></SPAN></SPAN><FONT face=3D"Times New Roman" size=3D3>What =
is the=20
intent of this document? Will it be published as an Implementation =
Agreement=20
(IA)?<BR>The title indicates it will be an Implementation Agreement on =
GMPLS=20
OSPF extensions, but the main body of the document is a list of issues =
with=20
GMPLS OSPF. Further, your communication to us stated the document was=20
requirements on and use of OSPF-TE at the ENNI. These three views seem =
to be=20
inconsistent.</FONT></P>
<P class=3DMsoNormal=20
style=3D"MARGIN: 0in 0in 0pt 0.25in; TEXT-INDENT: -0.25in; mso-list: l0 =
level1 lfo1; tab-stops: list .25in"><FONT=20
face=3D"Times New Roman"><I><SPAN=20
style=3D"mso-fareast-font-family: 'Times New Roman'; =
mso-bidi-font-weight: bold"><SPAN=20
style=3D"mso-list: Ignore"><FONT size=3D3>2.</FONT><SPAN=20
style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></SPAN></SPAN></I><FONT size=3D3>The list of changes from the =
previous=20
version (listed under the Table of Contents) includes &#8220;<I><SPAN=20
style=3D"mso-bidi-font-weight: bold">removed &#8220;intra-carrier&#8221; =

limitation<SPAN=20
style=3D"mso-bidi-font-weight: bold; mso-bidi-font-style: italic"><FONT=20
size=3D3>&#8221; and the inclusion of =
Figure 1 showing the=20
OSPF ENNI for use between vendor domains and between carrier domains. =
GMPLS=20
OSPF-TE already supports inter-vendor operations. The IETF&#8217;s =
GMPLS ASON=20
routing focus has been on the use of a link-state based protocol to =
support a=20
hierarchical routing architecture (G.7715.1) within a carrier&#8217;s =
domain.=20
Requirements for using a link state protocol as an inter-domain protocol =
between=20
carriers are significantly different. We strongly disagree if you intend =
to=20
publish this document as an inter-carrier OSPF ENNI Implementation =
Agreement=20
claiming alignment with IETF RFCs without review (or agreement) by any =
of the=20
IETF Working Groups.<o:p></o:p>
<FONT=20
face=3D"Times New Roman"><SPAN=20
style=3D"mso-fareast-font-family: 'Times New Roman'"><SPAN=20
style=3D"mso-list: Ignore">3.<SPAN=20
style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
Section 4.1/Table 1 and the =
statement under=20
the table identifying issues with GMPLS identifier namespaces are not =
correct.=20
GMPLS identifier namespaces do meet ASON requirements for namespace =
separation=20
of the transport plane and control plane (Section 5.2 and =
5.3/Evaluation).=20
Perhaps you are confusing OSPF and GMPLS OSPF? As you also identified in =
your=20
liaison that the key area needing review was the support of independence =
of=20
functional component to physical location, this appears to be a key area =
of=20
misunderstanding on GMPLS. We recommend reviewing RFC3945 (GMPLS =
Architecture)=20
to understand that the key architecture difference between GMPLS and =
MPLS is the=20
decoupling of the transport plane and control plane. Additionally, =
RFC4394,=20
RFC4397, and RFC4258, provide a mapping to ITU terminology which may be =
helpful=20
reading.
<o:p>&nbsp;</o:p>
We request an additional round of communication of this =
document to the=20
IETF before approval to allow us to work with you to produce convergence =
between=20
OIF and IETF work which, we believe, will be in the best interests of =
the=20
industry.
<o:p>&nbsp;</o:p>
Best regards,
<FONT=20
face=3D"Times New Roman"><st1:PersonName w:st=3D"on">Adrian =
Farrel</st1:PersonName>=20
and Deborah Brungard,
CCAMP co-chairs</DIV></BODY></HTML>

------_=_NextPart_001_01C6B262.C456D242--

Envelope-to: ccamp-data@psg.com
Delivery-date: Fri, 28 Jul 2006 14:39:06 +0000
Message-ID: <00f801c6b253$40a01320$6501a8c0@movaz.com>
From: "Igor Bryskin" <ibryskin@movaz.com>
To: <dimitri.papadimitriou@alcatel.be>
Cc: <ccamp@ops.ietf.org>, "Adrian Farrel" <adrian@olddog.co.uk>
Subject: Re: OSPF ASON Routing Solution
Date: Fri, 28 Jul 2006 10:36:38 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Dimitri,

I have a couple of questions. My understanding is that your draft now allows
for 1:N relationship between a routing controller (OSPF speaker) and data
switch(es) managed by the routing controller. However, I am unclear on what
to be done with the Router_Address TLV? What is the relationship between
Router Address advertised in this TLV and local TE Router identifier(s)
advertised,say,  in type 17 Te Link Sub-TLV(s) introduced in 5.1 of the
draft? When we considered only 1:1 relationship between routing controller
and data switch, we always considered TE Router ID = Router Address. Is it
still the case? If not, do you believe that Router_Address TLV is still
necessary and for what purposes? Should it be modified to mandate
advertising all TE Router IDs that appear as local TE Router IDs in locally
generated TE Link TLVs? Or may be you believe that Router Address is simply
a local routable IP address and does not have to match any of local TE
Router IDs?

Furthermore, do you consider N:1 (more than one routing controllers managing
the same data switch, e.g. a controller per layer or region) or/and M:N (
one controller managing several data switches within one layer of
multi-layer devices) relationships? Do you believe associating multiple
controllers (i.e. advertising Router IDs) with the same TE Router ID causes
no problem ?

Thanks,
Igor

----- Original Message ----- 
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: "Adrian Farrel" <adrian@olddog.co.uk>; <ccamp@ops.ietf.org>
Sent: Wednesday, July 26, 2006 9:52 AM
Subject: Re: OSPF ASON Routing Solution

> Having seem some discussion of the mechanisms and debate about the
details,
> but no objections, we will take this as a WG document.
>
> Dimitri, please re-submit as
draft-ietf-ccamp-gmpls-ason-routing-ospf-00.txt
>
> Thanks,
> Adrian
> ----- Original Message ----- 
> From: "Adrian Farrel" <adrian@olddog.co.uk>
> To: <ccamp@ops.ietf.org>
> Sent: Wednesday, July 19, 2006 2:27 PM
> Subject: Re: OSPF ASON Routing Solution
>
>
> > Just a refresh in case you were travelling.
> >
> > I am seeking objections to this draft becoming a WG document.
> >
> > Adrian
> > ----- Original Message ----- 
> > From: "Adrian Farrel" <adrian@olddog.co.uk>
> > To: <ccamp@ops.ietf.org>
> > Sent: Wednesday, July 12, 2006 8:10 PM
> > Subject: OSPF ASON Routing Solution
> >
> >
> >> Hi,
> >> On Monday in CCAMP we discussed
> >> draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt the solutions draft
> >> for OSPF in ASON routing.
> >>
> >> There is agreement from the OSPF WG chair that we are not treading on
> >> toes, and the meeting seemed to say that this was pretty stable.
> >>
> >> So a this is a quick poll to see if anyone objects to this becoming a
WG
> >> draft.
> >> NB, this is a charter item and we have an obligation to work on this
for
> >> the ITU-T.
> >>
> >> Thanks,
> >> Adrian
> >>
> >> PS Note that a solution does not have to be 100% perfect to become a WG
> >> draft.
>
>
>

Envelope-to: ccamp-data@psg.com
Delivery-date: Thu, 27 Jul 2006 23:09:54 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6B1D1.A3CA8C2E"
Subject: RE: Alignment of OIF routing requirements with CCAMP ASON routing requirements [Was : Proposed response to OIF on OSPF ENNI]
Date: Thu, 27 Jul 2006 18:06:07 -0500
Message-ID: <A1A52203CA93634BA1748887B9993AEA03098576@USNVEX1.tellabs-west.tellabsinc.net>
Thread-Topic: Alignment of OIF routing requirements with CCAMP ASON routing requirements [Was : Proposed response to OIF on OSPF ENNI]
Thread-Index: Acaws+RLrPZOOzAyQNKZ1mKth3uWiQA+ggyQ
From: "Sadler, Jonathan B." <Jonathan.Sadler@tellabs.com>
To: "Adrian Farrel" <adrian@olddog.co.uk>
Cc: <ccamp@ops.ietf.org>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6B1D1.A3CA8C2E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="us-ascii"

Hi Adrian,

=20

Sorry for not responding sooner -- I was out with the family at the
amusement park the past two days.  Something about hurtling down the
hill of a rollercoaster helps put things into perspective.

=20

My comments so far were intended only as a constructive and informative
contribution to the IETF process.  If I have offended, I offer my
apology.

=20

When you and Deborah request my opinion whether these documents meets
the needs of the OIF, I must interpret it as a request for my opinion if
these documents are aligned with the ITU's requirements and architecture
for ASON.  This stems from OIF motions to follow the ITU's requirements
and architecture documents.  All comments have been made from this
vantage point.

=20

Judgment of alignment with the ITU's requirements is something that can
only take place within the ITU after reasoned and informed debate.  It
is not something that an individual can say on the behalf of the ITU
without authorization.  In fact, this is something that Q14/15 discussed
in its liaison to CCAMP dated Nov 2005, well before the IESG review and
publication date of the CCAMP eval document.  The text of that liaison
(found at https://datatracker.ietf.org/documents/LIAISON/file210.doc)
reads:

=20

"In general, it is requested that CCAMP notify Q.14/15 when ASON-related
drafts are nearing completion.  While some members of Q.14/15 have
participated in CCAMP activities such as joint design teams, their
participation does not constitute agreement of Q.14/15 itself with the
output. We strongly suggest that CCAMP liaises such documents to ITU for
review prior to publishing as an RFC (for example, just preceding or
following WG Last Call), in order to ensure continued mutual
understanding of the requirements."

=20

Given this statement from the ITU, I do not feel it is my place to state
whether or not the document is in alignment.  All I can say is there is
potential evidence may not be and the documents should be liaised for
comment/agreement before it can be said they are in alignment.

=20

Jonathan Sadler

=20

-----Original Message-----

From: Adrian Farrel [mailto:adrian@olddog.co.uk]=20

Sent: Wednesday, July 26, 2006 7:59 AM

To: Sadler, Jonathan B.

Cc: ccamp@ops.ietf.org

Subject: Alignment of OIF routing requirements with CCAMP ASON routing
requirements [Was : Proposed response to OIF on OSPF ENNI]

=20

Jon,

=20

Deborah asked your opinion on whether CCAMP's ASON requirements document
and=20

evaluation document meet the needs of OIF. You say you are unable to
make=20

this personal evaluation. That is surprising. One would expect that you=20

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

OSPF (Restructured)"

- the editor of G.7715.

=20

Lyndon has stated that he believes there is good alignment and that the=20

objective is alignment.

=20

Will you state your opinion?

=20

Thanks,

Adrian

=20

=20

=20

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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_01C6B1D1.A3CA8C2E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset="us-ascii"

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" xmlns=3D"http://ww=
w=2Ew3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<o:SmartTagType namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"City" downloadurl=3D"http://www.5iamas-microsoft-com:office:smartt=
ags"/>
<o:SmartTagType namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"place" downloadurl=3D"http://www.5iantlavalamp.com/"/>
<o:SmartTagType namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"PersonName" downloadurl=3D"http://www.microsoft.com"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"MS Mincho";
	panose-1:2 2 6 9 4 2 5 8 3 4;}
@font-face
	{font-family:"\@MS Mincho";
	panose-1:2 2 6 9 4 2 5 8 3 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
p=2EMsoPlainText, li.MsoPlainText, div.MsoPlainText
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 77.95pt 1.0in 77.95pt;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span style=3D'=
font-size:
10.0pt'>Hi Adrian,<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span style=3D'=
font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span style=3D'=
font-size:
10.0pt'>Sorry for not responding sooner -- I was out with the family at the
amusement park the past two days.&nbsp; Something about hurtling down the h=
ill
of a rollercoaster helps put things into perspective.<o:p></o:p></span></fo=
nt></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span style=3D'=
font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span style=3D'=
font-size:
10.0pt'>My comments so far were intended only as a constructive and informa=
tive
contribution to the IETF process.&nbsp; If I have offended, I offer my apol=
ogy.<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span style=3D'=
font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span style=3D'=
font-size:
10.0pt'>When you and Deborah request my opinion whether these documents mee=
ts
the needs of the OIF, I must interpret it as a request for my opinion if th=
ese
documents are aligned with the ITU's requirements and architecture for
ASON.&nbsp; This stems from OIF motions to follow the ITU's requirements and
architecture documents.&nbsp; All comments have been made from this vantage
point.<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span style=3D'=
font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

Judgment of alignment with the ITU's requirements is something that=
 can
only take place within the ITU after reasoned and informed debate.&nbsp; It=
 is
not something that an individual can say on the behalf of the ITU without
authorization. &nbsp;In fact, this is something that Q14/15 discussed in its
liaison to CCAMP dated Nov 2005, well before the IESG review and publication
date of the CCAMP eval document.&nbsp; The text of that liaison (found at <a
href=3D"https://datatracker.ietf.org/documents/LIAISON/file210.doc">https:/=
/datatracker.ietf.org/documents/LIAISON/file210.doc</a>)
reads:<o:p></o:p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span style=3D'=
font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

&quot;In general, it is requested that CCAMP not=
ify
Q=2E14/15 when ASON-related drafts are nearing completion.&nbsp; While some
members of Q.14/15 have participated in CCAMP activities such as joint desi=
gn
teams, their participation does not constitute agreement of Q.14/15 itself =
with
the output. We strongly suggest that CCAMP liaises such documents to ITU for
review prior to publishing as an RFC (for example, just preceding or follow=
ing
WG Last Call), in order to ensure continued mutual understanding of the
requirements.&quot;<o:p></o:p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span style=3D'=
font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span style=3D'=
font-size:
10.0pt'>Given this statement from the ITU, I do not feel it is my place to =
state
whether or not the document is in alignment.&nbsp; All I can say is there i=
s potential
evidence may not be and the documents should be liaised for comment/agreeme=
nt
before it can be said they are in alignment.<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span style=3D'=
font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><st1:PersonName w:st=3D"on"><font size=3D2 face=3D"=
Courier New"><span
 style=3D'font-size:10.0pt'>Jonathan Sadler</span></font></st1:PersonName><=
o:p></o:p></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span style=3D'=
font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span style=3D'=
font-size:
10.0pt'>-----Original Message-----<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span style=3D'=
font-size:
10.0pt'>From: Adrian Farrel [mailto:adrian@olddog.co.uk] <o:p></o:p></span>=
</font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span style=3D'=
font-size:
10.0pt'>Sent: Wednesday, July 26, 2006 7:59 AM<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span style=3D'=
font-size:
10.0pt'>To: Sadler, Jonathan B.<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span style=3D'=
font-size:
10.0pt'>Cc: ccamp@ops.ietf.org<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span style=3D'=
font-size:
10.0pt'>Subject: Alignment of OIF routing requirements with CCAMP ASON rout=
ing
requirements [Was : Proposed response to OIF on OSPF ENNI]<o:p></o:p></span=
></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span style=3D'=
font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span style=3D'=
font-size:
10.0pt'>Jon,<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span style=3D'=
font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span style=3D'=
font-size:
10.0pt'>Deborah asked your opinion on whether CCAMP's ASON requirements
document and <o:p></o:p></span></font></p>

evaluation document meet the needs of OIF. You say you are unable to
make <o:p></o:p>

this personal evaluation. That is surprising. One would expect that=
 you
<o:p></o:p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span style=3D'=
font-size:
10.0pt'>would have some sort of clue as:<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span style=3D'=
font-size:
10.0pt'>- a named contributer and member of the design team for RFC4258<o:p=
></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span style=3D'=
font-size:
10.0pt'>- an author of draft-ietf-ccamp-gmpls-ason-routing-eval<o:p></o:p><=
/span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span style=3D'=
font-size:
10.0pt'>- an active participant in CCAMP where these two documents were last
called<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span style=3D'=
font-size:
10.0pt'>- a named contributer to &quot;Draft OIF Specification for E-NNI
Routing using <o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span style=3D'=
font-size:
10.0pt'>OSPF (Restructured)&quot;<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span style=3D'=
font-size:
10.0pt'>- the editor of G.7715.<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span style=3D'=
font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span style=3D'=
font-size:
10.0pt'>Lyndon has stated that he believes there is good alignment and that=
 the
<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span style=3D'=
font-size:
10.0pt'>objective is alignment.<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span style=3D'=
font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span style=3D'=
font-size:
10.0pt'>Will you state your opinion?<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span style=3D'=
font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span style=3D'=
font-size:
10.0pt'>Thanks,<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><st1:City w:st=3D"on"><st1:place w:st=3D"on"><font =
size=3D2
  face=3D"Courier New"><span style=3D'font-size:10.0pt'>Adrian</span></font=
></st1:place></st1:City><o:p></o:p></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span style=3D'=
font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span style=3D'=
font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span style=3D'=
font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

</div>

<pre>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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
</pre></body>

</html>

------_=_NextPart_001_01C6B1D1.A3CA8C2E--

Envelope-to: ccamp-data@psg.com
Delivery-date: Thu, 27 Jul 2006 22:01:03 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6B1C7.EF6A2202"
Subject: RE: Proposed response to OIF on OSPF ENNI
Date: Thu, 27 Jul 2006 16:59:29 -0500
Message-ID: <449B2580D802A443A923DABF3EAB82AF0C7AF28F@OCCLUST04EVS1.ugd.att.com>
Thread-Topic: Proposed response to OIF on OSPF ENNI
Thread-Index: Acas0Ha/aYxFikOBS5m873SVRoVJxgAACLxQAT1f0GA=
From: "Brungard, Deborah A, ALABS" <dbrungard@att.com>
To: <ccamp@ops.ietf.org>
Cc: "Adrian Farrel" <adrian@olddog.co.uk>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6B1C7.EF6A2202
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

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)
=20
We'll target COB (EST) tomorrow for finalizing-
Deborah
=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 2nd =
proposal=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D
=20
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 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.

=20

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.

=20

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

=20

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.

=20

Best regards,

Adrian Farrel and Deborah Brungard,

CCAMP co-chairs

________________________________

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

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

=20

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

=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

------_=_NextPart_001_01C6B1C7.EF6A2202
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns:o =3D "urn:schemas-microsoft-com:office:office" xmlns:st1 =
=3D=20
"urn:schemas-microsoft-com:office:smarttags"><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.2914" name=3DGENERATOR></HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft>Thanks all for the discussion. I've updated to=20
include:</DIV>
<DIV dir=3Dltr align=3Dleft>- our discussion on "alignment" --&gt; amended =
to say "does=20
not appear to be aligned"</DIV>
<DIV dir=3Dltr align=3Dleft>- reworded item&nbsp;2 (OSPF ENNI for =
inter-carrier use)=20
and item 3 (on addressing, renumbered&nbsp;as item 4 in new =
proposal)&nbsp;to=20
reflect our discussion</DIV>
<DIV dir=3Dltr align=3Dleft>- added two items based on Dimitri's and =
Lyndon's exchange:=20
GMPLS Change Process (new item 3), and concern on the stability of=20
the&nbsp;identified&nbsp;extensions&nbsp;(item 5)</DIV>
<DIV dir=3Dltr align=3Dleft>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft>We'll target COB (EST) tomorrow for=20
finalizing-</DIV>
<DIV dir=3Dltr align=3Dleft>Deborah</DIV>
<DIV dir=3Dltr align=3Dleft>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 2nd=20
proposal=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D</DIV>
<DIV dir=3Dltr align=3Dleft>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft>
Dear Jim,
<o:p>&nbsp;</o:p>
We thank you for sending us the OIF ENNI =
document in=20
response to our request. While we appreciate the document being provided =
for=20
information, it is concerning that this document has not been previously =
shared=20
with CCAMP or the OSPF WG considering the document contains significant=20
modifications to the operation of OSPF and reflects OIF work over the =
last=20
several years. CCAMP has been cooperating on GMPLS ASON with =
ITU-T&#8217;s SG15 for=20
several years and our Design Teams included OIF participants. Even =
though a=20
reply was not requested, we are replying, as we strongly recommend that =
the=20
document not be published for public information in its current =
form.
<o:p>&nbsp;</o:p>
Of most concern to CCAMP is that it does not =
appear to be=20
aligned with ITU-T&#8217;s and CCAMP&#8217;s cooperation on RFC 4258 =
(Requirements for=20
Generalized Multi-Protocol Label Switching (GMPLS) Routing for the =
Automatically=20
Switched Optical Network (ASON)) or the to-be-published document, =
<A=20
href=3D"ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpls-ason-rou=
ting-eval-03.txt"><FONT=20
face=3D"Times New Roman"=20
size=3D3>ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpls-ason-ro=
uting-eval-03.txt</A><FONT=20
face=3D"Times New Roman" color=3D#000000 size=3D3>, which is the basis =
for our=20
on-going routing solutions work. Considering notable OIF participants =
are=20
authors of both these IETF documents (and the same participants are =
contributors=20
and the Editor for the OIF document), the non-alignment is perplexing. =
We use=20
the term &#8220;appear&#8221; as after much discussion over the CCAMP =
mailing list, we could=20
not determine the relationship with CCAMP&#8217;s documents. OIF&#8217;s =
Liaison to CCAMP,=20
Lyndon Ong, did re-affirm the statement in the document, on OIF&#8217;s =
intention to=20
provide Implementation Agreements based on ITU-T and IETF&#8217;s =
Standards. In the=20
interests of avoiding divergence, we advise not to have duplicate =
requirements=20
documents. If you do have the need for an OIF document, we suggest in =
the=20
interests of time for the three groups, IETF, ITU-T, and OIF, that you =
directly=20
reference our ASON work in the corresponding GMPLS OSPF evaluation =
sections of=20
your document. If any questions on the interpretation of IETF&#8217;s =
work, we=20
recommend that you either utilize the CCAMP mail exploder or send a=20
communication.
<o:p>&nbsp;</o:p>
Specific comments include:
<SPAN=20
style=3D"mso-fareast-font-family: 'Times New Roman'"><SPAN=20
style=3D"mso-list: Ignore"><FONT=20
size=3D3>1.<SPAN=20
style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
What is the intent of this document? Will it be published as an =

Implementation Agreement (IA)? The title indicates it will be an=20
Implementation Agreement on GMPLS OSPF extensions, but the main body of =
the=20
document is a list of issues with GMPLS OSPF. Further, your =
communication to us=20
stated the document was requirements on and use of OSPF-TE at the ENNI. =
These=20
three views seem to be inconsistent.
<FONT=20
face=3D"Times New Roman"><SPAN=20
style=3D"mso-fareast-font-family: 'Times New Roman'; =
mso-bidi-font-weight: bold"><SPAN=20
style=3D"mso-list: Ignore">2.<SPAN=20
style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
The =
list of=20
changes from the previous version (listed under the Table of Contents) =
includes=20
&#8220;removed =
&#8220;intra-carrier&#8221;=20
limitation<SPAN=20
style=3D"mso-bidi-font-weight: bold; mso-bidi-font-style: =
italic">&#8221; and the=20
inclusion of Figure 1 showing the OSPF ENNI for use between vendor =
domains and=20
between carrier domains. GMPLS OSPF-TE already supports inter-vendor =
operations.=20
IETF&#8217;s GMPLS ASON routing focus has been on the use of a =
link-state based=20
protocol to support a hierarchical routing architecture (G.7715.1) =
within a=20
carrier&#8217;s domain. Requirements for using a link state protocol as =
an=20
inter-domain protocol between carriers are significantly different. We =
strongly=20
disagree if you intend to publish this document suggesting it can be =
used as an=20
inter-carrier OSPF ENNI Implementation Agreement. Regardless of OIF=20
inter-carrier demonstrations using this protocol, it is technically =
misleading,=20
both to your member carriers and the industry, to suggest using an IETF =
IGP=20
protocol as an inter-carrier ENNI. The title of the document and the=20
introduction need to be correctly=20
scoped.<o:p></o:p>
<FONT=20
face=3D"Times New Roman"><SPAN=20
style=3D"mso-fareast-font-family: 'Times New Roman'; =
mso-bidi-font-weight: bold"><SPAN=20
style=3D"mso-list: Ignore">3.<SPAN=20
style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
<SPAN=20
style=3D"mso-bidi-font-weight: bold; mso-bidi-font-style: italic"><FONT=20
size=3D3>While OIF&#8217;s UNI is based on an =
Informational RFC,=20
RFC3474, which was not a Standards Track Document, any new extensions to =
IETF=20
protocols now need to be reviewed by IETF under the (G)MPLS process. The =
OSPF=20
protocol elements in Appendix 1 (as noted in the document) are =
experimental. If=20
OIF sees a need for such extensions, OIF needs to bring the requirements =
to the=20
IETF. In the interests of a cooperative relationship between our =
organizations,=20
we advise against publication and public demonstrations of experimental=20
extensions to IETF protocols, based on presumed issues with IETF =
protocols, with=20
no review by IETF.<o:p></o:p>
<FONT=20
face=3D"Times New Roman"><SPAN=20
style=3D"mso-fareast-font-family: 'Times New Roman'"><SPAN=20
style=3D"mso-list: Ignore">4.<SPAN=20
style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
Section =
4.1/Table 1 and=20
the statement under the table identifying issues with GMPLS identifier=20
namespaces are not correct. GMPLS identifier namespaces do meet ASON=20
requirements for namespace separation of the transport plane and control =
plane=20
(Section 5.2 and 5.3/Evaluation). As you also identified in your liaison =
that=20
the key area needing review was the support of independence of =
functional=20
component to physical location, this appears to be a key area of=20
misunderstanding on GMPLS by OIF. While some pre-standard vendor =
implementations=20
do not support this separation, it is unfortunate if this has been =
guiding your=20
ASON work as a GMPLS issue and resulting in divergence on solutions. =
Discussion=20
on the CCAMP exploder highlighted a participant&#8217;s =
misinterpretation.<SPAN=20
style=3D"mso-spacerun: yes">&nbsp; We recommend reviewing RFC3945 =
(GMPLS=20
Architecture) to understand that the key architecture difference between =
GMPLS=20
and MPLS is the decoupling of the transport plane and control plane.=20
Additionally, RFC4394, RFC4397, and RFC4258, provide a mapping to ITU=20
terminology which may be helpful reading. To avoid these =
misunderstandings, we=20
encourage you to share your requirements with us in as early of a stage =
as=20
possible to allow us to work towards a standards track=20
solution.
<FONT=20
face=3D"Times New Roman"><SPAN=20
style=3D"mso-fareast-font-family: 'Times New Roman'"><SPAN=20
style=3D"mso-list: Ignore">5.<SPAN=20
style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
Concern was =
raised that=20
even though the codepoints in the Appendix carry the disclaimer that =
they are=20
for private and experimental use, the text in Section 1.2 positions the=20
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=20
Process on these extensions, this is very presumptuous. Again, we would=20
recommend against publication of this document in the public=20
domain.</FONT></FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><o:p><FONT =
face=3D"Times New Roman"=20
color=3D#000000 size=3D3>&nbsp;</FONT></o:p></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT face=3D"Times =
New Roman"=20
color=3D#000000 size=3D3>We request an additional round of communication =
of this=20
document to the IETF before OIF approval to allow us to work with you to =
improve=20
convergence between OIF and IETF work which, we believe, will be in the =
best=20
interests of our groups and the industry.</FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><o:p><FONT =
face=3D"Times New Roman"=20
color=3D#000000 size=3D3>&nbsp;</FONT></o:p></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT face=3D"Times =
New Roman"=20
color=3D#000000 size=3D3>Best regards,</FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT size=3D3><FONT=20
color=3D#000000><FONT face=3D"Times New Roman"><st1:PersonName =
w:st=3D"on">Adrian=20
Farrel</st1:PersonName> and Deborah Brungard,</FONT></FONT></FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT face=3D"Times =
New Roman"=20
color=3D#000000 size=3D3>CCAMP =
co-chairs</FONT></P></FONT></SPAN></DIV><BR>
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
<HR tabIndex=3D-1>
<FONT face=3DTahoma size=3D2><B>From:</B> owner-ccamp@ops.ietf.org=20
[mailto:owner-ccamp@ops.ietf.org] <B>On Behalf Of </B>Brungard, Deborah =
A,=20
ALABS<BR><B>Sent:</B> Friday, July 21, 2006 10:38 AM<BR><B>To:</B>=20
ccamp@ops.ietf.org<BR><B>Cc:</B> Adrian Farrel<BR><B>Subject:</B> =
Proposed=20
response to OIF on OSPF ENNI<BR></FONT><BR></DIV>
<DIV></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D845551814-21072006>Hi,</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial><FONT size=3D2><FONT =
color=3D#0000ff><FONT=20
face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D845551814-21072006></SPAN></FONT></FONT></FONT></FONT>&nbsp;</DIV=
>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial><FONT =
color=3D#0000ff><FONT size=3D2><SPAN=20
class=3D845551814-21072006>We had a communication from OIF on their OSPF =
ENNI=20
specification. </SPAN>You can see the original files on =
</FONT></FONT></FONT><A=20
href=3D"http://www.olddog.co.uk/ccamp.htm"><U><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>http://www.olddog.co.uk/ccamp.htm</FONT></U></A><FONT =
face=3DArial><FONT=20
color=3D#0000ff><FONT size=3D2>.<SPAN class=3D845551814-21072006> Having =
assembled=20
comments from several people and our discussions in Montreal, we have =
put=20
together the following response.</SPAN></FONT></FONT></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial><FONT =
color=3D#0000ff><FONT size=3D2><SPAN=20
class=3D845551814-21072006></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
<DIV dir=3Dltr><SPAN class=3D845551814-21072006><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>Please comment on the list in the next =
week.</FONT></SPAN></DIV>
<DIV dir=3Dltr><SPAN class=3D845551814-21072006><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr><SPAN class=3D845551814-21072006><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>Thanks,</FONT></SPAN></DIV>
<DIV dir=3Dltr><SPAN class=3D845551814-21072006><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>Adrian and Deborah</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff=20
size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT face=3D"Times =
New Roman"=20
size=3D3><SPAN class=3D427551414-21072006>=3D =3D =3D =3D =3D =3D =3D =
=3D =3D =3D</SPAN></FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT face=3D"Times =
New Roman"=20
size=3D3>Dear Jim,</FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><o:p><FONT =
face=3D"Times New Roman"=20
size=3D3>&nbsp;</FONT></o:p></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT face=3D"Times =
New Roman"=20
size=3D3>We thank you for sending us the OIF ENNI document in response =
to our=20
request. While we appreciate the document being provided for =
information, it is=20
concerning that this document has not been previously shared with CCAMP =
or the=20
OSPF WG considering the document contains significant modifications to =
the=20
operation of OSPF and reflects OIF work over the last several years. =
CCAMP has=20
been working on GMPLS ASON for several years and our Design Teams =
include OIF=20
participants. Even though a reply was not requested, we are replying, as =
we=20
strongly recommend that the document not be published for public =
information in=20
its current form.</FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><o:p><FONT =
face=3D"Times New Roman"=20
size=3D3>&nbsp;</FONT></o:p></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT face=3D"Times =
New Roman"=20
size=3D3>Of most concern to CCAMP is that it is not aligned with RFC =
4258=20
(Requirements for Generalized Multi-Protocol Label Switching (GMPLS) =
Routing for=20
the Automatically Switched Optical Network (ASON)) or the =
to-be-published:=20
</FONT><A=20
href=3D"ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpls-ason-rou=
ting-eval-03.txt"><FONT=20
face=3D"Times New Roman"=20
size=3D3>ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpls-ason-ro=
uting-eval-03.txt</FONT></A><FONT=20
face=3D"Times New Roman" size=3D3>. Considering notable OIF participants =
are authors=20
of both these IETF documents (and the same participants are contributors =
and the=20
Editor for the OIF document), the non-alignment is perplexing. =
Considering the=20
IETF document is ready for publication, we suggest in the interests of =
time,=20
that you align your document with the IETF document. If any questions on =
the=20
interpretation of the IETF&#8217;s work, we recommend that you either =
utilize the=20
CCAMP mail exploder or send a communication.</FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><o:p><FONT =
face=3D"Times New Roman"=20
size=3D3>&nbsp;</FONT></o:p></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT face=3D"Times =
New Roman"=20
size=3D3>Specific comments include:</FONT></P>
<P class=3DMsoNormal=20
style=3D"MARGIN: 0in 0in 0pt 0.25in; TEXT-INDENT: -0.25in; mso-list: l0 =
level1 lfo1; tab-stops: list .25in"><SPAN=20
style=3D"mso-fareast-font-family: 'Times New Roman'"><SPAN=20
style=3D"mso-list: Ignore"><FONT face=3D"Times New Roman"><FONT=20
size=3D3>1.</FONT><SPAN=20
style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></FONT></SPAN></SPAN><FONT face=3D"Times New Roman" size=3D3>What =
is the=20
intent of this document? Will it be published as an Implementation =
Agreement=20
(IA)?<BR>The title indicates it will be an Implementation Agreement on =
GMPLS=20
OSPF extensions, but the main body of the document is a list of issues =
with=20
GMPLS OSPF. Further, your communication to us stated the document was=20
requirements on and use of OSPF-TE at the ENNI. These three views seem =
to be=20
inconsistent.</FONT></P>
<P class=3DMsoNormal=20
style=3D"MARGIN: 0in 0in 0pt 0.25in; TEXT-INDENT: -0.25in; mso-list: l0 =
level1 lfo1; tab-stops: list .25in"><FONT=20
face=3D"Times New Roman"><I><SPAN=20
style=3D"mso-fareast-font-family: 'Times New Roman'; =
mso-bidi-font-weight: bold"><SPAN=20
style=3D"mso-list: Ignore"><FONT size=3D3>2.</FONT><SPAN=20
style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></SPAN></SPAN></I><FONT size=3D3>The list of changes from the =
previous=20
version (listed under the Table of Contents) includes &#8220;<I><SPAN=20
style=3D"mso-bidi-font-weight: bold">removed &#8220;intra-carrier&#8221; =

limitation<SPAN=20
style=3D"mso-bidi-font-weight: bold; mso-bidi-font-style: italic"><FONT=20
size=3D3>&#8221; and the inclusion of =
Figure 1 showing the=20
OSPF ENNI for use between vendor domains and between carrier domains. =
GMPLS=20
OSPF-TE already supports inter-vendor operations. The IETF&#8217;s =
GMPLS ASON=20
routing focus has been on the use of a link-state based protocol to =
support a=20
hierarchical routing architecture (G.7715.1) within a carrier&#8217;s =
domain.=20
Requirements for using a link state protocol as an inter-domain protocol =
between=20
carriers are significantly different. We strongly disagree if you intend =
to=20
publish this document as an inter-carrier OSPF ENNI Implementation =
Agreement=20
claiming alignment with IETF RFCs without review (or agreement) by any =
of the=20
IETF Working Groups.<o:p></o:p>
<FONT=20
face=3D"Times New Roman"><SPAN=20
style=3D"mso-fareast-font-family: 'Times New Roman'"><SPAN=20
style=3D"mso-list: Ignore">3.<SPAN=20
style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
Section 4.1/Table 1 and the =
statement under=20
the table identifying issues with GMPLS identifier namespaces are not =
correct.=20
GMPLS identifier namespaces do meet ASON requirements for namespace =
separation=20
of the transport plane and control plane (Section 5.2 and =
5.3/Evaluation).=20
Perhaps you are confusing OSPF and GMPLS OSPF? As you also identified in =
your=20
liaison that the key area needing review was the support of independence =
of=20
functional component to physical location, this appears to be a key area =
of=20
misunderstanding on GMPLS. We recommend reviewing RFC3945 (GMPLS =
Architecture)=20
to understand that the key architecture difference between GMPLS and =
MPLS is the=20
decoupling of the transport plane and control plane. Additionally, =
RFC4394,=20
RFC4397, and RFC4258, provide a mapping to ITU terminology which may be =
helpful=20
reading.
<o:p>&nbsp;</o:p>
We request an additional round of communication of this =
document to the=20
IETF before approval to allow us to work with you to produce convergence =
between=20
OIF and IETF work which, we believe, will be in the best interests of =
the=20
industry.
<o:p>&nbsp;</o:p>
Best regards,
<FONT=20
face=3D"Times New Roman"><st1:PersonName w:st=3D"on">Adrian =
Farrel</st1:PersonName>=20
and Deborah Brungard,
CCAMP co-chairs</DIV></BODY></HTML>

------_=_NextPart_001_01C6B1C7.EF6A2202--

Envelope-to: ccamp-data@psg.com
Delivery-date: Thu, 27 Jul 2006 18:32:43 +0000
Message-ID: <04e101c6b1aa$b08af050$0a23fea9@your029b8cecfe>
Reply-To: "Adrian Farrel" <adrian@olddog.co.uk>
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: "Mack-Crane, T. Benjamin" <Ben.Mack-Crane@tellabs.com>
Cc: <ccamp@ops.ietf.org>, "Brungard, Deborah A, ALABS" <dbrungard@att.com>
Subject: Re: Working Group Last Call on draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt
Date: Thu, 27 Jul 2006 18:26:38 +0100
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Ben,

You seem to believe that a tool:
- can only be designed with one use in mind
- must come with a statement that it MUST NOT be
  used for other purposes.

By the way:

> What is "C-to-C"?

Thanks for the laugh.

Adrian

Envelope-to: ccamp-data@psg.com
Delivery-date: Thu, 27 Jul 2006 18:32:36 +0000
Message-ID: <04e201c6b1aa$b80eeb60$0a23fea9@your029b8cecfe>
Reply-To: "Adrian Farrel" <adrian@olddog.co.uk>
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: "Jim Jones" <Jim.D.Jones@alcatel.com>
Cc: <ccamp@ops.ietf.org>
Subject: New CCAMP I-D of interest to OIF
Date: Thu, 27 Jul 2006 18:31:38 +0100
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Hi Jim,

>From recent exchanges on the CCAMP mailing list and from the E-NNI document 
that you sent us recently, I suspect that your members will be interested to 
know that the CCAMP working group has just adopted 
draft-ietf-ccamp-gmpls-ason-routing-ospf-00.txt as a working group draft.

There is some work still to be done on this, but we believe it is moving in 
the right direction to address the routing requirements of an ASON network, 
and we have received indications from participants in your forum and in the 
ITU-T study Group 15 that the work is a sound starting point.

As always, we welcome the input on this document and other CCAMP work 
through the CCAMP mailing list.

The draft can be downloaded from 
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-ospf-00.txt

Best regards,
Adrian and Deborah
CCAMP Co-chairs 

Envelope-to: ccamp-data@psg.com
Delivery-date: Thu, 27 Jul 2006 03:27:19 +0000
To: IETF-Announce <ietf-announce@ietf.org>
From: The IESG <iesg-secretary@ietf.org>
Subject: Last Call: 'GMPLS - Communication of Alarm Information' to Proposed  Standard (draft-ietf-ccamp-gmpls-alarm-spec) 
Reply-to: iesg@ietf.org
CC: <ccamp@ops.ietf.org>
Message-Id: <E1G5wWl-0005UZ-HD@stiedprstage1.ietf.org>
Date: Wed, 26 Jul 2006 23:27:11 -0400

The IESG has received a request from the Common Control and Measurement Plane 
WG to consider the following document:

- 'GMPLS - Communication of Alarm Information '
   <draft-ietf-ccamp-gmpls-alarm-spec-03.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
iesg@ietf.org or ietf@ietf.org mailing lists by 2006-08-09.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-alarm-spec-03.txt

Envelope-to: ccamp-data@psg.com
Delivery-date: Thu, 27 Jul 2006 03:24:33 +0000
To: IETF-Announce <ietf-announce@ietf.org>
From: The IESG <iesg-secretary@ietf.org>
Subject: Last Call: 'Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE'  to Proposed Standard (draft-ietf-ccamp-crankback) 
Reply-to: iesg@ietf.org
CC: <ccamp@ops.ietf.org>
Message-Id: <E1G5wSu-0005SB-0X@stiedprstage1.ietf.org>
Date: Wed, 26 Jul 2006 23:23:12 -0400

The IESG has received a request from the Common Control and Measurement Plane 
WG to consider the following document:

- 'Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE '
   <draft-ietf-ccamp-crankback-05.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
iesg@ietf.org or ietf@ietf.org mailing lists by 2006-08-09.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-crankback-05.txt

Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 26 Jul 2006 21:25:02 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: Working Group Last Call on draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt
Date: Wed, 26 Jul 2006 16:23:06 -0500
Message-ID: <A1A52203CA93634BA1748887B9993AEA0303587F@USNVEX1.tellabs-west.tellabsinc.net>
Thread-Topic: Working Group Last Call on draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt
Thread-Index: Acav1/VC3J6TsiKyQpCIbhumwfUbsQAMR9+g
From: "Mack-Crane, T. Benjamin" <Ben.Mack-Crane@tellabs.com>
To: "Adrian Farrel" <adrian@olddog.co.uk>
Cc: <ccamp@ops.ietf.org>, "Brungard, Deborah A, ALABS" <dbrungard@att.com>
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="us-ascii"

Hi Adrian,

> > Does the "link between the network and the egress node" connect
> > directly to the egress node?
>=20
> I believe that is the model we are building.
> Actually, I can see ways to use the same mechanism to solve wider
> connectivity pictures (e.g. C-to-C LSPs), but that would be an
extended
> application, and if it turned out to need additional encodings and
> procedures, i think it would be fine.

What is "C-to-C"?

It would be helpful if the specific case (or cases) covered by this
draft were clearer.  From the text in 4.3.1, 4.3.2, and 4.3.3 the form
of the protocol relationship across the link between the network and the
egress node seems to vary, but this is not explicitly described.

>=20
> >>> How is the "link between the network and the egress node"
> >>> determined?
> >>
> >> Good question. Clearly if there is only one such link, we are done.
> >> In the case of a "dual-homed" egress, the Link Capability object
> >> may report on more than one link.
> >
> > From your answer it is still not clear HOW the link is determined.
> > Is it assumed that the link (or set of links) is directly identified
by
> > the destination of the call?
>=20
> I, in my turn, am not quite sure what you mean by "determined" :-)

I think you got it right, i.e. how the egress call controller determines
the links about which to return capability info.  If I understand your
description below the determination of candidate links can take into
account more than just the destination name or address.  Correct?

> There are two steps:
> 1. The call responder can return information on one or more "links
>   between the network and the egress"
>   To do this, the call responder must determine such appropriate
>   links. It would certainly require knowledge of the destination of
>   the call, and would need to understand how that call destination
>   can be mapped to real connection end-points.
>   Now, it could simply return a full list of the available links with
>   information about the link capabilities, or it could filter the list
>   based on the information on the call request to supply a list of
>   links that it knows are suitable. Implementation choice.
> 2. On receiving a call response, the initiator must determine paths
>   for the connections (LSPs) that it will set up. The way that it
>   does this is (obviously?) out of scope since it is an algorithmic
>   process. However, it can take as input the information about
>   the available final links as supplied in the call response.
>=20
.=2E.snip...
> >>> Generally networks work best when there are uniform means
> >>> of providing connectivity between clients of the network.
> >>> What kinds of "tailoring" are envisioned?
> >>
> >> I think that the VCAT example is the best. The ingress may
> >> have the ability to generate a whole pile of signals, but the
> >> egress may only have the ability to terminate a limited set
> >> of signals.
> >> You might regard this as choosing between sub-layers, I
> >> suppose.
> >
> > A functional model would help here.
>=20
> Well, from my own personal point of view, while I think functional
> modeling
> can be a useful tool, I do not see the need for it here.
>=20
> However, if I put on the CCAMP co-chair hat (for the first time in
this
> discussion) I would say that if someone wants to produce a functional
> model
> for GMPLS then the working group would be pleased to look at it.

A functional model would be useful to show unambiguously what transport
plane configuration is being controlled by GMPLS.  It would not apply to
modeling GMPLS itself (control plane technology).  Throughout this
discussion I have had the feeling that only a subset of the possible
transport plane configurations are considered; however, the draft does
not clearly identify the configurations to which it applies.  Of course,
there is the fact that the link capability object is optional, so one
could argue that it can be used in any situation in which it is found
useful.  (Rather open ended.)

>=20
> > Are you saying that the ingress (i) can generate different LSP types
> > (i.e., different layer network technologies)
>=20
> Yup. The ingress can choose which adaptation functions to use.
>=20
> (Note that this is NOT saying that it can mix and match different LSP
> types
> to carry one payload signal.)
>=20
> > or (ii) can generate a different number of signals (e.g., as in
VCAT)
>=20
> Absolutely, yes.
>=20
> > or (iii) that the ingress offers different adaptations from
> > a client to the LSP(s)?
>=20
> Yes, again.

So it sounds like arbitrary flexibility is envisioned (which perhaps is
related to a lack of understanding of what flexibility is really
needed).

>=20
.=2E.snip...
> >>>What is "end-to-end spectral routing attribute negotiation"?
> >>
> >> It is a completely ridiculous and over-florid way of saying
> >> "end-to-end lambda negotiation for use in transparent optical
> >> networks".
> >
> > OK, but what egress link information is used by the ingress
> > in this case?
>=20
> I guess it would need to exchange the available lambdas that it can
> terminate.

Can't this constraint be handled by the egress, with the help of the
Label Set object?

>=20
> And, yes, this is not specified at the moment. All the I-D is doing is
> providing the tool kit, not the details of applicability.
>=20
> >>>What is "end-to-end spatial routing attribute negotiation"?
> >>
> >> Similarly poor choice of words for "end-to-end port negotiation
> >> for use in fiber switching networks".
> >
> > OK, again what egress link information is used by the ingress in
> > this case?
>=20
> I think that adaptation and switching capabilities would be important
here.

Negotiation of adaptation above the layer of the LSP being setup must
also be done for LSPs that are set up using management methods.  This is
something a capability exchange or link management protocol can do.  Why
is it necessary to duplicate this function in the call control protocol?

>=20
> But, again, the detailed information awaits someone who is
implementing
> this. We are just providing the object in which it can be encoded.

So at base this seems to be an open ended mechanism, for which
particular uses may be found in the future.  If the link capability
information is passed transparently between ingress and egress nodes,
this may present an issue for operators who do not wish to provide
clients an open communications channel via their signaling network.

.=2E.snip...
> >>>  Call setup may provide a suitable mechanism to exchange
> >>>   information for this purpose, although several other
possibilities
> >>>   exist.
> >>>
> >>> Just because a mechanism can be defined does not mean that it
> >>> should be.
> >>> Why is it necessary to define this mechanism, and add complexity
> >>> to call control, if another mechanism is required to do the same
> >>> thing in cases where call control is not used?
> >>
> >> Hmmm.
> >> Well that is a good question.
> >>
> >> I guess the answer is:
> >> Because the Call control mechanism a good one where this
> >> type of information (i.e. access connectivity information such
> >> as access addressing) is often exchanged.
> >
> > What is "access addressing"?  Can you give an example
> > use case?
>=20
> It is the address of an access point (such as an egress outside the
> network)
> where the address is taken from a different address space. You can
read
> more
> on this in RFC4208.
>=20
> >> Maybe more important are:
> >> - this mechanism is one that several implementers want to /
> >> have implemented.
> >
> > OK, but why?  There ought to be an explainable technical
> > reason.
>=20
> If you accept that the information needs to be exchanged, then the
> discussion is about which mechanism to use. The choice can be between
many
> mechanisms, but this is the only one that has been put forward. Other
> proposals would be welcomed, but in the presence of only one proposal
and
> the clear support from implementers, the request for technical
reasoning
> for
> adopting the solution seems a bit odd to me.

I would expect the technical reasoning supporting a proposed standard
should be fairly easy to provide.  I also think it would be of interest
to anyone involved in standards development.  (And even the need for the
information to be exchanged is still nebulous.)

>=20
> >> - no-one raised any concerns about this mechanism
> >> during a couple of years of discussion of this process
> >> and during WG last call.
> >
> > Was there discussion of the technical reasons for this
> > feature on the mailing list?  If you can provide a pointer
> > I can look at the reasons put forth there.
>=20
> Why do you believe there should be a discussion of the technical
reasons
> for
> a feature on the mailing list/ What is wrong with presenting the
solution
> in
> an I-D and allowing those with concerns (for example, those who are
> implementing in this area and who believe there is a better solution)
to
> raise the concerns?
>=20
> > (BTW, I raised this concern during working group last call;-)
>=20
> Did you?
> Are we still talking about the same thing? That is, the necessity and
> value
> of carrying Link Capabilities on a Call set-up or response message?
> I don't see any mention of this in your email of 19th June. In that
email
> you questioned:
> 1) Why use a notification message for Call control?
> 2) Were other (existing) call control protocols considered?
> 3) The network boundaries and models in sections 4.3 and 7
> 4) The exclusion of Simultaneous Call and connection establishment.
> 5) The address model in use.
>=20
> What exactly are you saying that you raised in the last call
discussion? I
> assume that you are saying that your concerns with the network
boundaries
> described in section 4.3 amount to a concern about the mechanisms used
to
> exchange information about the links that cross those boundaries.

Yes.

>=20
> >> It is possible that this is not the best way of achieving this
> >> (although it is my favourite), but if other mechanisms exist
> >> then (as Yakov fondly says) the market will decide which
> >> is the best mechanism.
> >
> > If other mechanisms must exist, and these can also be used
> > in the cases covered by this draft, then adding this mechanism
> > doesn't really help.
>=20
> "If."
>=20
> If other mechanisms exist that you believe are better, and if your
> implementation has shown that they are suitably functional, then I
> recommend
> you bring them forward quickly. In fact, I would go as far as saying
that
> you have a responsiblity to bring them forward.
>=20
> > If you could give an example showing where this mechanism
> > is needed, that might be enlightening.
>=20
> Yes?
>=20
> Let's take a PSC example and use the language of RFC4208.
> Suppose that an EN is dual-homed to the network as in the case of the
EN
> in
> the bottom left hand corner of Figure 1 of RFC4208.
> Let's suppose that the links to the network have very different delay
> characteristics.
> Let's assume that a connection is required to carry delay-sensitive
> traffic
> across the network to this EN.
> A call can be used to coordinate between the end points and to convey
the
> service requirements.
> The call response can be used to convey a list of suitable links, or
the
> link capabilities of all links.
> The connection can be routed to achieve the required service level.

It is common in transport applications for dual- (or multi-) homed
arrangements to be used for diversity and are expected to provide
equivalent service characteristics.  If the links do not provide
equivalent service characteristics, then they could be given different
destination addresses (or names) and the call request could be made to
the appropriate destination for the service.

It seems that this mechanism is being offered as a new level of routing
functionality.  That is, as a mechanism to choose which links would be
used to establish a connection (by selection from the set offered by the
egress call controller).  It adds a dimension of flexibility, and also
complexity, but the need for this added dimension seems nebulous.

>=20
> Adrian

Regards,
Ben
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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

Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 26 Jul 2006 19:56:01 +0000
From: "Jim Jones" <jim.d.jones@alcatel.com>
To: "'Adrian Farrel'" <adrian@olddog.co.uk>
Cc: "'Brungard, Deborah A, ALABS'" <dbrungard@att.com>, <ccamp@ops.ietf.org>
Subject: RE: Ethernet Traffic Parameters for Use in RSVP-TE Signaling
Date: Wed, 26 Jul 2006 14:55:41 -0500
Message-ID: <008c01c6b0ed$79dc8270$6701a8c0@ad3.ad.alcatel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Thread-index: Acaw0q0Tp0ZCpG+wTTecG+C1H0f+CwAGieIQ

Hi Adrian and Deborah,

Thank you for the information on Ethernet Traffic Parameters for RSVP-TE. We
will discuss this in our Vancouver meeting next week.

I also realized I was delinquent in responding to the CCAMP inputs on the
1:N protection feature that was sent on June 26. We appreciate the detailed
reply and are working through the information you provided.

Best Regards,
Jim

-----Original Message-----
From: Adrian Farrel [mailto:adrian@olddog.co.uk] 
Sent: Wednesday, July 26, 2006 11:23 AM
To: Jim Jones
Cc: Brungard, Deborah A, ALABS; ccamp@ops.ietf.org
Subject: Ethernet Traffic Parameters for Use in RSVP-TE Signaling

Hi Jim,

By way of input to your upcoming meeting in Vancouver, I would like to draw
your member's attention to
draft-ietf-ccamp-ethernet-traffic-parameters-00.txt. This document provides
"MEF Ethernet Traffic Parameters" and is intended to meet the requirements
of GMPLS and OIF UNI signaling of Ethernet LSP requests.

The Abstract reads as follows:

   This document described the Metro Ethernet Forum (MEF) - specific
   Ethernet Traffic Parameters as described in MEF.10 when using
   Generalized Multi-Protocol Label Switching (GMPLS) Resource
   ReSerVation Protocol - Traffic Engineering (RSVP-TE) signaling.

And the Introduction reads:

   Per [RFC3471], GMPLS allows the inclusion of technology specific
   parameters in signaling. Ethernet SENDER_TSPEC and FLOWSPEC specific
   objects are introduced in this document that describes Metro Ethernet
   Forum (MEF) Ethernet traffic parameters as specified in [MEF.10].

   These traffic parameters MUST be used when L2SC is specified in the
   LSP Switching Type field of a Generalized Label Request (see
   [RFC3471]) and the LSP encoding type is Ethernet.

The draft can be downloaded from
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ethernet-traffic-parame
ters-00.txt

We would very much welcome the comments of your members which can be sent as
individual contributions to the CCAMP mailing list, or as a more official
OIF comment through the usual channels.

Best regards,
Adrian and Deborah
CCAMP WG Co-chairs

Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 26 Jul 2006 19:51:39 +0000
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
Cc: ccamp@ops.ietf.org
From: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-ason-routing-ospf-00.txt 
Message-Id: <E1G5pOL-0001KB-W2@stiedprstage1.ietf.org>
Date: Wed, 26 Jul 2006 15:50:01 -0400

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

	Title		: OSPFv2 Routing Protocol Extensions for ASON Routing 
	Author(s)	: D. Papadimitriou
	Filename	: draft-ietf-ccamp-gmpls-ason-routing-ospf-00.txt
	Pages		: 
	Date		: 2006-7-28

   The Generalized MPLS (GMPLS) suite of protocols has been defined to 
   control different switching technologies as well as different 
   applications. These include support for requesting TDM connections 
   including SONET/SDH and Optical Transport Networks (OTNs). 

   This document provides the extensions of the OSPFv2 Link State 
   Routing Protocol to meet the routing requirements for an 
   Automatically Switched Optical Network (ASON) as defined by ITU-T.  

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-ospf-00.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ccamp-gmpls-ason-routing-ospf-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-ospf-00.txt".

NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2006-7-26133640.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-ospf-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-gmpls-ason-routing-ospf-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2006-7-26133640.I-D@ietf.org>

--OtherAccess--

--NextPart--

Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 26 Jul 2006 17:19:38 +0000
Message-ID: <44C7A3C1.8040308@pi.se>
Date: Wed, 26 Jul 2006 19:17:53 +0200
From: Loa Andersson <loa@pi.se>
Organization: Acreo AB
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: Adrian Farrel <adrian@olddog.co.uk>
CC: Jonathan Sadler <jonathan.sadler@tellabs.com>, ccamp@ops.ietf.org, IAB <iab@ietf.org>
Subject: An IETF / OIF liaison relationship Was: (Re: Proposed response to OIF on OSPF ENNI)
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

All,

the liaison relationship between IETF and other organizations
are not decided by the IETF working groups, but the IAB.

Taking my IAB hat of, (the IAB have not had time to  discuss
this), speaking for myself only.

In the case of OIF IAB have discussed a liaison reltionship
few times (e.g. April 17 2006) over the last two years. We have
seen no conclusive evidence that IETF will have any clear
benefits from a liaison relationship with the OIF.

Nevertheless, the IAB also said that we are willing to consider
such a relationship given that we have a mutual agreement on the
conditions regarding a liaison relationship.

My personal interpretation is that it would require at least
two very clear statements from the OIF:

- OIF will not extend, change or updated any IETF protocol without
  prior consultations with the IETF

- if the OIF after such consultations see needs for such extensions,
  changes or updates, the OIF will bring requirements to the IETF
  according to the (G)MPLS change process.

We have tried communicated this to the OIF leadership through private
channels, but have not found anyone prepared to discuss.

If this channel brings the message through more clearly we still
hope for a more constructive discussion.

 /Loa

Adrian Farrel wrote:
> Jon,
> 
> You said...
> 
>> 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.
> 
> You are now very close to the line.
> 
> Please restrain yourself from making disruptive and untrue statements on
> the CCAMP mailing list.
> 
> Thank you.
> 
> Adrian
> 
> 
> 

-- 
Loa Andersson

Principal Networking Architect
Acreo AB                           phone:  +46 8 632 77 14
Isafjordsgatan 22                  mobile: +46 739 81 21 64
Kista, Sweden                      email:  loa.andersson@acreo.se
                                           loa@pi.se

Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 26 Jul 2006 16:36:58 +0000
Message-ID: <02e001c6b0d1$95450620$0a23fea9@your029b8cecfe>
Reply-To: "Adrian Farrel" <adrian@olddog.co.uk>
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: "Jim Jones" <Jim.D.Jones@alcatel.com>
Cc: "Brungard, Deborah A, ALABS" <dbrungard@att.com>, <ccamp@ops.ietf.org>
Subject: Ethernet Traffic Parameters for Use in RSVP-TE Signaling
Date: Wed, 26 Jul 2006 17:23:16 +0100
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Hi Jim,

By way of input to your upcoming meeting in Vancouver, I would like to draw 
your member's attention to 
draft-ietf-ccamp-ethernet-traffic-parameters-00.txt. This document provides 
"MEF Ethernet Traffic Parameters" and is intended to meet the requirements 
of GMPLS and OIF UNI signaling of Ethernet LSP requests.

The Abstract reads as follows:

   This document described the Metro Ethernet Forum (MEF) - specific
   Ethernet Traffic Parameters as described in MEF.10 when using
   Generalized Multi-Protocol Label Switching (GMPLS) Resource
   ReSerVation Protocol - Traffic Engineering (RSVP-TE) signaling.

And the Introduction reads:

   Per [RFC3471], GMPLS allows the inclusion of technology specific
   parameters in signaling. Ethernet SENDER_TSPEC and FLOWSPEC specific
   objects are introduced in this document that describes Metro Ethernet
   Forum (MEF) Ethernet traffic parameters as specified in [MEF.10].

   These traffic parameters MUST be used when L2SC is specified in the
   LSP Switching Type field of a Generalized Label Request (see
   [RFC3471]) and the LSP encoding type is Ethernet.

The draft can be downloaded from 
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ethernet-traffic-parameters-00.txt

We would very much welcome the comments of your members which can be sent as 
individual contributions to the CCAMP mailing list, or as a more official 
OIF comment through the usual channels.

Best regards,
Adrian and Deborah
CCAMP WG Co-chairs

Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 26 Jul 2006 16:20:39 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Proposed response to OIF on OSPF ENNI
Date: Wed, 26 Jul 2006 09:20:10 -0700
Message-ID: <626FC7C6A97381468FB872072AB5DDC8C2DC2F@XCH-SW-42.sw.nos.boeing.com>
Thread-Topic: Proposed response to OIF on OSPF ENNI
Thread-Index: AcawiIQcvKU0ScNMSAa6Hq8hRT8aOAAOiXagAAMJY+A=
From: "Drake, John E" <John.E.Drake2@boeing.com>
To: "Ong, Lyndon" <Lyong@Ciena.com>, <Dimitri.Papadimitriou@alcatel.be>
Cc: <ccamp@ops.ietf.org>, <owner-ccamp@ops.ietf.org>

Lyndon,

Google "Any sufficiently advanced technology is indistinguishable from a
rigged demo."

Thanks,

John

> -----Original Message-----
> From: Ong, Lyndon [mailto:Lyong@Ciena.com]=20
> Sent: Wednesday, July 26, 2006 9:10 AM
> To: Dimitri.Papadimitriou@alcatel.be
> Cc: ccamp@ops.ietf.org; Drake, John E; owner-ccamp@ops.ietf.org
> Subject: RE: Proposed response to OIF on OSPF ENNI
>=20
>=20
> Hi Dimitri,
>=20
> Understood, I was just taken aback by the idea that the=20
> demonstration was somehow "rigged" (by little elves?)
>=20
> BTW it's not entirely clear what the testing process is to go=20
> from Proposed to
> Draft, the reports vary considerably in detail.   Some just list the
> number
> of implementations, without any test results.
>=20
> Cheers,  =20
>=20
> Lyndon
>=20
> -----Original Message-----
> From: Dimitri.Papadimitriou@alcatel.be=20
> [mailto:Dimitri.Papadimitriou@alcatel.be]=20
> Sent: Wednesday, July 26, 2006 12:53 AM
> To: Ong, Lyndon
> Cc: ccamp@ops.ietf.org; Drake, John E; owner-ccamp@ops.ietf.org
> Subject: RE: Proposed response to OIF on OSPF ENNI
>=20
> lyndon - i don't think the issue is exactly there ;-)
>=20
> the point is that having repeated demos and argue on its=20
> significance by the number and the affiliation of the=20
> participants does not make it necessarily a proof of validity=20
> both in terms of implementation and for what it related to=20
> the protocol arch./interoperability
> - this is the point i think john wants to make -
>=20
> so your question: how does IETF "validate" then ... well the=20
> answer by using the RFC2026 standard process - the reports on=20
> implementation following that process can be found at=20
> <http://www.ietf.org/IESG/implementation.html>
>=20
> for what it relates to MPLS/GMPLS there is addditionally an=20
> initial launching process for starting the effort:=20
> the so-called MPLS/GMPLS change process - which is more=20
> clearly formalizing current practices when a new effort is started -
>=20
> hope this answer your question
> - dimitri.
> =20
>=20
>=20
>=20
>=20
> "Ong, Lyndon" <Lyong@Ciena.com>
> Sent by: owner-ccamp@ops.ietf.org
> 26/07/2006 00:22
> =20
>         To:     "Drake, John E" <John.E.Drake2@boeing.com>,=20
> <ccamp@ops.ietf.org>
>         cc:=20
>         Subject:        RE: Proposed response to OIF on OSPF ENNI
>=20
>=20
> I confess it was all rigged, John.  Little midgets were inside the=20
> equipment plugging
> fibers here and there and typing RSVP messages into mini keypads.
> From: owner-ccamp@ops.ietf.org=20
> [mailto:owner-ccamp@ops.ietf.org] On Behalf=20
> Of Drake, John E
> Sent: Tuesday, July 25, 2006 3:08 PM
> To: ccamp@ops.ietf.org
> Subject: RE: Proposed response to OIF on OSPF ENNI
>=20
> =20
> -----Original Message-----
> From: Ong, Lyndon [mailto:Lyong@Ciena.com]=20
> Sent: Tuesday, July 25, 2006 2:39 PM
> To: Drake, John E; ccamp@ops.ietf.org
> Subject: RE: Proposed response to OIF on OSPF ENNI
>=20
> Hi John,
> =20
> If you wish to discuss how the tests were carried out, you=20
> can talk to the=20
>=20
> 7 major carriers that provided lab sites and the 13 router and switch=20
> vendors that participated
> in the 2005 demo.=20
> =20
> JD:  Just as I suspected=20
> =20
> In what sense does IETF use the term interoperability test?=20
> =20
> JD:  You know, the stuff required to advance to proposed standard
> =20
> Is there an RFC on this?=20
> =20
> JD:  I'm sure.
> =20
> I was unaware that IETF ran interoperability tests.=20
> =20
> JD:  I didn't say it did, and I don't know if it does.=20
> =20
> Cheers,
> =20
> Lyndon
>=20
> From: owner-ccamp@ops.ietf.org=20
> [mailto:owner-ccamp@ops.ietf.org] On Behalf=20
> Of Drake, John E
> Sent: Tuesday, July 25, 2006 2:28 PM
> To: ccamp@ops.ietf.org
> Subject: RE: Proposed response to OIF on OSPF ENNI
>=20
>  Snipped
> =20
>  Regarding Topic 2:
> =20
> =20
> Again I ask, wouldn't it be better to look at this document=20
> which has been=20
> implemented by many vendors, and successfully=20
> interoperability tested many=20
> times over many years to see what can be leveraged instead of=20
> starting=20
> from scratch?=20
> =20
> JD:  I noticed that Jonathan has put in this plug several=20
> times.  I am=20
> wondering whether these events are truly interoperability=20
> tests, in the=20
> sense that the IETF uses the term, or rather rigged demos?  I seem to=20
> remember that the OIF characterized itself as a marketing=20
> organization.
>=20
>=20
> =20
>=20

Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 26 Jul 2006 16:11:51 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Proposed response to OIF on OSPF ENNI
Date: Wed, 26 Jul 2006 12:09:48 -0400
Message-ID: <0901D1988E815341A0103206A834DA07F1A37E@mdmxm02.ciena.com>
Thread-Topic: Proposed response to OIF on OSPF ENNI
Thread-Index: AcawiIQcvKU0ScNMSAa6Hq8hRT8aOAAOiXag
From: "Ong, Lyndon" <Lyong@Ciena.com>
To: <Dimitri.Papadimitriou@alcatel.be>
Cc: <ccamp@ops.ietf.org>, "Drake, John E" <John.E.Drake2@boeing.com>, <owner-ccamp@ops.ietf.org>

Hi Dimitri,

Understood, I was just taken aback by the idea that the demonstration
was
somehow "rigged" (by little elves?)

BTW it's not entirely clear what the testing process is to go from
Proposed to
Draft, the reports vary considerably in detail.   Some just list the
number
of implementations, without any test results.

Cheers,  =20

Lyndon

-----Original Message-----
From: Dimitri.Papadimitriou@alcatel.be
[mailto:Dimitri.Papadimitriou@alcatel.be]=20
Sent: Wednesday, July 26, 2006 12:53 AM
To: Ong, Lyndon
Cc: ccamp@ops.ietf.org; Drake, John E; owner-ccamp@ops.ietf.org
Subject: RE: Proposed response to OIF on OSPF ENNI

lyndon - i don't think the issue is exactly there ;-)

the point is that having repeated demos and argue on its significance by
the number and the affiliation of the participants does not make it
necessarily a proof of validity both in terms of implementation and for
what it related to the protocol arch./interoperability
- this is the point i think john wants to make -

so your question: how does IETF "validate" then ... well the answer by
using the RFC2026 standard process - the reports on implementation
following that process can be found at
<http://www.ietf.org/IESG/implementation.html>

for what it relates to MPLS/GMPLS there is addditionally an initial
launching process for starting the effort:=20
the so-called MPLS/GMPLS change process - which is more clearly
formalizing current practices when a new effort is started -

hope this answer your question
- dimitri.
=20

"Ong, Lyndon" <Lyong@Ciena.com>
Sent by: owner-ccamp@ops.ietf.org
26/07/2006 00:22
=20
        To:     "Drake, John E" <John.E.Drake2@boeing.com>,=20
<ccamp@ops.ietf.org>
        cc:=20
        Subject:        RE: Proposed response to OIF on OSPF ENNI

I confess it was all rigged, John.  Little midgets were inside the=20
equipment plugging
fibers here and there and typing RSVP messages into mini keypads.
From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On
Behalf=20
Of Drake, John E
Sent: Tuesday, July 25, 2006 3:08 PM
To: ccamp@ops.ietf.org
Subject: RE: Proposed response to OIF on OSPF ENNI

=20
-----Original Message-----
From: Ong, Lyndon [mailto:Lyong@Ciena.com]=20
Sent: Tuesday, July 25, 2006 2:39 PM
To: Drake, John E; ccamp@ops.ietf.org
Subject: RE: Proposed response to OIF on OSPF ENNI

Hi John,
=20
If you wish to discuss how the tests were carried out, you can talk to
the=20

7 major carriers that provided lab sites and the 13 router and switch=20
vendors that participated
in the 2005 demo.=20
=20
JD:  Just as I suspected=20
=20
In what sense does IETF use the term interoperability test?=20
=20
JD:  You know, the stuff required to advance to proposed standard
=20
Is there an RFC on this?=20
=20
JD:  I'm sure.
=20
I was unaware that IETF ran interoperability tests.=20
=20
JD:  I didn't say it did, and I don't know if it does.=20
=20
Cheers,
=20
Lyndon

From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On
Behalf=20
Of Drake, John E
Sent: Tuesday, July 25, 2006 2:28 PM
To: ccamp@ops.ietf.org
Subject: RE: Proposed response to OIF on OSPF ENNI

 Snipped
=20
 Regarding Topic 2:
=20
=20
Again I ask, wouldn't it be better to look at this document which has
been=20
implemented by many vendors, and successfully interoperability tested
many=20
times over many years to see what can be leveraged instead of starting=20
from scratch?=20
=20
JD:  I noticed that Jonathan has put in this plug several times.  I am=20
wondering whether these events are truly interoperability tests, in the=20
sense that the IETF uses the term, or rather rigged demos?  I seem to=20
remember that the OIF characterized itself as a marketing organization.

=20

Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 26 Jul 2006 13:54:02 +0000
Message-ID: <021a01c6b0ba$df5e1b50$0a23fea9@your029b8cecfe>
Reply-To: "Adrian Farrel" <adrian@olddog.co.uk>
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: "Adrian Farrel" <adrian@olddog.co.uk>, <ccamp@ops.ietf.org>
Subject: Re: OSPF ASON Routing Solution
Date: Wed, 26 Jul 2006 14:52:26 +0100
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response
Content-Transfer-Encoding: 7bit

Having seem some discussion of the mechanisms and debate about the details, 
but no objections, we will take this as a WG document.

Dimitri, please re-submit as draft-ietf-ccamp-gmpls-ason-routing-ospf-00.txt

Thanks,
Adrian
----- Original Message ----- 
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: <ccamp@ops.ietf.org>
Sent: Wednesday, July 19, 2006 2:27 PM
Subject: Re: OSPF ASON Routing Solution

> Just a refresh in case you were travelling.
>
> I am seeking objections to this draft becoming a WG document.
>
> Adrian
> ----- Original Message ----- 
> From: "Adrian Farrel" <adrian@olddog.co.uk>
> To: <ccamp@ops.ietf.org>
> Sent: Wednesday, July 12, 2006 8:10 PM
> Subject: OSPF ASON Routing Solution
>
>
>> Hi,
>> On Monday in CCAMP we discussed 
>> draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt the solutions draft 
>> for OSPF in ASON routing.
>>
>> There is agreement from the OSPF WG chair that we are not treading on 
>> toes, and the meeting seemed to say that this was pretty stable.
>>
>> So a this is a quick poll to see if anyone objects to this becoming a WG 
>> draft.
>> NB, this is a charter item and we have an obligation to work on this for 
>> the ITU-T.
>>
>> Thanks,
>> Adrian
>>
>> PS Note that a solution does not have to be 100% perfect to become a WG 
>> draft.

Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 26 Jul 2006 13:45:27 +0000
Message-ID: <01c201c6b0b9$ac306950$0a23fea9@your029b8cecfe>
Reply-To: "Adrian Farrel" <adrian@olddog.co.uk>
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: "Richard Rabbat" <richard@us.fujitsu.com>, "Sadler, Jonathan B." <Jonathan.Sadler@tellabs.com>
Cc: "Brungard, Deborah A, ALABS" <dbrungard@att.com>, "Ong, Lyndon" <Lyong@Ciena.com>, <ccamp@ops.ietf.org>, "Richard Rabbat" <richard@us.fujitsu.com>
Subject: Addressing draft [Was: Proposed response to OIF on OSPF ENNI]
Date: Wed, 26 Jul 2006 14:43:42 +0100
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=response
Content-Transfer-Encoding: 7bit

Richard said:

> Sadler, Jonathan B. wrote:
>>
>> - 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.
>>
> Can you please elaborate on the issue discussed in the addressing draft? 
> Which section are you talking about?

This is actually very important.

I have just re-read the draft and I do not find any such text discussing any 
real or imagined namespace issues.

If the draft gives the false impression that there is some major issue with 
GMPLS namespaces I hope Jonathan will highlight the text so that it can be 
removed.

Thanks,
Adrian

Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 26 Jul 2006 13:40:04 +0000
Message-ID: <019901c6b0b8$f0d379e0$0a23fea9@your029b8cecfe>
Reply-To: "Adrian Farrel" <adrian@olddog.co.uk>
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: "Jonathan Sadler" <jonathan.sadler@tellabs.com>
Cc: <ccamp@ops.ietf.org>
Subject: Re: Proposed response to OIF on OSPF ENNI
Date: Wed, 26 Jul 2006 14:39:30 +0100
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Jon,

You said...

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

You are now very close to the line.

Please restrain yourself from making disruptive and untrue statements on the 
CCAMP mailing list.

Thank you.

Adrian 

Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 26 Jul 2006 13:35:13 +0000
Message-ID: <019301c6b0b8$3b5476a0$0a23fea9@your029b8cecfe>
Reply-To: "Adrian Farrel" <adrian@olddog.co.uk>
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: <ccamp@ops.ietf.org>
Cc: "Scott Bradner" <sob@harvard.edu>
Subject: Statements about liaison relationship with ITU-T SG15
Date: Wed, 26 Jul 2006 14:32:14 +0100
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Hi,

The discussion of the liaison relationship between CCAMP and ITU-T SG15 on 
this mailing list, is (in my view) getting unnecessarily heated and does not 
demonstrate a desire to achieve cooperative work between the bodies while 
continuing to recognise each body's right to make standards in their areas 
of expertise and with the protocol that they 'own'.

The ASON routing work has demonstrated the best cooperation between CCAMP 
and SG15 to date, and has successfully involved participants from CCAMP, 
SG15, and the OIF. The liaison process for this work was initially 
tentative, but developed into a good exchange with CCAMP requesting input 
from SG15 on the requirements and the evaluation as they were being 
produced, and with the input from SG15 being given proper consideration and 
response by the authors. Further, the solutions work now in progress has 
also been communicated to SG15 with a promise to liaise the work as it 
stabilises.

Attempts to represent the relationship between the bodies as anything other 
than "significantly improving" are, in fact, part of the long-standing 
problem. If anyone has an issue with past or current procedures and 
constructive suggestions for change, they are welcome to express them on the 
CCAMP list, to me directly (as liaison to the ITU-T on optical networking), 
or to Scott Bradner (as overall IETF liaison to the ITU-T).

Thanks,
Adrian

Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 26 Jul 2006 13:05:08 +0000
Message-ID: <015a01c6b0b3$d9d24af0$0a23fea9@your029b8cecfe>
Reply-To: "Adrian Farrel" <adrian@olddog.co.uk>
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: "Sadler, Jonathan B." <Jonathan.Sadler@tellabs.com>
Cc: <ccamp@ops.ietf.org>
Subject: Alignment of OIF routing requirements with CCAMP ASON routing requirements [Was : Proposed response to OIF on OSPF ENNI]
Date: Wed, 26 Jul 2006 13:58:45 +0100
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

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

Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 26 Jul 2006 08:49:24 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Proposed response to OIF on OSPF ENNI
Date: Wed, 26 Jul 2006 10:48:04 +0200
Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB02603AF5371@FTRDMEL2.rd.francetelecom.fr>
Thread-Topic: Proposed response to OIF on OSPF ENNI
Thread-Index: AcavdNm23DacerUoR2eeOhvtB9cVwQAqe5VwABrepVA=
From: "MEURIC Julien RD-CORE-LAN" <julien.meuric@orange-ft.com>
To: "Brungard, Deborah A, ALABS" <dbrungard@att.com>, <otani@kddilabs.jp>
Cc: <ccamp@ops.ietf.org>, <adrian@olddog.co.uk>

Hi all.

About the OSPF scope, I also have concern. As far as I know, OSPF is an
IGP, which brings 2 issues to my mind:
- OSPF has not been built as an EGP, so enlarging it to that scope must
be considered thoroughly;
- I really do not see the use of any link-state protocol for
inter-carrier applications.

Regards,

Julien

-----Original Message-----
From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On
Behalf Of Brungard, Deborah A, ALABS

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

Regards,
Deborah
=20

-----Original Message-----
From: Tomohiro Otani [mailto:otani@kddilabs.jp]=20

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:
> Hi,
> =20
> We had a communication from OIF on their OSPF ENNI specification. You=20
> can see the original files on _http://www.olddog.co.uk/ccamp.htm_.=20
> Having assembled comments from several people and our discussions in=20
> Montreal, we have put together the following response.
> =20
> Please comment on the list in the next week.
> =20
> Thanks,
> Adrian and Deborah
> =20
>=20
> =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D
>=20
> Dear Jim,
>=20
> =20
>=20
> We thank you for sending us the OIF ENNI document in response to our=20
> request. While we appreciate the document being provided for=20
> information, it is concerning that this document has not been
previously=20
> shared with CCAMP or the OSPF WG considering the document contains=20
> significant modifications to the operation of OSPF and reflects OIF
work=20
> over the last several years. CCAMP has been working on GMPLS ASON for=20
> several years and our Design Teams include OIF participants. Even
though=20
> a reply was not requested, we are replying, as we strongly recommend=20
> that the document not be published for public information in its
current=20
> form.
>=20
> =20
>=20
> Of most concern to CCAMP is that it is not aligned with RFC 4258=20
> (Requirements for Generalized Multi-Protocol Label Switching (GMPLS)=20
> Routing for the Automatically Switched Optical Network (ASON)) or the=20
> to-be-published:=20
>
ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-ev
al-03.txt.=20
> Considering notable OIF participants are authors of both these IETF=20
> documents (and the same participants are contributors and the Editor
for=20
> the OIF document), the non-alignment is perplexing. Considering the
IETF=20
> document is ready for publication, we suggest in the interests of
time,=20
> that you align your document with the IETF document. If any questions
on=20
> the interpretation of the IETF's work, we recommend that you either=20
> utilize the CCAMP mail exploder or send a communication.
>=20
> =20
>=20
> Specific comments include:
>=20
> 1.      What is the intent of this document? Will it be published as
an=20
> Implementation Agreement (IA)?
> The title indicates it will be an Implementation Agreement on GMPLS
OSPF=20
> 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=20
> requirements on and use of OSPF-TE at the ENNI. These three views seem

> to be inconsistent.
>=20
> /2.      /The list of changes from the previous version (listed under=20
> the Table of Contents) includes "/removed "intra-carrier" limitation/"

> and the inclusion of Figure 1 showing the OSPF ENNI for use between=20
> vendor domains and between carrier domains. GMPLS OSPF-TE already=20
> supports inter-vendor operations.
> The IETF's GMPLS ASON routing focus has been on the use of a
link-state=20
> based protocol to support a hierarchical routing architecture
(G.7715.1)=20
> within a carrier's domain. Requirements for using a link state
protocol=20
> as an inter-domain protocol between carriers are significantly=20
> different. We strongly disagree if you intend to publish this document

> as an inter-carrier OSPF ENNI Implementation Agreement claiming=20
> alignment with IETF RFCs without review (or agreement) by any of the=20
> IETF Working Groups.//
>=20
> 3.      Section 4.1/Table 1 and the statement under the table=20
> identifying issues with GMPLS identifier namespaces are not correct.=20
> GMPLS identifier namespaces do meet ASON requirements for namespace=20
> separation of the transport plane and control plane (Section 5.2 and=20
> 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=20
> support of independence of functional component to physical location,=20
> this appears to be a key area of misunderstanding on GMPLS. We
recommend=20
> reviewing RFC3945 (GMPLS Architecture) to understand that the key=20
> architecture difference between GMPLS and MPLS is the decoupling of
the=20
> transport plane and control plane. Additionally, RFC4394, RFC4397, and

> RFC4258, provide a mapping to ITU terminology which may be helpful
reading.
>=20
> =20
>=20
> We request an additional round of communication of this document to
the=20
> IETF before approval to allow us to work with you to produce
convergence=20
> between OIF and IETF work which, we believe, will be in the best=20
> interests of the industry.
>=20
> =20
>=20
> Best regards,
>=20
> Adrian Farrel and Deborah Brungard,
>=20
> CCAMP co-chairs
>=20

Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 26 Jul 2006 07:53:27 +0000
To: "Ong, Lyndon" <Lyong@Ciena.com>
Cc: ccamp@ops.ietf.org, "Drake, John E" <John.E.Drake2@boeing.com>, owner-ccamp@ops.ietf.org
Subject: RE: Proposed response to OIF on OSPF ENNI
MIME-Version: 1.0
Message-ID: <OF843CE607.10183F3B-ONC12571B6.007B8F78-C12571B7.002B459B@netfr.alcatel.fr>
From: Dimitri.Papadimitriou@alcatel.be
Date: Wed, 26 Jul 2006 09:52:37 +0200
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: base64

bHluZG9uIC0gaSBkb24ndCB0aGluayB0aGUgaXNzdWUgaXMgZXhhY3RseSB0aGVyZSA7LSkNCg0K
dGhlIHBvaW50IGlzIHRoYXQgaGF2aW5nIHJlcGVhdGVkIGRlbW9zIGFuZCBhcmd1ZSBvbiANCml0
cyBzaWduaWZpY2FuY2UgYnkgdGhlIG51bWJlciBhbmQgdGhlIGFmZmlsaWF0aW9uIG9mIA0KdGhl
IHBhcnRpY2lwYW50cyBkb2VzIG5vdCBtYWtlIGl0IG5lY2Vzc2FyaWx5IGEgcHJvb2YgDQpvZiB2
YWxpZGl0eSBib3RoIGluIHRlcm1zIG9mIGltcGxlbWVudGF0aW9uIGFuZCBmb3IgDQp3aGF0IGl0
IHJlbGF0ZWQgdG8gdGhlIHByb3RvY29sIGFyY2guL2ludGVyb3BlcmFiaWxpdHkNCi0gdGhpcyBp
cyB0aGUgcG9pbnQgaSB0aGluayBqb2huIHdhbnRzIHRvIG1ha2UgLQ0KDQpzbyB5b3VyIHF1ZXN0
aW9uOiBob3cgZG9lcyBJRVRGICJ2YWxpZGF0ZSIgdGhlbiAuLi4gd2VsbCANCnRoZSBhbnN3ZXIg
YnkgdXNpbmcgdGhlIFJGQzIwMjYgc3RhbmRhcmQgcHJvY2VzcyAtIHRoZQ0KcmVwb3J0cyBvbiBp
bXBsZW1lbnRhdGlvbiBmb2xsb3dpbmcgdGhhdCBwcm9jZXNzIGNhbiBiZSANCmZvdW5kIGF0IA0K
PGh0dHA6Ly93d3cuaWV0Zi5vcmcvSUVTRy9pbXBsZW1lbnRhdGlvbi5odG1sPg0KDQpmb3Igd2hh
dCBpdCByZWxhdGVzIHRvIE1QTFMvR01QTFMgdGhlcmUgaXMgYWRkZGl0aW9uYWxseQ0KYW4gaW5p
dGlhbCBsYXVuY2hpbmcgcHJvY2VzcyBmb3Igc3RhcnRpbmcgdGhlIGVmZm9ydDogDQp0aGUgc28t
Y2FsbGVkIE1QTFMvR01QTFMgY2hhbmdlIHByb2Nlc3MgLSB3aGljaCBpcyBtb3JlIA0KY2xlYXJs
eSBmb3JtYWxpemluZyBjdXJyZW50IHByYWN0aWNlcyB3aGVuIGEgbmV3IGVmZm9ydCANCmlzIHN0
YXJ0ZWQgLQ0KDQpob3BlIHRoaXMgYW5zd2VyIHlvdXIgcXVlc3Rpb24gDQotIGRpbWl0cmkuDQog
DQoNCg0KDQoNCiJPbmcsIEx5bmRvbiIgPEx5b25nQENpZW5hLmNvbT4NClNlbnQgYnk6IG93bmVy
LWNjYW1wQG9wcy5pZXRmLm9yZw0KMjYvMDcvMjAwNiAwMDoyMg0KIA0KICAgICAgICBUbzogICAg
ICJEcmFrZSwgSm9obiBFIiA8Sm9obi5FLkRyYWtlMkBib2VpbmcuY29tPiwgDQo8Y2NhbXBAb3Bz
LmlldGYub3JnPg0KICAgICAgICBjYzogDQogICAgICAgIFN1YmplY3Q6ICAgICAgICBSRTogUHJv
cG9zZWQgcmVzcG9uc2UgdG8gT0lGIG9uIE9TUEYgRU5OSQ0KDQoNCkkgY29uZmVzcyBpdCB3YXMg
YWxsIHJpZ2dlZCwgSm9obi4gIExpdHRsZSBtaWRnZXRzIHdlcmUgaW5zaWRlIHRoZSANCmVxdWlw
bWVudCBwbHVnZ2luZw0KZmliZXJzIGhlcmUgYW5kIHRoZXJlIGFuZCB0eXBpbmcgUlNWUCBtZXNz
YWdlcyBpbnRvIG1pbmkga2V5cGFkcy4NCkZyb206IG93bmVyLWNjYW1wQG9wcy5pZXRmLm9yZyBb
bWFpbHRvOm93bmVyLWNjYW1wQG9wcy5pZXRmLm9yZ10gT24gQmVoYWxmIA0KT2YgRHJha2UsIEpv
aG4gRQ0KU2VudDogVHVlc2RheSwgSnVseSAyNSwgMjAwNiAzOjA4IFBNDQpUbzogY2NhbXBAb3Bz
LmlldGYub3JnDQpTdWJqZWN0OiBSRTogUHJvcG9zZWQgcmVzcG9uc2UgdG8gT0lGIG9uIE9TUEYg
RU5OSQ0KDQogDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogT25nLCBMeW5kb24g
W21haWx0bzpMeW9uZ0BDaWVuYS5jb21dIA0KU2VudDogVHVlc2RheSwgSnVseSAyNSwgMjAwNiAy
OjM5IFBNDQpUbzogRHJha2UsIEpvaG4gRTsgY2NhbXBAb3BzLmlldGYub3JnDQpTdWJqZWN0OiBS
RTogUHJvcG9zZWQgcmVzcG9uc2UgdG8gT0lGIG9uIE9TUEYgRU5OSQ0KDQpIaSBKb2huLA0KIA0K
SWYgeW91IHdpc2ggdG8gZGlzY3VzcyBob3cgdGhlIHRlc3RzIHdlcmUgY2FycmllZCBvdXQsIHlv
dSBjYW4gdGFsayB0byB0aGUgDQoNCjcgbWFqb3IgY2FycmllcnMgdGhhdCBwcm92aWRlZCBsYWIg
c2l0ZXMgYW5kIHRoZSAxMyByb3V0ZXIgYW5kIHN3aXRjaCANCnZlbmRvcnMgdGhhdCBwYXJ0aWNp
cGF0ZWQNCmluIHRoZSAyMDA1IGRlbW8uIA0KIA0KSkQ6ICBKdXN0IGFzIEkgc3VzcGVjdGVkIA0K
IA0KSW4gd2hhdCBzZW5zZSBkb2VzIElFVEYgdXNlIHRoZSB0ZXJtIGludGVyb3BlcmFiaWxpdHkg
dGVzdD8gDQogDQpKRDogIFlvdSBrbm93LCB0aGUgc3R1ZmYgcmVxdWlyZWQgdG8gYWR2YW5jZSB0
byBwcm9wb3NlZCBzdGFuZGFyZA0KIA0KSXMgdGhlcmUgYW4gUkZDIG9uIHRoaXM/IA0KIA0KSkQ6
ICBJJ20gc3VyZS4NCiANCkkgd2FzIHVuYXdhcmUgdGhhdCBJRVRGIHJhbiBpbnRlcm9wZXJhYmls
aXR5IHRlc3RzLiANCiANCkpEOiAgSSBkaWRuJ3Qgc2F5IGl0IGRpZCwgYW5kIEkgZG9uJ3Qga25v
dyBpZiBpdCBkb2VzLiANCiANCkNoZWVycywNCiANCkx5bmRvbg0KDQpGcm9tOiBvd25lci1jY2Ft
cEBvcHMuaWV0Zi5vcmcgW21haWx0bzpvd25lci1jY2FtcEBvcHMuaWV0Zi5vcmddIE9uIEJlaGFs
ZiANCk9mIERyYWtlLCBKb2huIEUNClNlbnQ6IFR1ZXNkYXksIEp1bHkgMjUsIDIwMDYgMjoyOCBQ
TQ0KVG86IGNjYW1wQG9wcy5pZXRmLm9yZw0KU3ViamVjdDogUkU6IFByb3Bvc2VkIHJlc3BvbnNl
IHRvIE9JRiBvbiBPU1BGIEVOTkkNCg0KIFNuaXBwZWQNCiANCiBSZWdhcmRpbmcgVG9waWMgMjoN
CiANCiANCkFnYWluIEkgYXNrLCB3b3VsZG7igJl0IGl0IGJlIGJldHRlciB0byBsb29rIGF0IHRo
aXMgZG9jdW1lbnQgd2hpY2ggaGFzIGJlZW4gDQppbXBsZW1lbnRlZCBieSBtYW55IHZlbmRvcnMs
IGFuZCBzdWNjZXNzZnVsbHkgaW50ZXJvcGVyYWJpbGl0eSB0ZXN0ZWQgbWFueSANCnRpbWVzIG92
ZXIgbWFueSB5ZWFycyB0byBzZWUgd2hhdCBjYW4gYmUgbGV2ZXJhZ2VkIGluc3RlYWQgb2Ygc3Rh
cnRpbmcgDQpmcm9tIHNjcmF0Y2g/IA0KIA0KSkQ6ICBJIG5vdGljZWQgdGhhdCBKb25hdGhhbiBo
YXMgcHV0IGluIHRoaXMgcGx1ZyBzZXZlcmFsIHRpbWVzLiAgSSBhbSANCndvbmRlcmluZyB3aGV0
aGVyIHRoZXNlIGV2ZW50cyBhcmUgdHJ1bHkgaW50ZXJvcGVyYWJpbGl0eSB0ZXN0cywgaW4gdGhl
IA0Kc2Vuc2UgdGhhdCB0aGUgSUVURiB1c2VzIHRoZSB0ZXJtLCBvciByYXRoZXIgcmlnZ2VkIGRl
bW9zPyAgSSBzZWVtIHRvIA0KcmVtZW1iZXIgdGhhdCB0aGUgT0lGIGNoYXJhY3Rlcml6ZWQgaXRz
ZWxmIGFzIGEgbWFya2V0aW5nIG9yZ2FuaXphdGlvbi4gIA0KDQogDQoNCg==

Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 26 Jul 2006 07:07:20 +0000
Message-Id: <6.2.3.4.2.20060726145745.096dc810@inc.inetcore.com>
Date: Wed, 26 Jul 2006 16:05:21 +0900
To: otani@kddilabs.jp, ma-miyazawa@kddilabs.jp, tnadeau@cisco.com, ke-kumaki@kddi.com
From: Ken Nagami <nagami@wide.ad.jp>
Subject: comments for draft-ietf-ccamp-gmpls-ospf-mib-00.txt
Cc: ccamp@ops.ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Content-Transfer-Encoding: 7bit

Dear authors (Masanori, Tomo, Tom, Kenji)

I have following comments for the draft-ietf-ccamp-gmpls-ospf-mib-00.txt
I think it is better to change the draft. How do you think?

Regards,
Ken Nagami
-----------------------
1. Index of ospfTeLsdbEntry should be changed.
   - Index of ospfTeLsdbEntry needs to add ospfAreaID becasue LSDB 
exists in each ospf area.
     current INDEX
       { ospfLsdbLsid, ospflsdbRouterId}
     should changed to
       { ospfAreaId, ospfLsdbLsid, ospflsdbRouterId}

2. Index of ospfTeLocalIntAddrEntry, ospfTeRemoteIntAddrEntry, 
ospfTeSwCapEntry and
    ospfTeSrlgEntry needs to add ospfAreaId. This is same as the above.

3. "ospfTeLinkIdAddr     InetAddress,
     ospfTeLinkIdAddrType InetAddressType"
    needs to change to
    "ospfTeLinkIdAddr     IpAddress"
    Because the Link ID in the RFC3630 is 32 bits.

4. "ospfTeLocalIntAddr, ospfTeLocalIntAddrType" and 
"ospfTeRemoteIntAddr, ospfTeRemoteIntAddrType"
    needs to be changed. This is same as the above.

5. Need to add information for "Router Address TLV" in section 2.4.1 of RFC3630.
    I think the current draft do not have information of "Router Address TLV".

6. SYNTAX of "*Bandwidth*" needs to change from "Unsigned32" to 
"OCTET STRING SIZE(4)"
    because this field is described by IEEE floating point format.

    Related managed objects are :
     ospfTeMaxBandwidth
     ospfMaxReservableBandwidth
     ospfTeUnreservedBandwidthPri*
     ospfTeMaxLspBandwidth*

7. I think it is better to add "UNITS byte per seconds" in "*Bandwidth*" objects.

8. SYNTAX of ospfTeLinkProtectionType needs to change from "INTEGER" to "BITS".
    Because the first octet of "Link protection Type" in section 1.2 of RFC4303
    is a bit vector.

9. MIB compile error
         "Initial version. Published as RFC xxxx." -- RFC-editor pls fill
         in xxx"
     needs to changed to
         "Initial version. Published as RFC xxxx." -- RFC-editor pls fill
                                                   -- in xxx

Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 25 Jul 2006 23:24:51 +0000
To: "Payam Torab" <ptorab@lopsys.com>
Cc: ccamp@ops.ietf.org, "'Dave Walters'" <dwalters@lopsys.com>, owner-ccamp@ops.ietf.org
Subject: RE: shared mesh restoration - e2e recovery signaling draft
MIME-Version: 1.0
Message-ID: <OFE71BFB78.76B5585A-ONC12571B6.007FCEEA-C12571B6.00808E4B@netfr.alcatel.fr>
From: Dimitri.Papadimitriou@alcatel.be
Date: Wed, 26 Jul 2006 01:24:09 +0200
Content-Type: text/plain; charset="US-ASCII"

notify the other (N-1) ingresses by sending a PathErr of Notify msg - the 
error code defined for this case is "Notify Error/LSP Recovered" - applies 
here, i didn't list it in the draft because the mechanism of bringing back 
the recovery LSP availability is not specific to shared mesh it applies 
whenever the recovery LSP is not available for whatever reason

thanks,
- d.

"Payam Torab" <ptorab@lopsys.com>
Sent by: owner-ccamp@ops.ietf.org
26/07/2006 01:11

        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     <ccamp@ops.ietf.org>, "'Dave Walters'" 
<dwalters@lopsys.com>, <owner-ccamp@ops.ietf.org>
        Subject:        RE: shared mesh restoration - e2e recovery 
signaling draft

Dimitri- indeed, the last case under Section 12 is the case of interest, 
but
we are talking about the very last step of the process (last two sentences
in Section 12):

   3. Finally, de-activate the protecting LSP by setting the S bit to 1 
      in the PROTECTION object sent over the protecting LSP.

It is not clear (not documented) how the ingress nodes for other working
LSPs should know after this step that the protecting LSP is available 
again
and they are not vulnerable anymore. I hope this clarifies the question.

Thanks,
Payam

> -----Original Message-----
> From: Dimitri.Papadimitriou@alcatel.be 
> [mailto:Dimitri.Papadimitriou@alcatel.be] 
> Sent: Tuesday, July 25, 2006 6:53 PM
> To: Payam Torab
> Cc: ccamp@ops.ietf.org; 'Dave Walters'; owner-ccamp@ops.ietf.org
> Subject: RE: shared mesh restoration - e2e recovery signaling draft
> 
> 
> ok you are referring to the case when the LSP reverts back to 
> the primary same business but instead make use of the "Notify 
> Error/LSP Recovered" 
> code
> 
> this is documented in section 12 (last part)
> 
> thanks,
> - dimitri.
> 
> 
> 
> 
> "Payam Torab" <ptorab@lopsys.com>
> Sent by: owner-ccamp@ops.ietf.org
> 26/07/2006 00:47
> 
>         To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
>         cc:     <ccamp@ops.ietf.org>, "'Dave Walters'" 
> <dwalters@lopsys.com>, <owner-ccamp@ops.ietf.org>
>         Subject:        RE: shared mesh restoration - e2e recovery 
> signaling draft
> 
> 
> The question is availability of a mechanism once the shared 
> restoration 
> path
> becomes available again - we would like to let the other 
> ingress nodes 
> know
> their LSPs are no longer vulnerable (if they have not picked 
> a different restoration path already); Referring to the 
> scenario on page 20 of the draft, it is desirable for node E 
> to notify H that the shared restoration path H-E-F-G-K is 
> available again.
> 
> A notify message with the error code/sub-code "Notify 
> Error/LSP Recovered" could be a good solution, but it does 
> not seem to be used by the draft in this context.
> 
> Thanks,
> Payam
> 
> 
> > -----Original Message-----
> > From: owner-ccamp@ops.ietf.org
> > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of 
> > Dimitri.Papadimitriou@alcatel.be
> > Sent: Tuesday, July 25, 2006 6:25 PM
> > To: Payam Torab
> > Cc: ccamp@ops.ietf.org; 'Dave Walters'; owner-ccamp@ops.ietf.org
> > Subject: Re: shared mesh restoration - e2e recovery signaling draft
> > 
> > 
> > hi
> > 
> > your question is in a shared mesh case, are the ingress nodes (N-1)
> > notified about the use of the recovery path by the remaining 
> > ingress node 
> > part of the same shared mesh group
> > 
> > answer is yes - you can notify the other ingresses by sending
> > a PathErr of 
> > Notify msg - the error code defined for this case is "Notify 
> > Error/LSP 
> > Locally Failed" - 
> > 
> > much thanks,
> > - dimitri.
> > 
> > 
> > 
> > 
> > 
> > "Payam Torab" <ptorab@lopsys.com>
> > Sent by: owner-ccamp@ops.ietf.org
> > 26/07/2006 00:11
> > 
> >         To:     <ccamp@ops.ietf.org>
> >         cc:     "'Dave Walters'" <dwalters@lopsys.com>
> >         Subject:        shared mesh restoration - e2e 
> > recovery signaling
> > draft
> > 
> > 
> > In the e2e recovery signaling draft
> > (draft-ietf-ccamp-gmpls-recovery-e2e-signaling-03.txt), there is a 
> > procedure defined for a node on the shared restoration path 
> to notify 
> > other nodes regarding the working LSPs that become vulnerable 
> > as a result 
> > of switching to the shared restoration path.
> > 
> > It seems there is a similar need to notify these nodes once
> > the shared 
> > restoration path becomes available again. Is this mechanism defined 
> > anywhere?
> > 
> > Thanks,
> > Payam
> > 
> 
> 
> 

Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 25 Jul 2006 23:13:29 +0000
From: "Payam Torab" <ptorab@lopsys.com>
To: <Dimitri.Papadimitriou@alcatel.be>
Cc: <ccamp@ops.ietf.org>, "'Dave Walters'" <dwalters@lopsys.com>, <owner-ccamp@ops.ietf.org>
Subject: RE: shared mesh restoration - e2e recovery signaling draft
Date: Tue, 25 Jul 2006 19:11:57 -0400
Organization: Lambda OpticalSystems
Message-ID: <00a201c6b03f$b9cf32f0$30fea8c0@NETPTORAB>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Dimitri- indeed, the last case under Section 12 is the case of interest, but
we are talking about the very last step of the process (last two sentences
in Section 12):

   3. Finally, de-activate the protecting LSP by setting the S bit to 1  
      in the PROTECTION object sent over the protecting LSP.

It is not clear (not documented) how the ingress nodes for other working
LSPs should know after this step that the protecting LSP is available again
and they are not vulnerable anymore. I hope this clarifies the question.

Thanks,
Payam

> -----Original Message-----
> From: Dimitri.Papadimitriou@alcatel.be 
> [mailto:Dimitri.Papadimitriou@alcatel.be] 
> Sent: Tuesday, July 25, 2006 6:53 PM
> To: Payam Torab
> Cc: ccamp@ops.ietf.org; 'Dave Walters'; owner-ccamp@ops.ietf.org
> Subject: RE: shared mesh restoration - e2e recovery signaling draft
> 
> 
> ok you are referring to the case when the LSP reverts back to 
> the primary same business but instead make use of the "Notify 
> Error/LSP Recovered" 
> code
> 
> this is documented in section 12 (last part)
> 
> thanks,
> - dimitri.
> 
> 
> 
> 
> "Payam Torab" <ptorab@lopsys.com>
> Sent by: owner-ccamp@ops.ietf.org
> 26/07/2006 00:47
>  
>         To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
>         cc:     <ccamp@ops.ietf.org>, "'Dave Walters'" 
> <dwalters@lopsys.com>, <owner-ccamp@ops.ietf.org>
>         Subject:        RE: shared mesh restoration - e2e recovery 
> signaling draft
> 
> 
> The question is availability of a mechanism once the shared 
> restoration 
> path
> becomes available again - we would like to let the other 
> ingress nodes 
> know
> their LSPs are no longer vulnerable (if they have not picked 
> a different restoration path already); Referring to the 
> scenario on page 20 of the draft, it is desirable for node E 
> to notify H that the shared restoration path H-E-F-G-K is 
> available again.
> 
> A notify message with the error code/sub-code "Notify 
> Error/LSP Recovered" could be a good solution, but it does 
> not seem to be used by the draft in this context.
> 
> Thanks,
> Payam
> 
> 
> > -----Original Message-----
> > From: owner-ccamp@ops.ietf.org
> > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of 
> > Dimitri.Papadimitriou@alcatel.be
> > Sent: Tuesday, July 25, 2006 6:25 PM
> > To: Payam Torab
> > Cc: ccamp@ops.ietf.org; 'Dave Walters'; owner-ccamp@ops.ietf.org
> > Subject: Re: shared mesh restoration - e2e recovery signaling draft
> > 
> > 
> > hi
> > 
> > your question is in a shared mesh case, are the ingress nodes (N-1)
> > notified about the use of the recovery path by the remaining 
> > ingress node 
> > part of the same shared mesh group
> > 
> > answer is yes - you can notify the other ingresses by sending
> > a PathErr of 
> > Notify msg - the error code defined for this case is "Notify 
> > Error/LSP 
> > Locally Failed" - 
> > 
> > much thanks,
> > - dimitri.
> > 
> > 
> > 
> > 
> > 
> > "Payam Torab" <ptorab@lopsys.com>
> > Sent by: owner-ccamp@ops.ietf.org
> > 26/07/2006 00:11
> > 
> >         To:     <ccamp@ops.ietf.org>
> >         cc:     "'Dave Walters'" <dwalters@lopsys.com>
> >         Subject:        shared mesh restoration - e2e 
> > recovery signaling
> > draft
> > 
> > 
> > In the e2e recovery signaling draft
> > (draft-ietf-ccamp-gmpls-recovery-e2e-signaling-03.txt), there is a 
> > procedure defined for a node on the shared restoration path 
> to notify 
> > other nodes regarding the working LSPs that become vulnerable 
> > as a result 
> > of switching to the shared restoration path.
> > 
> > It seems there is a similar need to notify these nodes once
> > the shared 
> > restoration path becomes available again. Is this mechanism defined 
> > anywhere?
> > 
> > Thanks,
> > Payam
> > 
> 
> 
> 

Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 25 Jul 2006 22:53:37 +0000
To: "Payam Torab" <ptorab@lopsys.com>
Cc: ccamp@ops.ietf.org, "'Dave Walters'" <dwalters@lopsys.com>, owner-ccamp@ops.ietf.org
Subject: RE: shared mesh restoration - e2e recovery signaling draft
MIME-Version: 1.0
Message-ID: <OF0B839290.70AA0157-ONC12571B6.007D67EA-C12571B6.007DAED8@netfr.alcatel.fr>
From: Dimitri.Papadimitriou@alcatel.be
Date: Wed, 26 Jul 2006 00:52:46 +0200
Content-Type: text/plain; charset="US-ASCII"

ok you are referring to the case when the LSP reverts back to the primary
same business but instead make use of the "Notify Error/LSP Recovered" 
code

this is documented in section 12 (last part)

thanks,
- dimitri.

"Payam Torab" <ptorab@lopsys.com>
Sent by: owner-ccamp@ops.ietf.org
26/07/2006 00:47

        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     <ccamp@ops.ietf.org>, "'Dave Walters'" 
<dwalters@lopsys.com>, <owner-ccamp@ops.ietf.org>
        Subject:        RE: shared mesh restoration - e2e recovery 
signaling draft

The question is availability of a mechanism once the shared restoration 
path
becomes available again - we would like to let the other ingress nodes 
know
their LSPs are no longer vulnerable (if they have not picked a different
restoration path already); Referring to the scenario on page 20 of the
draft, it is desirable for node E to notify H that the shared restoration
path H-E-F-G-K is available again.

A notify message with the error code/sub-code "Notify Error/LSP Recovered"
could be a good solution, but it does not seem to be used by the draft in
this context.

Thanks,
Payam

> -----Original Message-----
> From: owner-ccamp@ops.ietf.org 
> [mailto:owner-ccamp@ops.ietf.org] On Behalf Of 
> Dimitri.Papadimitriou@alcatel.be
> Sent: Tuesday, July 25, 2006 6:25 PM
> To: Payam Torab
> Cc: ccamp@ops.ietf.org; 'Dave Walters'; owner-ccamp@ops.ietf.org
> Subject: Re: shared mesh restoration - e2e recovery signaling draft
> 
> 
> hi 
> 
> your question is in a shared mesh case, are the ingress nodes (N-1) 
> notified about the use of the recovery path by the remaining 
> ingress node 
> part of the same shared mesh group
> 
> answer is yes - you can notify the other ingresses by sending 
> a PathErr of 
> Notify msg - the error code defined for this case is "Notify 
> Error/LSP 
> Locally Failed" - 
> 
> much thanks,
> - dimitri.
> 
> 
> 
> 
> 
> "Payam Torab" <ptorab@lopsys.com>
> Sent by: owner-ccamp@ops.ietf.org
> 26/07/2006 00:11
> 
>         To:     <ccamp@ops.ietf.org>
>         cc:     "'Dave Walters'" <dwalters@lopsys.com>
>         Subject:        shared mesh restoration - e2e 
> recovery signaling 
> draft
> 
> 
> In the e2e recovery signaling draft 
> (draft-ietf-ccamp-gmpls-recovery-e2e-signaling-03.txt), there is a 
> procedure defined for a node on the shared restoration path to notify 
> other nodes regarding the working LSPs that become vulnerable 
> as a result 
> of switching to the shared restoration path.
> 
> It seems there is a similar need to notify these nodes once 
> the shared 
> restoration path becomes available again. Is this mechanism defined 
> anywhere?
> 
> Thanks,
> Payam
> 

Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 25 Jul 2006 22:48:57 +0000
From: "Payam Torab" <ptorab@lopsys.com>
To: <Dimitri.Papadimitriou@alcatel.be>
Cc: <ccamp@ops.ietf.org>, "'Dave Walters'" <dwalters@lopsys.com>, <owner-ccamp@ops.ietf.org>
Subject: RE: shared mesh restoration - e2e recovery signaling draft
Date: Tue, 25 Jul 2006 18:47:50 -0400
Organization: Lambda OpticalSystems
Message-ID: <009f01c6b03c$5b7aab10$30fea8c0@NETPTORAB>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

The question is availability of a mechanism once the shared restoration path
becomes available again - we would like to let the other ingress nodes know
their LSPs are no longer vulnerable (if they have not picked a different
restoration path already); Referring to the scenario on page 20 of the
draft, it is desirable for node E to notify H that the shared restoration
path H-E-F-G-K is available again.

A notify message with the error code/sub-code "Notify Error/LSP Recovered"
could be a good solution, but it does not seem to be used by the draft in
this context.

Thanks,
Payam

> -----Original Message-----
> From: owner-ccamp@ops.ietf.org 
> [mailto:owner-ccamp@ops.ietf.org] On Behalf Of 
> Dimitri.Papadimitriou@alcatel.be
> Sent: Tuesday, July 25, 2006 6:25 PM
> To: Payam Torab
> Cc: ccamp@ops.ietf.org; 'Dave Walters'; owner-ccamp@ops.ietf.org
> Subject: Re: shared mesh restoration - e2e recovery signaling draft
> 
> 
> hi 
> 
> your question is in a shared mesh case, are the ingress nodes (N-1) 
> notified about the use of the recovery path by the remaining 
> ingress node 
> part of the same shared mesh group
> 
> answer is yes - you can notify the other ingresses by sending 
> a PathErr of 
> Notify msg - the error code defined for this case is "Notify 
> Error/LSP 
> Locally Failed" - 
> 
> much thanks,
> - dimitri.
> 
> 
> 
> 
> 
> "Payam Torab" <ptorab@lopsys.com>
> Sent by: owner-ccamp@ops.ietf.org
> 26/07/2006 00:11
>  
>         To:     <ccamp@ops.ietf.org>
>         cc:     "'Dave Walters'" <dwalters@lopsys.com>
>         Subject:        shared mesh restoration - e2e 
> recovery signaling 
> draft
> 
> 
> In the e2e recovery signaling draft 
> (draft-ietf-ccamp-gmpls-recovery-e2e-signaling-03.txt), there is a 
> procedure defined for a node on the shared restoration path to notify 
> other nodes regarding the working LSPs that become vulnerable 
> as a result 
> of switching to the shared restoration path.
>  
> It seems there is a similar need to notify these nodes once 
> the shared 
> restoration path becomes available again. Is this mechanism defined 
> anywhere?
>  
> Thanks,
> Payam
> 

Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 25 Jul 2006 22:46:13 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6B03B.0AECFD70"
Subject: RE: Proposed response to OIF on OSPF ENNI
Date: Tue, 25 Jul 2006 18:38:25 -0400
Message-ID: <0901D1988E815341A0103206A834DA07F1A2E0@mdmxm02.ciena.com>
Thread-Topic: Proposed response to OIF on OSPF ENNI
Thread-Index: Acas0Ha/aYxFikOBS5m873SVRoVJxgAACLxQAAHPZJAAnZ89IAACGznwAAEH8mAAAxLNQAAAS4QQACJG/RAAAkvKMAANb1UQAABQfIAAASU6IAAAZZ6gAACVGuAAACH1gA==
From: "Ong, Lyndon" <Lyong@Ciena.com>
To: "Drake, John E" <John.E.Drake2@boeing.com>, <ccamp@ops.ietf.org>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6B03B.0AECFD70
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

What's more, any display lights on the equipment were actually tiny
candles
burning behind small circles of colored glass (don't ask how the fibers
were lit).

________________________________

From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On
Behalf Of Drake, John E
Sent: Tuesday, July 25, 2006 3:33 PM
To: ccamp@ops.ietf.org
Subject: RE: Proposed response to OIF on OSPF ENNI

That's even worse than what I expected.

	-----Original Message-----
	From: Ong, Lyndon [mailto:Lyong@Ciena.com]=20
	Sent: Tuesday, July 25, 2006 3:22 PM
	To: Drake, John E; ccamp@ops.ietf.org
	Subject: RE: Proposed response to OIF on OSPF ENNI
=09
=09
	I confess it was all rigged, John.  Little midgets were inside
the equipment plugging
	fibers here and there and typing RSVP messages into mini
keypads.
=09
________________________________

	From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]
On Behalf Of Drake, John E
	Sent: Tuesday, July 25, 2006 3:08 PM
	To: ccamp@ops.ietf.org
	Subject: RE: Proposed response to OIF on OSPF ENNI
=09
=09
	=20

		-----Original Message-----
		From: Ong, Lyndon [mailto:Lyong@Ciena.com]=20
		Sent: Tuesday, July 25, 2006 2:39 PM
		To: Drake, John E; ccamp@ops.ietf.org
		Subject: RE: Proposed response to OIF on OSPF ENNI
	=09
	=09
		Hi John,
		=20
		If you wish to discuss how the tests were carried out,
you can talk to the=20
		7 major carriers that provided lab sites and the 13
router and switch vendors that participated
		in the 2005 demo.=20
		=20
		JD:  Just as I suspected=20
		=20
		In what sense does IETF use the term interoperability
test?=20
		=20
		JD:  You know, the stuff required to advance to proposed
standard
		=20
		Is there an RFC on this?=20
		=20
		JD:  I'm sure.
		=20
		I was unaware that IETF ran interoperability tests.=20
		=20
		JD:  I didn't say it did, and I don't know if it does.=20
		=20
		Cheers,
		=20
		Lyndon

________________________________

		From: owner-ccamp@ops.ietf.org
[mailto:owner-ccamp@ops.ietf.org] On Behalf Of Drake, John E
		Sent: Tuesday, July 25, 2006 2:28 PM
		To: ccamp@ops.ietf.org
		Subject: RE: Proposed response to OIF on OSPF ENNI
	=09
	=09
		 Snipped
		=20
		 Regarding Topic 2:

			=20

			=20

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

			=20

			JD:  I noticed that Jonathan has put in this
plug several times.  I am wondering whether these events are truly
interoperability tests, in the sense that the IETF uses the term, or
rather rigged demos?  I seem to remember that the OIF characterized
itself as a marketing organization. =20

		=09
________________________________

			=20

------_=_NextPart_001_01C6B03B.0AECFD70
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:v =3D=20
"urn:schemas-microsoft-com:vml" xmlns:o =3D=20
"urn:schemas-microsoft-com:office:office" xmlns:w =3D=20
"urn:schemas-microsoft-com:office:word" xmlns:p =3D=20
"urn:schemas-microsoft-com:office:powerpoint" xmlns:oa =3D=20
"urn:schemas-microsoft-com:office:activation" xmlns:st1 =3D=20
"urn:schemas-microsoft-com:office:smarttags"><HEAD><TITLE>Message</TITLE>=

<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.2912" name=3DGENERATOR><!--[if !mso]>
<STYLE>v\:* {
	BEHAVIOR: url(#default#VML)
}
o\:* {
	BEHAVIOR: url(#default#VML)
}
w\:* {
	BEHAVIOR: url(#default#VML)
}
.shape {
	BEHAVIOR: url(#default#VML)
}
</STYLE>
<![endif]--><o:SmartTagType=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" =
name=3D"State"=20
downloadurl=3D"http://www.5iamas-microsoft-com:office:smarttags"></o:Smar=
tTagType><o:SmartTagType=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" =
name=3D"City"=20
downloadurl=3D"http://www.5iamas-microsoft-com:office:smarttags"></o:Smar=
tTagType><o:SmartTagType=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" =
name=3D"place"=20
downloadurl=3D"http://www.5iantlavalamp.com/"></o:SmartTagType><o:SmartTa=
gType=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" =
name=3D"PersonName"=20
downloadurl=3D"http://www.microsoft.com"></o:SmartTagType><!--[if !mso]>
<STYLE>st1\:* {
	BEHAVIOR: url(#default#ieooui)
}
</STYLE>
<![endif]-->
<STYLE>@font-face {
	font-family: Wingdings;
}
@font-face {
	font-family: MS Mincho;
}
@font-face {
	font-family: Tahoma;
}
@font-face {
	font-family: @MS Mincho;
}
@page Section1 {size: 8.5in 11.0in; margin: 1.0in 1.25in 1.0in 1.25in; }
P.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
LI.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
DIV.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline
}
A:visited {
	COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlinkFollowed {
	COLOR: blue; TEXT-DECORATION: underline
}
PRE {
	FONT-SIZE: 10pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Courier New"
}
SPAN.EmailStyle18 {
	COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal
}
SPAN.EmailStyle19 {
	COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal
}
SPAN.EmailStyle20 {
	COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal
}
SPAN.EmailStyle21 {
	COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal-reply
}
DIV.Section1 {
	page: Section1
}
OL {
	MARGIN-BOTTOM: 0in
}
UL {
	MARGIN-BOTTOM: 0in
}
</STYLE>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]--></HEAD>
<BODY lang=3DEN-US vLink=3Dblue link=3Dblue><![if =
!supportLists]><![endif]><![if !supportLists]><![endif]><![if =
!supportLists]><![endif]><![if !supportLists]><![endif]><![if =
!supportLists]><![endif]>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D918463522-25072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>What's more, any display lights on the =
equipment were=20
actually tiny candles</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D918463522-25072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>burning behind small circles of colored glass =
(don't ask=20
how the fibers were lit).</FONT></SPAN></DIV><BR>
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
<HR tabIndex=3D-1>
<FONT face=3DTahoma size=3D2><B>From:</B> owner-ccamp@ops.ietf.org=20
[mailto:owner-ccamp@ops.ietf.org] <B>On Behalf Of </B>Drake, John=20
E<BR><B>Sent:</B> Tuesday, July 25, 2006 3:33 PM<BR><B>To:</B>=20
ccamp@ops.ietf.org<BR><B>Subject:</B> RE: Proposed response to OIF on =
OSPF=20
ENNI<BR></FONT><BR></DIV>
<DIV></DIV>
<DIV><SPAN class=3D264593122-25072006><FONT face=3DArial color=3D#0000ff =
size=3D2>That's=20
even worse than what I expected.</FONT></SPAN></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
  face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B> Ong, =
Lyndon=20
  [mailto:Lyong@Ciena.com] <BR><B>Sent:</B> Tuesday, July 25, 2006 3:22=20
  PM<BR><B>To:</B> Drake, John E; ccamp@ops.ietf.org<BR><B>Subject:</B> =
RE:=20
  Proposed response to OIF on OSPF ENNI<BR><BR></FONT></DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN =
class=3D442181522-25072006></SPAN><FONT=20
  face=3DArial><FONT color=3D#0000ff><FONT size=3D2>I<SPAN =
class=3D442181522-25072006>=20
  confess it</SPAN><SPAN class=3D442181522-25072006>&nbsp;was all =
rigged,=20
  John.&nbsp; Little midgets were inside the equipment=20
  plugging</SPAN></FONT></FONT></FONT></DIV>
  <DIV dir=3Dltr align=3Dleft><FONT size=3D+0><FONT =
color=3D#0000ff><FONT size=3D2><SPAN=20
  class=3D442181522-25072006></SPAN></FONT></FONT></FONT><SPAN=20
  class=3D442181522-25072006></SPAN><FONT face=3DArial><FONT =
color=3D#0000ff><FONT=20
  size=3D2>f<SPAN class=3D442181522-25072006>ibers here and there and =
typing RSVP=20
  messages into mini keypads.</SPAN></FONT></FONT></FONT><BR></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
  <HR tabIndex=3D-1>
  <FONT face=3DTahoma size=3D2><B>From:</B> owner-ccamp@ops.ietf.org=20
  [mailto:owner-ccamp@ops.ietf.org] <B>On Behalf Of </B>Drake, John=20
  E<BR><B>Sent:</B> Tuesday, July 25, 2006 3:08 PM<BR><B>To:</B>=20
  ccamp@ops.ietf.org<BR><B>Subject:</B> RE: Proposed response to OIF on =
OSPF=20
  ENNI<BR></FONT><BR></DIV>
  <DIV></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT>&nbsp;</DIV>
  <BLOCKQUOTE dir=3Dltr=20
  style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
    <DIV></DIV>
    <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
    face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B> =
Ong, Lyndon=20
    [mailto:Lyong@Ciena.com] <BR><B>Sent:</B> Tuesday, July 25, 2006 =
2:39=20
    PM<BR><B>To:</B> Drake, John E; =
ccamp@ops.ietf.org<BR><B>Subject:</B> RE:=20
    Proposed response to OIF on OSPF ENNI<BR><BR></FONT></DIV>
    <DIV dir=3Dltr align=3Dleft><SPAN class=3D693083121-25072006><FONT =
face=3DArial=20
    color=3D#0000ff size=3D2>Hi John,</FONT></SPAN></DIV>
    <DIV dir=3Dltr align=3Dleft><SPAN class=3D693083121-25072006><FONT =
face=3DArial=20
    color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
    <DIV dir=3Dltr align=3Dleft><SPAN class=3D693083121-25072006><FONT =
face=3DArial=20
    color=3D#0000ff size=3D2>If you wish to discuss how the tests were =
carried out,=20
    you can talk to the </FONT></SPAN></DIV>
    <DIV dir=3Dltr align=3Dleft><SPAN class=3D693083121-25072006><FONT =
face=3DArial=20
    color=3D#0000ff size=3D2>7 major carriers that provided lab sites =
and the 13=20
    router and switch vendors that participated</FONT></SPAN></DIV>
    <DIV dir=3Dltr align=3Dleft><SPAN class=3D693083121-25072006><FONT=20
    face=3DArial><FONT color=3D#0000ff><FONT size=3D2>in the 2005 =
demo.<SPAN=20
    =
class=3D710560322-25072006>&nbsp;</SPAN></FONT></FONT></FONT></SPAN></DIV=
>
    <DIV dir=3Dltr align=3Dleft><SPAN class=3D693083121-25072006><FONT=20
    face=3DArial><FONT color=3D#0000ff><FONT size=3D2><SPAN=20
    =
class=3D710560322-25072006></SPAN></FONT></FONT></FONT></SPAN>&nbsp;</DIV=
>
    <DIV dir=3Dltr align=3Dleft><SPAN class=3D693083121-25072006><FONT=20
    face=3DArial><FONT color=3D#0000ff><FONT size=3D2><SPAN=20
    class=3D710560322-25072006>JD:&nbsp; Just as I=20
    suspected&nbsp;</SPAN></FONT></FONT></FONT></SPAN></DIV>
    <DIV dir=3Dltr align=3Dleft><SPAN class=3D693083121-25072006><FONT =
face=3DArial=20
    color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
    <DIV dir=3Dltr align=3Dleft><SPAN class=3D693083121-25072006><FONT =
face=3DArial=20
    color=3D#0000ff size=3D2>In what sense does IETF use the term =
interoperability=20
    test?<SPAN =
class=3D710560322-25072006>&nbsp;</SPAN></FONT></SPAN></DIV>
    <DIV dir=3Dltr align=3Dleft><SPAN class=3D693083121-25072006><FONT =
face=3DArial=20
    color=3D#0000ff size=3D2><SPAN=20
    class=3D710560322-25072006></SPAN></FONT></SPAN>&nbsp;</DIV>
    <DIV dir=3Dltr align=3Dleft><SPAN class=3D693083121-25072006><FONT =
face=3DArial=20
    color=3D#0000ff size=3D2><SPAN class=3D710560322-25072006>JD:&nbsp; =
You know, the=20
    stuff required to advance&nbsp;to proposed=20
    standard</SPAN></FONT></SPAN></DIV>
    <DIV dir=3Dltr align=3Dleft><SPAN class=3D693083121-25072006><FONT =
face=3DArial=20
    color=3D#0000ff size=3D2><SPAN=20
    class=3D710560322-25072006></SPAN></FONT></SPAN>&nbsp;</DIV>
    <DIV dir=3Dltr align=3Dleft><SPAN class=3D693083121-25072006><FONT =
size=3D+0><FONT=20
    face=3DArial><FONT color=3D#0000ff><FONT size=3D2>Is there an RFC on =
this?<SPAN=20
    =
class=3D710560322-25072006>&nbsp;</SPAN></FONT></FONT></FONT></FONT></SPA=
N></DIV>
    <DIV dir=3Dltr align=3Dleft><SPAN class=3D693083121-25072006><FONT =
size=3D+0><FONT=20
    face=3DArial><FONT color=3D#0000ff><FONT size=3D2><SPAN=20
    =
class=3D710560322-25072006></SPAN></FONT></FONT></FONT></FONT></SPAN>&nbs=
p;</DIV>
    <DIV dir=3Dltr align=3Dleft><SPAN class=3D693083121-25072006><FONT =
size=3D+0><FONT=20
    face=3DArial><FONT color=3D#0000ff><FONT size=3D2><SPAN=20
    class=3D710560322-25072006>JD:&nbsp; I'm=20
    sure.</SPAN></FONT></FONT></FONT></FONT></SPAN></DIV>
    <DIV dir=3Dltr align=3Dleft><SPAN class=3D693083121-25072006><FONT =
size=3D+0><FONT=20
    face=3DArial><FONT color=3D#0000ff><FONT size=3D2><SPAN=20
    =
class=3D710560322-25072006></SPAN></FONT></FONT></FONT></FONT></SPAN>&nbs=
p;</DIV>
    <DIV dir=3Dltr align=3Dleft><FONT face=3DArial><FONT =
color=3D#0000ff><FONT=20
    size=3D2><SPAN class=3D693083121-25072006>I was unaware that IETF =
ran=20
    </SPAN><SPAN class=3D693083121-25072006>interoperability tests.<SPAN =

    =
class=3D710560322-25072006>&nbsp;</SPAN></SPAN></FONT></FONT></FONT></DIV=
>
    <DIV dir=3Dltr align=3Dleft><FONT face=3DArial><FONT =
color=3D#0000ff><FONT=20
    size=3D2><SPAN class=3D693083121-25072006><SPAN=20
    =
class=3D710560322-25072006></SPAN></SPAN></FONT></FONT></FONT>&nbsp;</DIV=
>
    <DIV dir=3Dltr align=3Dleft><FONT face=3DArial><FONT =
color=3D#0000ff><FONT=20
    size=3D2><SPAN class=3D693083121-25072006><SPAN=20
    class=3D710560322-25072006>JD:&nbsp; I didn't say it did, and I =
don't know if=20
    it does.&nbsp;</SPAN></SPAN></FONT></FONT></FONT></DIV>
    <DIV dir=3Dltr align=3Dleft><SPAN class=3D693083121-25072006><FONT =
face=3DArial=20
    color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
    <DIV dir=3Dltr align=3Dleft><SPAN class=3D693083121-25072006><FONT =
face=3DArial=20
    color=3D#0000ff size=3D2>Cheers,</FONT></SPAN></DIV>
    <DIV dir=3Dltr align=3Dleft><SPAN class=3D693083121-25072006><FONT =
face=3DArial=20
    color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
    <DIV dir=3Dltr align=3Dleft><SPAN class=3D693083121-25072006><FONT =
face=3DArial=20
    color=3D#0000ff size=3D2>Lyndon</FONT></SPAN></DIV><BR>
    <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft>
    <HR tabIndex=3D-1>
    <FONT face=3DTahoma size=3D2><B>From:</B> owner-ccamp@ops.ietf.org=20
    [mailto:owner-ccamp@ops.ietf.org] <B>On Behalf Of </B>Drake, John=20
    E<BR><B>Sent:</B> Tuesday, July 25, 2006 2:28 PM<BR><B>To:</B>=20
    ccamp@ops.ietf.org<BR><B>Subject:</B> RE: Proposed response to OIF =
on OSPF=20
    ENNI<BR></FONT><BR></DIV>
    <DIV></DIV>
    <DIV><FONT color=3Dnavy><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><SPAN=20
    class=3D105092221-25072006><FONT=20
    color=3D#0000ff>&nbsp;Snipped</FONT></SPAN></SPAN></FONT></DIV>
    <DIV><FONT color=3Dnavy><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><SPAN=20
    class=3D105092221-25072006></SPAN></SPAN></FONT>&nbsp;</DIV>
    <DIV><FONT color=3Dnavy><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><SPAN=20
    class=3D105092221-25072006>&nbsp;</SPAN>Regarding Topic=20
    2:<o:p></o:p></SPAN></FONT></DIV>
    <BLOCKQUOTE dir=3Dltr=20
    style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff =
2px solid; MARGIN-RIGHT: 0px">
      <DIV class=3DSection1>
      <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy =
size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
      <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy =
size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
      <P class=3DMsoNormal style=3D"MARGIN-LEFT: 9pt"><FONT =
color=3Dnavy><SPAN=20
      style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Again I =
ask,=20
      wouldn&#8217;t it be better to look at this document which has =
been implemented=20
      by many vendors, and successfully interoperability tested many =
times over=20
      many years to see what can be leveraged instead of starting from=20
      scratch?<FONT color=3D#0000ff><SPAN=20
      class=3D105092221-25072006>&nbsp;</SPAN></FONT></SPAN></FONT></P>
      <P class=3DMsoNormal style=3D"MARGIN-LEFT: 9pt"><FONT =
color=3Dnavy><SPAN=20
      style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><FONT=20
      color=3D#0000ff><SPAN=20
      class=3D105092221-25072006></SPAN></FONT></SPAN></FONT>&nbsp;</P>
      <P class=3DMsoNormal style=3D"MARGIN-LEFT: 9pt"><FONT =
color=3Dnavy><SPAN=20
      style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><FONT=20
      color=3D#0000ff><SPAN class=3D105092221-25072006>JD:&nbsp; I =
noticed that=20
      Jonathan has put in this plug several times.&nbsp; I am wondering =
whether=20
      these events are truly interoperability tests, in the sense that =
the IETF=20
      uses the term, or rather rigged demos?&nbsp; I seem to remember =
that the=20
      OIF characterized itself as a marketing organization.=20
      </SPAN></FONT></SPAN></FONT><FONT face=3DArial color=3Dnavy =
size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
      <DIV>
      <DIV class=3DMsoNormal style=3D"TEXT-ALIGN: center" =
align=3Dcenter><FONT=20
      face=3D"Times New Roman" size=3D3><SPAN style=3D"FONT-SIZE: 12pt">
      <HR tabIndex=3D-1 align=3Dcenter width=3D"100%" SIZE=3D2>
      </SPAN></FONT></DIV>
      <P class=3DMsoNormal><FONT face=3DArial color=3D#0000ff=20
      =
size=3D2></FONT>&nbsp;</P></DIV></DIV></BLOCKQUOTE></BLOCKQUOTE></BLOCKQU=
OTE></BODY></HTML>

------_=_NextPart_001_01C6B03B.0AECFD70--

Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 25 Jul 2006 22:46:06 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Proposed response to OIF on OSPF ENNI
Date: Tue, 25 Jul 2006 18:39:31 -0400
Message-ID: <0901D1988E815341A0103206A834DA07F1A2E1@mdmxm02.ciena.com>
Thread-Topic: Proposed response to OIF on OSPF ENNI
Thread-Index: AcawOdLBXLe3OYUfSKKvtZVe1OwbuAAAUqJA
From: "Ong, Lyndon" <Lyong@Ciena.com>
To: <Dimitri.Papadimitriou@alcatel.be>
Cc: "Adrian Farrel" <adrian@olddog.co.uk>, <ccamp@ops.ietf.org>, "Brungard, Deborah A, ALABS" <dbrungard@att.com>, "Sadler, Jonathan B." <Jonathan.Sadler@tellabs.com>, <owner-ccamp@ops.ietf.org>

I have no objection to this, although I think people know this already.

Lyndon=20

-----Original Message-----
From: Dimitri.Papadimitriou@alcatel.be
[mailto:Dimitri.Papadimitriou@alcatel.be]=20
Sent: Tuesday, July 25, 2006 3:29 PM
To: Ong, Lyndon
Cc: Adrian Farrel; ccamp@ops.ietf.org; Brungard, Deborah A, ALABS;
Sadler, Jonathan B.; owner-ccamp@ops.ietf.org
Subject: RE: Proposed response to OIF on OSPF ENNI

lyndon - this would really be helpful - this said the point is not only
editorial there is an implication as indicated in my previous e-mail

if this OIF IA targets more than documenting demo codepoints
(experimental work remaining at that status), there is a need to warn
OIF about implications i.e. if OIF intents to change the status of this
doc. then the extensions will be de-facto subject to the MPLS/GMPLS
change process from the IETF perspective

i would like to see this point included in the liaison text because
leaving OIF unaware of such process may leave OIF audience uaware of
rule change from what they knew when OIF UNI signaling was conducted in
2001, as of today having demo code doesn't leave the possibility to ask
for std codepoints w/o passing through the complete MPLS/GMPLS change
process
=20
thanks,
- d.

"Ong, Lyndon" <Lyong@Ciena.com>
25/07/2006 23:10
=20
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     "Adrian Farrel" <adrian@olddog.co.uk>,=20
<ccamp@ops.ietf.org>, "Brungard, Deborah A, ALABS" <dbrungard@att.com>,
"Sadler, Jonathan B." <Jonathan.Sadler@tellabs.com>,
<owner-ccamp@ops.ietf.org>
        Subject:        RE: Proposed response to OIF on OSPF ENNI

Hi Dimitri,

Regarding the scope, I don't think the scope is that complicated.
However, I will reflect to OIF that there is confusion about the scope
of the document and as editor will see what I can do to help clarify
these.=20

Cheers,

Lyndon

-----Original Message-----
From: Dimitri.Papadimitriou@alcatel.be
[mailto:Dimitri.Papadimitriou@alcatel.be]
Sent: Tuesday, July 25, 2006 11:11 AM
To: Ong, Lyndon
Cc: Adrian Farrel; ccamp@ops.ietf.org; Brungard, Deborah A, ALABS;
Sadler, Jonathan B.; owner-ccamp@ops.ietf.org
Subject: RE: Proposed response to OIF on OSPF ENNI

lyndon - see my reply to jonathan on this specific point -=20

i can sum'up the evaluation phases lead to different premises and ext.=20
guidelines (in addition to the specific OIF reachability information
encoding) hence, these extensions are not reconcilable without
reconsidering the protocol evaluation itself - it is the basic reason
why i have been so scrupulous in driving this evaluation work as
accurate as possible - and the reason why the proposed liaison text
directly referred to this Section 4.1

ps: could you answer to my previous post ? on OIF IA scope

"Ong, Lyndon" <Lyong@Ciena.com>
25/07/2006 20:01
=20
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     "Adrian Farrel" <adrian@olddog.co.uk>,=20
<ccamp@ops.ietf.org>, "Brungard, Deborah A, ALABS" <dbrungard@att.com>,
"Sadler, Jonathan B." <Jonathan.Sadler@tellabs.com>,
<owner-ccamp@ops.ietf.org>
        Subject:        RE: Proposed response to OIF on OSPF ENNI

Hi Dimitri,

Well, they could of course become agreed standard codepoints if CCAMP
adopted them (unlikely as that appears to be given the past history of
CCAMP and any protocol proposals made by other bodies) hence "at this
time" seemed like a required note.

OIF would of course be very happy if CCAMP agreed to adopt the formats
that were implemented during OIF prototype testing, this is still
possible :o)

Cheers,

Lyndon=20

-----Original Message-----
From: Dimitri.Papadimitriou@alcatel.be
[mailto:Dimitri.Papadimitriou@alcatel.be]
Sent: Tuesday, July 25, 2006 10:54 AM
To: Ong, Lyndon
Cc: Adrian Farrel; ccamp@ops.ietf.org; Brungard, Deborah A, ALABS;
Sadler, Jonathan B.; owner-ccamp@ops.ietf.org
Subject: RE: Proposed response to OIF on OSPF ENNI

lyndon - indeed this is mentioned - the concern here can be formulated
as
follows: section 1.2 of the OIF IA is unclear about positioning and
exact intention with the proposed extensions (in Appendix)=20

"These extensions use codepoints in the range reserved by IANA for
private and experimental use, and are not agreed standard codepoints at
this time.=20
Future developments may result in change to the codepoints and/or
formats of these extensions."=20

you wrote: "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."

the fact that the sentence combines "at this time" and points to
potential "standard codepoints" means that we have to warn OIF about
implication i.e. if OIF intents to change their status (toward standard
codepoints) then the extensions will be de-facto subject to the
MPLS/GMPLS change process from the IETF perspective

ps: this is also the reason why there is a direct relationship between
objective of the document (see previous post) and listed extensions -

"Ong, Lyndon" <Lyong@Ciena.com>
Sent by: owner-ccamp@ops.ietf.org
25/07/2006 18:55
=20
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Sadler,=20
Jonathan B." <Jonathan.Sadler@tellabs.com>
        cc:     "Adrian Farrel" <adrian@olddog.co.uk>,=20
<ccamp@ops.ietf.org>, "Brungard, Deborah A, ALABS" <dbrungard@att.com>,
<owner-ccamp@ops.ietf.org>
        Subject:        RE: Proposed response to OIF on OSPF ENNI

Hi Dimitri,

I completely agree with you that there is much unnecessary hubbub going
on.  The document does in fact point to IETF (and ITU) for standard
extensions to the routing protocols.

>From the discussion I have the sense that there is some unhappiness with
the document focusing on requirements that are still in the process of
being

addressed within CCAMP, but since it points to the drafts being done
here if anything it should focus reader's attention on the work here in
CCAMP rather than anywhere else.=20

Cheers,

Lyndon

-----Original Message-----
From: Dimitri.Papadimitriou@alcatel.be
[mailto:Dimitri.Papadimitriou@alcatel.be]
Sent: Tuesday, July 25, 2006 3:18 AM
To: Sadler, Jonathan B.; Ong, Lyndon
Cc: Adrian Farrel; ccamp@ops.ietf.org; Brungard, Deborah A, ALABS;
owner-ccamp@ops.ietf.org
Subject: RE: Proposed response to OIF on OSPF ENNI

jonathan & lyndon

o) During Dallas CCAMP meeting, IETF 66, we have had the following
discussion (extracted from the meeting minutes)=20

"Kireeti: What would make me happy is not to have extensions defined in
IAs=20
         Work has been done in the IETF. Instead, we will have objects
in the specs and IAs=20
         Putting the extensions in an informational appendix is still
confusing, especially=20
         as vendors have implemented them for demos=20
         I would prefer that you just point to IETF so as extensions
evolve in the IETF, you=20
         stay coordinated
Jim: We [the OIF] don't think that differently=20
     One of our goals is to align and converge.=20
     We understand we are using experimental codepoints"=20

so, it is rather unclear why there is so much hubub when IETF proposes
to achieve this objective ? if i well understand your opinion is that
IETF should not target this objective ? let's assume this is the case,
it still does not allow OIF to bypass the MPLS-GMPLS change process=20

o) concerning the alignment of IETF vs G.7715 and G.7715.1, from the
IETF liaison webpage you will see that a set of exchanges between bodies
has been conducted to ensure such alignment; however, as ITU should be
defining ASON routing requirements your statement "I cannot say that
they are aligned with the requirements of the OIF" is totally unclear to
me.=20
Does OIF has its own requirements or are OIF requirements not fully
aligned with ITU G.7715/.1 ? This question should be reflected in the
liaison to OIF - as a CLEAR response from OIF will surely help sorting
the present situation=20

o) what is the real "issue" by pointing to the addressing i-d, the
latter just provides recommendation in case of 1:1 corr. between data
and control plane entities; i thought ASON was looking at larger scope -
so what's the point beside trying to mis-use any IETF production to
corroborate the GMPLS OSPF digression of Section 4.1 of the OIF IA ?

o) the tone of the OIF IA is its first sections is totally inappropriate
and misleading - so requires major revision - by reading one got the
impression by reading that a) OIF puts premises of a new protocol
recommendation while also stating it is a demo code reporting for a
single level - this must be seriously revisited b) OIF has apparently
discovered major holes and flaws, while issue is limited to unnumbered
links with overlapping ID space per TE Router ID (as detailed in section
5.7 of the eval doc) - alignment on these aspect(s) is also more than
recommended imho=20

o) at the end, the major concern is that it is totally unclear what the
purpose of the OIF IA OSPF extensions are, if the intention of OIF is to
push them outside OIF demo scope (which seems to be the case since the
document passes through OIF ballot process and thus will be openly
available after this phase), then de-facto it is an OIF dutty to ask
IETF for in-depth revision and full alignment before publication=20

ps: to achieve a standard you need running code, but not any running
code becomes a standard even informational (hopefully);

-d.

"Sadler, Jonathan B." <Jonathan.Sadler@tellabs.com> Sent by:
owner-ccamp@ops.ietf.org
24/07/2006 22:31
=20
        To:     "Brungard, Deborah A, ALABS" <dbrungard@att.com>, "Ong,=20
Lyndon" <Lyong@Ciena.com>, <ccamp@ops.ietf.org>
        cc:     "Adrian Farrel" <adrian@olddog.co.uk>
        Subject:        RE: Proposed response to OIF on OSPF ENNI

Hi Deborah, Lyndon, et al,
=20
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.
=20
Given that:
-          CCAMP has a milestone to publish an ASON routing solution by=20
Nov 2006,=20
-          CCAMP didn't have at the time this was liaised (doesn't have=20
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...
=20
Regards,
=20
Jonathan Sadler
=20

From: Ong, Lyndon [mailto:Lyong@Ciena.com]
Sent: Monday, July 24, 2006 2: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
=20
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
-- 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.
=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 conclusions are no
different.
=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".=20
=20
I think we're experiencing a significant miscommunication...
=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"=20
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]
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:=20
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.      What is the intent of this document? Will it be published as an=20
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=20
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.      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).=20
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

Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 25 Jul 2006 22:33:38 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6B03A.4ED5C8F3"
Subject: RE: Proposed response to OIF on OSPF ENNI
Date: Tue, 25 Jul 2006 15:33:10 -0700
Message-ID: <626FC7C6A97381468FB872072AB5DDC8C2DC2A@XCH-SW-42.sw.nos.boeing.com>
Thread-Topic: Proposed response to OIF on OSPF ENNI
Thread-Index: Acas0Ha/aYxFikOBS5m873SVRoVJxgAACLxQAAHPZJAAnZ89IAACGznwAAEH8mAAAxLNQAAAS4QQACJG/RAAAkvKMAANb1UQAABQfIAAASU6IAAAZZ6gAACVGuA=
From: "Drake, John E" <John.E.Drake2@boeing.com>
To: <ccamp@ops.ietf.org>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6B03A.4ED5C8F3
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

That's even worse than what I expected.

	-----Original Message-----
	From: Ong, Lyndon [mailto:Lyong@Ciena.com]=20
	Sent: Tuesday, July 25, 2006 3:22 PM
	To: Drake, John E; ccamp@ops.ietf.org
	Subject: RE: Proposed response to OIF on OSPF ENNI
=09
=09
	I confess it was all rigged, John.  Little midgets were inside
the equipment plugging
	fibers here and there and typing RSVP messages into mini
keypads.
=09
________________________________

	From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]
On Behalf Of Drake, John E
	Sent: Tuesday, July 25, 2006 3:08 PM
	To: ccamp@ops.ietf.org
	Subject: RE: Proposed response to OIF on OSPF ENNI
=09
=09
	=20

		-----Original Message-----
		From: Ong, Lyndon [mailto:Lyong@Ciena.com]=20
		Sent: Tuesday, July 25, 2006 2:39 PM
		To: Drake, John E; ccamp@ops.ietf.org
		Subject: RE: Proposed response to OIF on OSPF ENNI
	=09
	=09
		Hi John,
		=20
		If you wish to discuss how the tests were carried out,
you can talk to the=20
		7 major carriers that provided lab sites and the 13
router and switch vendors that participated
		in the 2005 demo.=20
		=20
		JD:  Just as I suspected=20
		=20
		In what sense does IETF use the term interoperability
test?=20
		=20
		JD:  You know, the stuff required to advance to proposed
standard
		=20
		Is there an RFC on this?=20
		=20
		JD:  I'm sure.
		=20
		I was unaware that IETF ran interoperability tests.=20
		=20
		JD:  I didn't say it did, and I don't know if it does.=20
		=20
		Cheers,
		=20
		Lyndon

________________________________

		From: owner-ccamp@ops.ietf.org
[mailto:owner-ccamp@ops.ietf.org] On Behalf Of Drake, John E
		Sent: Tuesday, July 25, 2006 2:28 PM
		To: ccamp@ops.ietf.org
		Subject: RE: Proposed response to OIF on OSPF ENNI
	=09
	=09
		 Snipped
		=20
		 Regarding Topic 2:

			=20

			=20

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

			=20

			JD:  I noticed that Jonathan has put in this
plug several times.  I am wondering whether these events are truly
interoperability tests, in the sense that the IETF uses the term, or
rather rigged demos?  I seem to remember that the OIF characterized
itself as a marketing organization. =20

		=09
________________________________

			=20

------_=_NextPart_001_01C6B03A.4ED5C8F3
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:v =3D=20
"urn:schemas-microsoft-com:vml" xmlns:o =3D=20
"urn:schemas-microsoft-com:office:office" xmlns:w =3D=20
"urn:schemas-microsoft-com:office:word" xmlns:p =3D=20
"urn:schemas-microsoft-com:office:powerpoint" xmlns:oa =3D=20
"urn:schemas-microsoft-com:office:activation" xmlns:st1 =3D=20
"urn:schemas-microsoft-com:office:smarttags"><HEAD><TITLE>Message</TITLE>=

<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1556" name=3DGENERATOR><!--[if !mso]>
<STYLE>v\:* {
	BEHAVIOR: url(#default#VML)
}
o\:* {
	BEHAVIOR: url(#default#VML)
}
w\:* {
	BEHAVIOR: url(#default#VML)
}
.shape {
	BEHAVIOR: url(#default#VML)
}
</STYLE>
<![endif]--><o:SmartTagType=20
downloadurl=3D"http://www.5iamas-microsoft-com:office:smarttags" =
name=3D"State"=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTagT=
ype><o:SmartTagType=20
downloadurl=3D"http://www.5iamas-microsoft-com:office:smarttags" =
name=3D"City"=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTagT=
ype><o:SmartTagType=20
downloadurl=3D"http://www.5iantlavalamp.com/" name=3D"place"=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTagT=
ype><o:SmartTagType=20
downloadurl=3D"http://www.microsoft.com" name=3D"PersonName"=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTagT=
ype><!--[if !mso]>
<STYLE>st1\:* {
	BEHAVIOR: url(#default#ieooui)
}
</STYLE>
<![endif]-->
<STYLE>@font-face {
	font-family: Wingdings;
}
@font-face {
	font-family: MS Mincho;
}
@font-face {
	font-family: Tahoma;
}
@font-face {
	font-family: @MS Mincho;
}
@page Section1 {size: 8.5in 11.0in; margin: 1.0in 1.25in 1.0in 1.25in; }
P.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
LI.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
DIV.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline
}
A:visited {
	COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlinkFollowed {
	COLOR: blue; TEXT-DECORATION: underline
}
PRE {
	FONT-SIZE: 10pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Courier New"
}
SPAN.EmailStyle18 {
	COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal
}
SPAN.EmailStyle19 {
	COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal
}
SPAN.EmailStyle20 {
	COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal
}
SPAN.EmailStyle21 {
	COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal-reply
}
DIV.Section1 {
	page: Section1
}
OL {
	MARGIN-BOTTOM: 0in
}
UL {
	MARGIN-BOTTOM: 0in
}
</STYLE>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]--></HEAD>
<BODY lang=3DEN-US vLink=3Dblue link=3Dblue><![if =
!supportLists]><![endif]><![if !supportLists]><![endif]><![if =
!supportLists]><![endif]><![if !supportLists]><![endif]><![if =
!supportLists]><![endif]>
<DIV><SPAN class=3D264593122-25072006><FONT face=3DArial color=3D#0000ff =
size=3D2>That's=20
even worse than what I expected.</FONT></SPAN></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
  face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B> Ong, =
Lyndon=20
  [mailto:Lyong@Ciena.com] <BR><B>Sent:</B> Tuesday, July 25, 2006 3:22=20
  PM<BR><B>To:</B> Drake, John E; ccamp@ops.ietf.org<BR><B>Subject:</B> =
RE:=20
  Proposed response to OIF on OSPF ENNI<BR><BR></FONT></DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN =
class=3D442181522-25072006></SPAN><FONT=20
  face=3DArial><FONT color=3D#0000ff><FONT size=3D2>I<SPAN =
class=3D442181522-25072006>=20
  confess it</SPAN><SPAN class=3D442181522-25072006>&nbsp;was all =
rigged,=20
  John.&nbsp; Little midgets were inside the equipment=20
  plugging</SPAN></FONT></FONT></FONT></DIV>
  <DIV dir=3Dltr align=3Dleft><FONT size=3D+0><FONT =
color=3D#0000ff><FONT size=3D2><SPAN=20
  class=3D442181522-25072006></SPAN></FONT></FONT></FONT><SPAN=20
  class=3D442181522-25072006></SPAN><FONT face=3DArial><FONT =
color=3D#0000ff><FONT=20
  size=3D2>f<SPAN class=3D442181522-25072006>ibers here and there and =
typing RSVP=20
  messages into mini keypads.</SPAN></FONT></FONT></FONT><BR></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
  <HR tabIndex=3D-1>
  <FONT face=3DTahoma size=3D2><B>From:</B> owner-ccamp@ops.ietf.org=20
  [mailto:owner-ccamp@ops.ietf.org] <B>On Behalf Of </B>Drake, John=20
  E<BR><B>Sent:</B> Tuesday, July 25, 2006 3:08 PM<BR><B>To:</B>=20
  ccamp@ops.ietf.org<BR><B>Subject:</B> RE: Proposed response to OIF on =
OSPF=20
  ENNI<BR></FONT><BR></DIV>
  <DIV></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT>&nbsp;</DIV>
  <BLOCKQUOTE dir=3Dltr=20
  style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
    <DIV></DIV>
    <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
    face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B> =
Ong, Lyndon=20
    [mailto:Lyong@Ciena.com] <BR><B>Sent:</B> Tuesday, July 25, 2006 =
2:39=20
    PM<BR><B>To:</B> Drake, John E; =
ccamp@ops.ietf.org<BR><B>Subject:</B> RE:=20
    Proposed response to OIF on OSPF ENNI<BR><BR></FONT></DIV>
    <DIV dir=3Dltr align=3Dleft><SPAN class=3D693083121-25072006><FONT =
face=3DArial=20
    color=3D#0000ff size=3D2>Hi John,</FONT></SPAN></DIV>
    <DIV dir=3Dltr align=3Dleft><SPAN class=3D693083121-25072006><FONT =
face=3DArial=20
    color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
    <DIV dir=3Dltr align=3Dleft><SPAN class=3D693083121-25072006><FONT =
face=3DArial=20
    color=3D#0000ff size=3D2>If you wish to discuss how the tests were =
carried out,=20
    you can talk to the </FONT></SPAN></DIV>
    <DIV dir=3Dltr align=3Dleft><SPAN class=3D693083121-25072006><FONT =
face=3DArial=20
    color=3D#0000ff size=3D2>7 major carriers that provided lab sites =
and the 13=20
    router and switch vendors that participated</FONT></SPAN></DIV>
    <DIV dir=3Dltr align=3Dleft><SPAN class=3D693083121-25072006><FONT=20
    face=3DArial><FONT color=3D#0000ff><FONT size=3D2>in the 2005 =
demo.<SPAN=20
    =
class=3D710560322-25072006>&nbsp;</SPAN></FONT></FONT></FONT></SPAN></DIV=
>
    <DIV dir=3Dltr align=3Dleft><SPAN class=3D693083121-25072006><FONT=20
    face=3DArial><FONT color=3D#0000ff><FONT size=3D2><SPAN=20
    =
class=3D710560322-25072006></SPAN></FONT></FONT></FONT></SPAN>&nbsp;</DIV=
>
    <DIV dir=3Dltr align=3Dleft><SPAN class=3D693083121-25072006><FONT=20
    face=3DArial><FONT color=3D#0000ff><FONT size=3D2><SPAN=20
    class=3D710560322-25072006>JD:&nbsp; Just as I=20
    suspected&nbsp;</SPAN></FONT></FONT></FONT></SPAN></DIV>
    <DIV dir=3Dltr align=3Dleft><SPAN class=3D693083121-25072006><FONT =
face=3DArial=20
    color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
    <DIV dir=3Dltr align=3Dleft><SPAN class=3D693083121-25072006><FONT =
face=3DArial=20
    color=3D#0000ff size=3D2>In what sense does IETF use the term =
interoperability=20
    test?<SPAN =
class=3D710560322-25072006>&nbsp;</SPAN></FONT></SPAN></DIV>
    <DIV dir=3Dltr align=3Dleft><SPAN class=3D693083121-25072006><FONT =
face=3DArial=20
    color=3D#0000ff size=3D2><SPAN=20
    class=3D710560322-25072006></SPAN></FONT></SPAN>&nbsp;</DIV>
    <DIV dir=3Dltr align=3Dleft><SPAN class=3D693083121-25072006><FONT =
face=3DArial=20
    color=3D#0000ff size=3D2><SPAN class=3D710560322-25072006>JD:&nbsp; =
You know, the=20
    stuff required to advance&nbsp;to proposed=20
    standard</SPAN></FONT></SPAN></DIV>
    <DIV dir=3Dltr align=3Dleft><SPAN class=3D693083121-25072006><FONT =
face=3DArial=20
    color=3D#0000ff size=3D2><SPAN=20
    class=3D710560322-25072006></SPAN></FONT></SPAN>&nbsp;</DIV>
    <DIV dir=3Dltr align=3Dleft><SPAN class=3D693083121-25072006><FONT =
size=3D+0><FONT=20
    face=3DArial><FONT color=3D#0000ff><FONT size=3D2>Is there an RFC on =
this?<SPAN=20
    =
class=3D710560322-25072006>&nbsp;</SPAN></FONT></FONT></FONT></FONT></SPA=
N></DIV>
    <DIV dir=3Dltr align=3Dleft><SPAN class=3D693083121-25072006><FONT =
size=3D+0><FONT=20
    face=3DArial><FONT color=3D#0000ff><FONT size=3D2><SPAN=20
    =
class=3D710560322-25072006></SPAN></FONT></FONT></FONT></FONT></SPAN>&nbs=
p;</DIV>
    <DIV dir=3Dltr align=3Dleft><SPAN class=3D693083121-25072006><FONT =
size=3D+0><FONT=20
    face=3DArial><FONT color=3D#0000ff><FONT size=3D2><SPAN=20
    class=3D710560322-25072006>JD:&nbsp; I'm=20
    sure.</SPAN></FONT></FONT></FONT></FONT></SPAN></DIV>
    <DIV dir=3Dltr align=3Dleft><SPAN class=3D693083121-25072006><FONT =
size=3D+0><FONT=20
    face=3DArial><FONT color=3D#0000ff><FONT size=3D2><SPAN=20
    =
class=3D710560322-25072006></SPAN></FONT></FONT></FONT></FONT></SPAN>&nbs=
p;</DIV>
    <DIV dir=3Dltr align=3Dleft><FONT face=3DArial><FONT =
color=3D#0000ff><FONT=20
    size=3D2><SPAN class=3D693083121-25072006>I was unaware that IETF =
ran=20
    </SPAN><SPAN class=3D693083121-25072006>interoperability tests.<SPAN =

    =
class=3D710560322-25072006>&nbsp;</SPAN></SPAN></FONT></FONT></FONT></DIV=
>
    <DIV dir=3Dltr align=3Dleft><FONT face=3DArial><FONT =
color=3D#0000ff><FONT=20
    size=3D2><SPAN class=3D693083121-25072006><SPAN=20
    =
class=3D710560322-25072006></SPAN></SPAN></FONT></FONT></FONT>&nbsp;</DIV=
>
    <DIV dir=3Dltr align=3Dleft><FONT face=3DArial><FONT =
color=3D#0000ff><FONT=20
    size=3D2><SPAN class=3D693083121-25072006><SPAN=20
    class=3D710560322-25072006>JD:&nbsp; I didn't say it did, and I =
don't know if=20
    it does.&nbsp;</SPAN></SPAN></FONT></FONT></FONT></DIV>
    <DIV dir=3Dltr align=3Dleft><SPAN class=3D693083121-25072006><FONT =
face=3DArial=20
    color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
    <DIV dir=3Dltr align=3Dleft><SPAN class=3D693083121-25072006><FONT =
face=3DArial=20
    color=3D#0000ff size=3D2>Cheers,</FONT></SPAN></DIV>
    <DIV dir=3Dltr align=3Dleft><SPAN class=3D693083121-25072006><FONT =
face=3DArial=20
    color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
    <DIV dir=3Dltr align=3Dleft><SPAN class=3D693083121-25072006><FONT =
face=3DArial=20
    color=3D#0000ff size=3D2>Lyndon</FONT></SPAN></DIV><BR>
    <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft>
    <HR tabIndex=3D-1>
    <FONT face=3DTahoma size=3D2><B>From:</B> owner-ccamp@ops.ietf.org=20
    [mailto:owner-ccamp@ops.ietf.org] <B>On Behalf Of </B>Drake, John=20
    E<BR><B>Sent:</B> Tuesday, July 25, 2006 2:28 PM<BR><B>To:</B>=20
    ccamp@ops.ietf.org<BR><B>Subject:</B> RE: Proposed response to OIF =
on OSPF=20
    ENNI<BR></FONT><BR></DIV>
    <DIV></DIV>
    <DIV><FONT color=3Dnavy><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><SPAN=20
    class=3D105092221-25072006><FONT=20
    color=3D#0000ff>&nbsp;Snipped</FONT></SPAN></SPAN></FONT></DIV>
    <DIV><FONT color=3Dnavy><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><SPAN=20
    class=3D105092221-25072006></SPAN></SPAN></FONT>&nbsp;</DIV>
    <DIV><FONT color=3Dnavy><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><SPAN=20
    class=3D105092221-25072006>&nbsp;</SPAN>Regarding Topic=20
    2:<o:p></o:p></SPAN></FONT></DIV>
    <BLOCKQUOTE dir=3Dltr=20
    style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff =
2px solid; MARGIN-RIGHT: 0px">
      <DIV class=3DSection1>
      <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy =
size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
      <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy =
size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
      <P class=3DMsoNormal style=3D"MARGIN-LEFT: 9pt"><FONT =
color=3Dnavy><SPAN=20
      style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Again I =
ask,=20
      wouldn&#8217;t it be better to look at this document which has =
been implemented=20
      by many vendors, and successfully interoperability tested many =
times over=20
      many years to see what can be leveraged instead of starting from=20
      scratch?<FONT color=3D#0000ff><SPAN=20
      class=3D105092221-25072006>&nbsp;</SPAN></FONT></SPAN></FONT></P>
      <P class=3DMsoNormal style=3D"MARGIN-LEFT: 9pt"><FONT =
color=3Dnavy><SPAN=20
      style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><FONT=20
      color=3D#0000ff><SPAN=20
      class=3D105092221-25072006></SPAN></FONT></SPAN></FONT>&nbsp;</P>
      <P class=3DMsoNormal style=3D"MARGIN-LEFT: 9pt"><FONT =
color=3Dnavy><SPAN=20
      style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><FONT=20
      color=3D#0000ff><SPAN class=3D105092221-25072006>JD:&nbsp; I =
noticed that=20
      Jonathan has put in this plug several times.&nbsp; I am wondering =
whether=20
      these events are truly interoperability tests, in the sense that =
the IETF=20
      uses the term, or rather rigged demos?&nbsp; I seem to remember =
that the=20
      OIF characterized itself as a marketing organization.=20
      </SPAN></FONT></SPAN></FONT><FONT face=3DArial color=3Dnavy =
size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
      <DIV>
      <DIV class=3DMsoNormal style=3D"TEXT-ALIGN: center" =
align=3Dcenter><FONT=20
      face=3D"Times New Roman" size=3D3><SPAN style=3D"FONT-SIZE: 12pt">
      <HR tabIndex=3D-1 align=3Dcenter width=3D"100%" SIZE=3D2>
      </SPAN></FONT></DIV>
      <P class=3DMsoNormal><FONT face=3DArial color=3D#0000ff=20
      =
size=3D2></FONT>&nbsp;</P></DIV></DIV></BLOCKQUOTE></BLOCKQUOTE></BLOCKQU=
OTE></BODY></HTML>

------_=_NextPart_001_01C6B03A.4ED5C8F3--

Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 25 Jul 2006 22:30:04 +0000
To: "Ong, Lyndon" <Lyong@Ciena.com>
Cc: "Adrian Farrel" <adrian@olddog.co.uk>, ccamp@ops.ietf.org, "Brungard, Deborah A, ALABS" <dbrungard@att.com>, "Sadler, Jonathan B." <Jonathan.Sadler@tellabs.com>, owner-ccamp@ops.ietf.org
Subject: RE: Proposed response to OIF on OSPF ENNI
MIME-Version: 1.0
Message-ID: <OF199ECA6A.C278B754-ONC12571B6.00775C42-C12571B6.007B8B9E@netfr.alcatel.fr>
From: Dimitri.Papadimitriou@alcatel.be
Date: Wed, 26 Jul 2006 00:29:25 +0200
Content-Type: text/plain; charset="US-ASCII"

lyndon - this would really be helpful - this said the point is not only 
editorial there is an implication as indicated in my previous e-mail

if this OIF IA targets more than documenting demo codepoints (experimental 
work remaining at that status), there is a need to warn OIF about 
implications i.e. if OIF intents to change the status of this doc. then 
the extensions will be de-facto subject to the MPLS/GMPLS change process 
from the IETF perspective

i would like to see this point included in the liaison text because 
leaving OIF unaware of such process may leave OIF audience uaware of rule 
change from what they knew when OIF UNI signaling was conducted in 2001, 
as of today having demo code doesn't leave the possibility to ask for std 
codepoints w/o passing through the complete MPLS/GMPLS change process

thanks,
- d.

"Ong, Lyndon" <Lyong@Ciena.com>
25/07/2006 23:10

        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     "Adrian Farrel" <adrian@olddog.co.uk>, 
<ccamp@ops.ietf.org>, "Brungard, Deborah A, ALABS" <dbrungard@att.com>, 
"Sadler, Jonathan B." <Jonathan.Sadler@tellabs.com>, 
<owner-ccamp@ops.ietf.org>
        Subject:        RE: Proposed response to OIF on OSPF ENNI

Hi Dimitri,

Regarding the scope, I don't think the scope is that complicated.
However, I will reflect to OIF that there is confusion about the scope
of the document and as editor will see what I
can do to help clarify these. 

Cheers,

Lyndon

-----Original Message-----
From: Dimitri.Papadimitriou@alcatel.be
[mailto:Dimitri.Papadimitriou@alcatel.be] 
Sent: Tuesday, July 25, 2006 11:11 AM
To: Ong, Lyndon
Cc: Adrian Farrel; ccamp@ops.ietf.org; Brungard, Deborah A, ALABS;
Sadler, Jonathan B.; owner-ccamp@ops.ietf.org
Subject: RE: Proposed response to OIF on OSPF ENNI

lyndon - see my reply to jonathan on this specific point - 

i can sum'up the evaluation phases lead to different premises and ext. 
guidelines (in addition to the specific OIF reachability information
encoding) hence, these extensions are not reconcilable without
reconsidering the protocol evaluation itself - it is the basic reason
why i have been so scrupulous in driving this evaluation work as
accurate as possible - and the reason why the proposed liaison text
directly referred to this Section 4.1

ps: could you answer to my previous post ? on OIF IA scope

"Ong, Lyndon" <Lyong@Ciena.com>
25/07/2006 20:01

        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     "Adrian Farrel" <adrian@olddog.co.uk>, 
<ccamp@ops.ietf.org>, "Brungard, Deborah A, ALABS" <dbrungard@att.com>,
"Sadler, Jonathan B." <Jonathan.Sadler@tellabs.com>,
<owner-ccamp@ops.ietf.org>
        Subject:        RE: Proposed response to OIF on OSPF ENNI

Hi Dimitri,

Well, they could of course become agreed standard codepoints if CCAMP
adopted them (unlikely as that appears to be given the past history of
CCAMP and any protocol proposals made by other bodies) hence "at this
time" seemed like a required note.

OIF would of course be very happy if CCAMP agreed to adopt the formats
that were implemented during OIF prototype testing, this is still
possible :o)

Cheers,

Lyndon 

-----Original Message-----
From: Dimitri.Papadimitriou@alcatel.be
[mailto:Dimitri.Papadimitriou@alcatel.be]
Sent: Tuesday, July 25, 2006 10:54 AM
To: Ong, Lyndon
Cc: Adrian Farrel; ccamp@ops.ietf.org; Brungard, Deborah A, ALABS;
Sadler, Jonathan B.; owner-ccamp@ops.ietf.org
Subject: RE: Proposed response to OIF on OSPF ENNI

lyndon - indeed this is mentioned - the concern here can be formulated
as
follows: section 1.2 of the OIF IA is unclear about positioning and
exact intention with 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." 

you wrote: "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."

the fact that the sentence combines "at this time" and points to
potential "standard codepoints" means that we have to warn OIF about
implication i.e. if OIF intents to change their status (toward standard
codepoints) then the extensions will be de-facto subject to the
MPLS/GMPLS change process from the IETF perspective

ps: this is also the reason why there is a direct relationship between
objective of the document (see previous post) and listed extensions -

"Ong, Lyndon" <Lyong@Ciena.com>
Sent by: owner-ccamp@ops.ietf.org
25/07/2006 18:55

        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Sadler, 
Jonathan B." <Jonathan.Sadler@tellabs.com>
        cc:     "Adrian Farrel" <adrian@olddog.co.uk>, 
<ccamp@ops.ietf.org>, "Brungard, Deborah A, ALABS" <dbrungard@att.com>,
<owner-ccamp@ops.ietf.org>
        Subject:        RE: Proposed response to OIF on OSPF ENNI

Hi Dimitri,

I completely agree with you that there is much unnecessary hubbub
going on.  The document does in fact point to IETF (and ITU) for
standard extensions to the routing protocols.

>From the discussion I have the sense that there is some unhappiness with
the
document focusing on requirements that are still in the process of being

addressed within CCAMP, but since it points to the drafts being done
here
if anything it should focus reader's attention on the work here in CCAMP
rather than anywhere else. 

Cheers,

Lyndon

-----Original Message-----
From: Dimitri.Papadimitriou@alcatel.be
[mailto:Dimitri.Papadimitriou@alcatel.be] 
Sent: Tuesday, July 25, 2006 3:18 AM
To: Sadler, Jonathan B.; Ong, Lyndon
Cc: Adrian Farrel; ccamp@ops.ietf.org; Brungard, Deborah A, ALABS;
owner-ccamp@ops.ietf.org
Subject: RE: Proposed response to OIF on OSPF ENNI

jonathan & lyndon

o) During Dallas CCAMP meeting, IETF 66, we have had the following
discussion (extracted from the meeting minutes) 

"Kireeti: What would make me happy is not to have extensions defined in
IAs 
         Work has been done in the IETF. Instead, we will have objects
in the specs and IAs 
         Putting the extensions in an informational appendix is still
confusing, especially 
         as vendors have implemented them for demos 
         I would prefer that you just point to IETF so as extensions
evolve in the IETF, you 
         stay coordinated
Jim: We [the OIF] don't think that differently 
     One of our goals is to align and converge. 
     We understand we are using experimental codepoints" 

so, it is rather unclear why there is so much hubub when IETF proposes
to achieve this objective ? if i well understand your opinion is that
IETF should not target this objective ? let's assume this is the case,
it still does not allow OIF to bypass the MPLS-GMPLS change process 

o) concerning the alignment of IETF vs G.7715 and G.7715.1, from the
IETF liaison webpage you will see that a set of exchanges between bodies
has been conducted to ensure such alignment; however, as ITU should be
defining ASON routing requirements your statement "I cannot say that
they are aligned with the requirements of the OIF" is totally unclear to
me. 
Does OIF has its own requirements or are OIF requirements not fully
aligned with ITU G.7715/.1 ? This question should be reflected in the
liaison to OIF - as a CLEAR response from OIF will surely help sorting
the present situation 

o) what is the real "issue" by pointing to the addressing i-d, the
latter just provides recommendation in case of 1:1 corr. between data
and control plane entities; i thought ASON was looking at larger scope -
so what's the point beside trying to mis-use any IETF production to
corroborate the GMPLS OSPF digression of Section 4.1 of the OIF IA ?

o) the tone of the OIF IA is its first sections is totally inappropriate
and misleading - so requires major revision - by reading one got the
impression by reading that a) OIF puts premises of a new protocol
recommendation while also stating it is a demo code reporting for a
single level - this must be seriously revisited b) OIF has apparently
discovered major holes and flaws, while issue is limited to unnumbered
links with overlapping ID space per TE Router ID (as detailed in section
5.7 of the eval doc) - alignment on these aspect(s) is also more than
recommended imho 

o) at the end, the major concern is that it is totally unclear what the
purpose of the OIF IA OSPF extensions are, if the intention of OIF is to
push them outside OIF demo scope (which seems to be the case since the
document passes through OIF ballot process and thus will be openly
available after this phase), then de-facto it is an OIF dutty to ask
IETF for in-depth revision and full alignment before publication 

ps: to achieve a standard you need running code, but not any running
code becomes a standard even informational (hopefully);

-d.

"Sadler, Jonathan B." <Jonathan.Sadler@tellabs.com> Sent by:
owner-ccamp@ops.ietf.org
24/07/2006 22:31

        To:     "Brungard, Deborah A, ALABS" <dbrungard@att.com>, "Ong, 
Lyndon" <Lyong@Ciena.com>, <ccamp@ops.ietf.org>
        cc:     "Adrian Farrel" <adrian@olddog.co.uk>
        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:Lyong@Ciena.com]
Sent: Monday, July 24, 2006 2: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,

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: 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),

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:Jonathan.Sadler@tellabs.com]
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,

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

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.

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

Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 25 Jul 2006 22:25:49 +0000
To: "Payam Torab" <ptorab@lopsys.com>
Cc: ccamp@ops.ietf.org, "'Dave Walters'" <dwalters@lopsys.com>, owner-ccamp@ops.ietf.org
Subject: Re: shared mesh restoration - e2e recovery signaling draft
MIME-Version: 1.0
Message-ID: <OF6993F566.DD842D9C-ONC12571B6.007A605B-C12571B6.007B2C12@netfr.alcatel.fr>
From: Dimitri.Papadimitriou@alcatel.be
Date: Wed, 26 Jul 2006 00:25:20 +0200
Content-Type: text/plain; charset="US-ASCII"

hi 

your question is in a shared mesh case, are the ingress nodes (N-1) 
notified about the use of the recovery path by the remaining ingress node 
part of the same shared mesh group

answer is yes - you can notify the other ingresses by sending a PathErr of 
Notify msg - the error code defined for this case is "Notify Error/LSP 
Locally Failed" - 

much thanks,
- dimitri.

"Payam Torab" <ptorab@lopsys.com>
Sent by: owner-ccamp@ops.ietf.org
26/07/2006 00:11

        To:     <ccamp@ops.ietf.org>
        cc:     "'Dave Walters'" <dwalters@lopsys.com>
        Subject:        shared mesh restoration - e2e recovery signaling 
draft

In the e2e recovery signaling draft 
(draft-ietf-ccamp-gmpls-recovery-e2e-signaling-03.txt), there is a 
procedure defined for a node on the shared restoration path to notify 
other nodes regarding the working LSPs that become vulnerable as a result 
of switching to the shared restoration path.

It seems there is a similar need to notify these nodes once the shared 
restoration path becomes available again. Is this mechanism defined 
anywhere?

Thanks,
Payam

Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 25 Jul 2006 22:23:55 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6B038.CB1A8E6C"
Subject: RE: Proposed response to OIF on OSPF ENNI
Date: Tue, 25 Jul 2006 18:22:19 -0400
Message-ID: <0901D1988E815341A0103206A834DA07F1A2DB@mdmxm02.ciena.com>
Thread-Topic: Proposed response to OIF on OSPF ENNI
Thread-Index: Acas0Ha/aYxFikOBS5m873SVRoVJxgAACLxQAAHPZJAAnZ89IAACGznwAAEH8mAAAxLNQAAAS4QQACJG/RAAAkvKMAANb1UQAABQfIAAASU6IAAAZZ6g
From: "Ong, Lyndon" <Lyong@Ciena.com>
To: "Drake, John E" <John.E.Drake2@boeing.com>, <ccamp@ops.ietf.org>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6B038.CB1A8E6C
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I confess it was all rigged, John.  Little midgets were inside the
equipment plugging
fibers here and there and typing RSVP messages into mini keypads.

________________________________

From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On
Behalf Of Drake, John E
Sent: Tuesday, July 25, 2006 3:08 PM
To: ccamp@ops.ietf.org
Subject: RE: Proposed response to OIF on OSPF ENNI

=20

	-----Original Message-----
	From: Ong, Lyndon [mailto:Lyong@Ciena.com]=20
	Sent: Tuesday, July 25, 2006 2:39 PM
	To: Drake, John E; ccamp@ops.ietf.org
	Subject: RE: Proposed response to OIF on OSPF ENNI
=09
=09
	Hi John,
	=20
	If you wish to discuss how the tests were carried out, you can
talk to the=20
	7 major carriers that provided lab sites and the 13 router and
switch vendors that participated
	in the 2005 demo.=20
	=20
	JD:  Just as I suspected=20
	=20
	In what sense does IETF use the term interoperability test?=20
	=20
	JD:  You know, the stuff required to advance to proposed
standard
	=20
	Is there an RFC on this?=20
	=20
	JD:  I'm sure.
	=20
	I was unaware that IETF ran interoperability tests.=20
	=20
	JD:  I didn't say it did, and I don't know if it does.=20
	=20
	Cheers,
	=20
	Lyndon

________________________________

	From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]
On Behalf Of Drake, John E
	Sent: Tuesday, July 25, 2006 2:28 PM
	To: ccamp@ops.ietf.org
	Subject: RE: Proposed response to OIF on OSPF ENNI
=09
=09
	 Snipped
	=20
	 Regarding Topic 2:

		=20

		=20

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

		=20

		JD:  I noticed that Jonathan has put in this plug
several times.  I am wondering whether these events are truly
interoperability tests, in the sense that the IETF uses the term, or
rather rigged demos?  I seem to remember that the OIF characterized
itself as a marketing organization. =20

	=09
________________________________

		=20

------_=_NextPart_001_01C6B038.CB1A8E6C
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:v =3D=20
"urn:schemas-microsoft-com:vml" xmlns:o =3D=20
"urn:schemas-microsoft-com:office:office" xmlns:w =3D=20
"urn:schemas-microsoft-com:office:word" xmlns:p =3D=20
"urn:schemas-microsoft-com:office:powerpoint" xmlns:oa =3D=20
"urn:schemas-microsoft-com:office:activation" xmlns:st1 =3D=20
"urn:schemas-microsoft-com:office:smarttags"><HEAD><TITLE>Message</TITLE>=

<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.2912" name=3DGENERATOR><!--[if !mso]>
<STYLE>v\:* {
	BEHAVIOR: url(#default#VML)
}
o\:* {
	BEHAVIOR: url(#default#VML)
}
w\:* {
	BEHAVIOR: url(#default#VML)
}
.shape {
	BEHAVIOR: url(#default#VML)
}
</STYLE>
<![endif]--><o:SmartTagType=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" =
name=3D"State"=20
downloadurl=3D"http://www.5iamas-microsoft-com:office:smarttags"></o:Smar=
tTagType><o:SmartTagType=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" =
name=3D"City"=20
downloadurl=3D"http://www.5iamas-microsoft-com:office:smarttags"></o:Smar=
tTagType><o:SmartTagType=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" =
name=3D"place"=20
downloadurl=3D"http://www.5iantlavalamp.com/"></o:SmartTagType><o:SmartTa=
gType=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" =
name=3D"PersonName"=20
downloadurl=3D"http://www.microsoft.com"></o:SmartTagType><!--[if !mso]>
<STYLE>st1\:* {
	BEHAVIOR: url(#default#ieooui)
}
</STYLE>
<![endif]-->
<STYLE>@font-face {
	font-family: Wingdings;
}
@font-face {
	font-family: MS Mincho;
}
@font-face {
	font-family: Tahoma;
}
@font-face {
	font-family: @MS Mincho;
}
@page Section1 {size: 8.5in 11.0in; margin: 1.0in 1.25in 1.0in 1.25in; }
P.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
LI.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
DIV.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline
}
A:visited {
	COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlinkFollowed {
	COLOR: blue; TEXT-DECORATION: underline
}
PRE {
	FONT-SIZE: 10pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Courier New"
}
SPAN.EmailStyle18 {
	COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal
}
SPAN.EmailStyle19 {
	COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal
}
SPAN.EmailStyle20 {
	COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal
}
SPAN.EmailStyle21 {
	COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal-reply
}
DIV.Section1 {
	page: Section1
}
OL {
	MARGIN-BOTTOM: 0in
}
UL {
	MARGIN-BOTTOM: 0in
}
</STYLE>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]--></HEAD>
<BODY lang=3DEN-US vLink=3Dblue link=3Dblue><![if =
!supportLists]><![endif]><![if !supportLists]><![endif]><![if =
!supportLists]><![endif]><![if !supportLists]><![endif]><![if =
!supportLists]><![endif]>
<DIV dir=3Dltr align=3Dleft><SPAN =
class=3D442181522-25072006></SPAN><FONT=20
face=3DArial><FONT color=3D#0000ff><FONT size=3D2>I<SPAN =
class=3D442181522-25072006>=20
confess it</SPAN><SPAN class=3D442181522-25072006>&nbsp;was all rigged,=20
John.&nbsp; Little midgets were inside the equipment=20
plugging</SPAN></FONT></FONT></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT><FONT color=3D#0000ff><FONT =
size=3D2><SPAN=20
class=3D442181522-25072006></SPAN></FONT></FONT></FONT><SPAN=20
class=3D442181522-25072006></SPAN><FONT face=3DArial><FONT =
color=3D#0000ff><FONT=20
size=3D2>f<SPAN class=3D442181522-25072006>ibers here and there and =
typing RSVP=20
messages into mini keypads.</SPAN></FONT></FONT></FONT><BR></DIV>
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
<HR tabIndex=3D-1>
<FONT face=3DTahoma size=3D2><B>From:</B> owner-ccamp@ops.ietf.org=20
[mailto:owner-ccamp@ops.ietf.org] <B>On Behalf Of </B>Drake, John=20
E<BR><B>Sent:</B> Tuesday, July 25, 2006 3:08 PM<BR><B>To:</B>=20
ccamp@ops.ietf.org<BR><B>Subject:</B> RE: Proposed response to OIF on =
OSPF=20
ENNI<BR></FONT><BR></DIV>
<DIV></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT>&nbsp;</DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
  face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B> Ong, =
Lyndon=20
  [mailto:Lyong@Ciena.com] <BR><B>Sent:</B> Tuesday, July 25, 2006 2:39=20
  PM<BR><B>To:</B> Drake, John E; ccamp@ops.ietf.org<BR><B>Subject:</B> =
RE:=20
  Proposed response to OIF on OSPF ENNI<BR><BR></FONT></DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D693083121-25072006><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2>Hi John,</FONT></SPAN></DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D693083121-25072006><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D693083121-25072006><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2>If you wish to discuss how the tests were =
carried out,=20
  you can talk to the </FONT></SPAN></DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D693083121-25072006><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2>7 major carriers that provided lab sites and =
the 13=20
  router and switch vendors that participated</FONT></SPAN></DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D693083121-25072006><FONT =
face=3DArial><FONT=20
  color=3D#0000ff><FONT size=3D2>in the 2005 demo.<SPAN=20
  =
class=3D710560322-25072006>&nbsp;</SPAN></FONT></FONT></FONT></SPAN></DIV=
>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D693083121-25072006><FONT =
face=3DArial><FONT=20
  color=3D#0000ff><FONT size=3D2><SPAN=20
  =
class=3D710560322-25072006></SPAN></FONT></FONT></FONT></SPAN>&nbsp;</DIV=
>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D693083121-25072006><FONT =
face=3DArial><FONT=20
  color=3D#0000ff><FONT size=3D2><SPAN =
class=3D710560322-25072006>JD:&nbsp; Just as I=20
  suspected&nbsp;</SPAN></FONT></FONT></FONT></SPAN></DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D693083121-25072006><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D693083121-25072006><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2>In what sense does IETF use the term =
interoperability=20
  test?<SPAN =
class=3D710560322-25072006>&nbsp;</SPAN></FONT></SPAN></DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D693083121-25072006><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2><SPAN=20
  class=3D710560322-25072006></SPAN></FONT></SPAN>&nbsp;</DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D693083121-25072006><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2><SPAN class=3D710560322-25072006>JD:&nbsp; =
You know, the=20
  stuff required to advance&nbsp;to proposed =
standard</SPAN></FONT></SPAN></DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D693083121-25072006><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2><SPAN=20
  class=3D710560322-25072006></SPAN></FONT></SPAN>&nbsp;</DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D693083121-25072006><FONT =
size=3D+0><FONT=20
  face=3DArial><FONT color=3D#0000ff><FONT size=3D2>Is there an RFC on =
this?<SPAN=20
  =
class=3D710560322-25072006>&nbsp;</SPAN></FONT></FONT></FONT></FONT></SPA=
N></DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D693083121-25072006><FONT =
size=3D+0><FONT=20
  face=3DArial><FONT color=3D#0000ff><FONT size=3D2><SPAN=20
  =
class=3D710560322-25072006></SPAN></FONT></FONT></FONT></FONT></SPAN>&nbs=
p;</DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D693083121-25072006><FONT =
size=3D+0><FONT=20
  face=3DArial><FONT color=3D#0000ff><FONT size=3D2><SPAN=20
  class=3D710560322-25072006>JD:&nbsp; I'm=20
  sure.</SPAN></FONT></FONT></FONT></FONT></SPAN></DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D693083121-25072006><FONT =
size=3D+0><FONT=20
  face=3DArial><FONT color=3D#0000ff><FONT size=3D2><SPAN=20
  =
class=3D710560322-25072006></SPAN></FONT></FONT></FONT></FONT></SPAN>&nbs=
p;</DIV>
  <DIV dir=3Dltr align=3Dleft><FONT face=3DArial><FONT =
color=3D#0000ff><FONT=20
  size=3D2><SPAN class=3D693083121-25072006>I was unaware that IETF ran =
</SPAN><SPAN=20
  class=3D693083121-25072006>interoperability tests.<SPAN=20
  =
class=3D710560322-25072006>&nbsp;</SPAN></SPAN></FONT></FONT></FONT></DIV=
>
  <DIV dir=3Dltr align=3Dleft><FONT face=3DArial><FONT =
color=3D#0000ff><FONT=20
  size=3D2><SPAN class=3D693083121-25072006><SPAN=20
  =
class=3D710560322-25072006></SPAN></SPAN></FONT></FONT></FONT>&nbsp;</DIV=
>
  <DIV dir=3Dltr align=3Dleft><FONT face=3DArial><FONT =
color=3D#0000ff><FONT=20
  size=3D2><SPAN class=3D693083121-25072006><SPAN =
class=3D710560322-25072006>JD:&nbsp;=20
  I didn't say it did, and I don't know if it=20
  does.&nbsp;</SPAN></SPAN></FONT></FONT></FONT></DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D693083121-25072006><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D693083121-25072006><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2>Cheers,</FONT></SPAN></DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D693083121-25072006><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D693083121-25072006><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2>Lyndon</FONT></SPAN></DIV><BR>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
  <HR tabIndex=3D-1>
  <FONT face=3DTahoma size=3D2><B>From:</B> owner-ccamp@ops.ietf.org=20
  [mailto:owner-ccamp@ops.ietf.org] <B>On Behalf Of </B>Drake, John=20
  E<BR><B>Sent:</B> Tuesday, July 25, 2006 2:28 PM<BR><B>To:</B>=20
  ccamp@ops.ietf.org<BR><B>Subject:</B> RE: Proposed response to OIF on =
OSPF=20
  ENNI<BR></FONT><BR></DIV>
  <DIV></DIV>
  <DIV><FONT color=3Dnavy><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><SPAN=20
  class=3D105092221-25072006><FONT=20
  color=3D#0000ff>&nbsp;Snipped</FONT></SPAN></SPAN></FONT></DIV>
  <DIV><FONT color=3Dnavy><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><SPAN=20
  class=3D105092221-25072006></SPAN></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=3Dnavy><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><SPAN=20
  class=3D105092221-25072006>&nbsp;</SPAN>Regarding Topic=20
  2:<o:p></o:p></SPAN></FONT></DIV>
  <BLOCKQUOTE dir=3Dltr=20
  style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
    <DIV class=3DSection1>
    <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
    <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
    <P class=3DMsoNormal style=3D"MARGIN-LEFT: 9pt"><FONT =
color=3Dnavy><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Again I =
ask,=20
    wouldn&#8217;t it be better to look at this document which has been =
implemented by=20
    many vendors, and successfully interoperability tested many times =
over many=20
    years to see what can be leveraged instead of starting from =
scratch?<FONT=20
    color=3D#0000ff><SPAN=20
    class=3D105092221-25072006>&nbsp;</SPAN></FONT></SPAN></FONT></P>
    <P class=3DMsoNormal style=3D"MARGIN-LEFT: 9pt"><FONT =
color=3Dnavy><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><FONT=20
    color=3D#0000ff><SPAN=20
    class=3D105092221-25072006></SPAN></FONT></SPAN></FONT>&nbsp;</P>
    <P class=3DMsoNormal style=3D"MARGIN-LEFT: 9pt"><FONT =
color=3Dnavy><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><FONT=20
    color=3D#0000ff><SPAN class=3D105092221-25072006>JD:&nbsp; I noticed =
that=20
    Jonathan has put in this plug several times.&nbsp; I am wondering =
whether=20
    these events are truly interoperability tests, in the sense that the =
IETF=20
    uses the term, or rather rigged demos?&nbsp; I seem to remember that =
the OIF=20
    characterized itself as a marketing organization.=20
    </SPAN></FONT></SPAN></FONT><FONT face=3DArial color=3Dnavy =
size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
    <DIV>
    <DIV class=3DMsoNormal style=3D"TEXT-ALIGN: center" =
align=3Dcenter><FONT=20
    face=3D"Times New Roman" size=3D3><SPAN style=3D"FONT-SIZE: 12pt">
    <HR tabIndex=3D-1 align=3Dcenter width=3D"100%" SIZE=3D2>
    </SPAN></FONT></DIV>
    <P class=3DMsoNormal><FONT face=3DArial color=3D#0000ff=20
    =
size=3D2></FONT>&nbsp;</P></DIV></DIV></BLOCKQUOTE></BLOCKQUOTE></BODY></=
HTML>

------_=_NextPart_001_01C6B038.CB1A8E6C--

Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 25 Jul 2006 22:12:06 +0000
From: "Payam Torab" <ptorab@lopsys.com>
To: <ccamp@ops.ietf.org>
Cc: "'Dave Walters'" <dwalters@lopsys.com>
Subject: shared mesh restoration - e2e recovery signaling draft
Date: Tue, 25 Jul 2006 18:11:01 -0400
Organization: Lambda OpticalSystems
Message-ID: <009001c6b037$368d5640$30fea8c0@NETPTORAB>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0091_01C6B015.AF7BB640"

This is a multi-part message in MIME format.

------=_NextPart_000_0091_01C6B015.AF7BB640
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

In the e2e recovery signaling draft
(draft-ietf-ccamp-gmpls-recovery-e2e-signaling-03.txt), there is a =
procedure
defined for a node on the shared restoration path to notify other nodes
regarding the working LSPs that become vulnerable as a result of =
switching
to the shared restoration path.
=20
It seems there is a similar need to notify these nodes once the shared
restoration path becomes available again. Is this mechanism defined
anywhere?
=20
Thanks,
Payam

------=_NextPart_000_0091_01C6B015.AF7BB640
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:v =3D=20
"urn:schemas-microsoft-com:vml" xmlns:o =3D=20
"urn:schemas-microsoft-com:office:office" xmlns:w =3D=20
"urn:schemas-microsoft-com:office:word" xmlns:p =3D=20
"urn:schemas-microsoft-com:office:powerpoint" xmlns:oa =3D=20
"urn:schemas-microsoft-com:office:activation" xmlns:st1 =3D=20
"urn:schemas-microsoft-com:office:smarttags"><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<TITLE>Message</TITLE>

<META content=3D"MSHTML 6.00.2900.2912" name=3DGENERATOR><!--[if !mso]>
<STYLE>v\:* {
	BEHAVIOR: url(#default#VML)
}
o\:* {
	BEHAVIOR: url(#default#VML)
}
w\:* {
	BEHAVIOR: url(#default#VML)
}
.shape {
	BEHAVIOR: url(#default#VML)
}
</STYLE>
<![endif]--><o:SmartTagType=20
downloadurl=3D"http://www.5iamas-microsoft-com:office:smarttags" =
name=3D"State"=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTagT=
ype><o:SmartTagType=20
downloadurl=3D"http://www.5iamas-microsoft-com:office:smarttags" =
name=3D"City"=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTagT=
ype><o:SmartTagType=20
downloadurl=3D"http://www.5iantlavalamp.com/" name=3D"place"=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTagT=
ype><o:SmartTagType=20
downloadurl=3D"http://www.microsoft.com" name=3D"PersonName"=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTagT=
ype><!--[if !mso]>
<STYLE>st1\:* {
	BEHAVIOR: url(#default#ieooui)
}
</STYLE>
<![endif]-->
<STYLE>@font-face {
	font-family: Wingdings;
}
@font-face {
	font-family: MS Mincho;
}
@font-face {
	font-family: Tahoma;
}
@font-face {
	font-family: @MS Mincho;
}
@page Section1 {size: 8.5in 11.0in; margin: 1.0in 1.25in 1.0in 1.25in; }
P.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
LI.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
DIV.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline
}
A:visited {
	COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlinkFollowed {
	COLOR: blue; TEXT-DECORATION: underline
}
PRE {
	FONT-SIZE: 10pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Courier New"
}
SPAN.EmailStyle18 {
	COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal
}
SPAN.EmailStyle19 {
	COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal
}
SPAN.EmailStyle20 {
	COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal
}
SPAN.EmailStyle21 {
	COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal-reply
}
DIV.Section1 {
	page: Section1
}
OL {
	MARGIN-BOTTOM: 0in
}
UL {
	MARGIN-BOTTOM: 0in
}
</STYLE>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]--></HEAD>
<BODY lang=3DEN-US vLink=3Dblue link=3Dblue><![if =
!supportLists]><![endif]><![if !supportLists]><![endif]><![if =
!supportLists]><![endif]><![if !supportLists]><![endif]><![if =
!supportLists]><![endif]>
<DIV><SPAN class=3D750205621-25072006><FONT face=3D"Courier New" =
color=3D#0000ff=20
size=3D2>In the e2e recovery signaling draft=20
(draft-ietf-ccamp-gmpls-recovery-e2e-signaling-03.txt), there is a =
procedure=20
defined for a node on the shared restoration path to notify other=20
nodes&nbsp;regarding the working LSPs that become vulnerable&nbsp;as a =
result of=20
switching to the shared restoration path.</FONT></SPAN></DIV>
<DIV><SPAN class=3D750205621-25072006><FONT face=3D"Courier New" =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D750205621-25072006><FONT face=3D"Courier New" =
color=3D#0000ff=20
size=3D2>It seems there is a similar need to notify these nodes once the =
shared=20
restoration path becomes available again. Is this mechanism defined=20
anywhere?</FONT></SPAN></DIV>
<DIV><SPAN class=3D750205621-25072006><FONT face=3D"Courier New" =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D750205621-25072006><FONT face=3D"Courier New" =
color=3D#0000ff=20
size=3D2>Thanks,</FONT></SPAN></DIV>
<DIV><SPAN class=3D750205621-25072006><FONT face=3D"Courier New" =
color=3D#0000ff=20
size=3D2>Payam</FONT></SPAN></DIV></BODY></HTML>

------=_NextPart_000_0091_01C6B015.AF7BB640--

Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 25 Jul 2006 22:09:07 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6B036.CC40F2E9"
Subject: RE: Proposed response to OIF on OSPF ENNI
Date: Tue, 25 Jul 2006 15:08:02 -0700
Message-ID: <626FC7C6A97381468FB872072AB5DDC8C2DC28@XCH-SW-42.sw.nos.boeing.com>
Thread-Topic: Proposed response to OIF on OSPF ENNI
Thread-Index: Acas0Ha/aYxFikOBS5m873SVRoVJxgAACLxQAAHPZJAAnZ89IAACGznwAAEH8mAAAxLNQAAAS4QQACJG/RAAAkvKMAANb1UQAABQfIAAASU6IA==
From: "Drake, John E" <John.E.Drake2@boeing.com>
To: <ccamp@ops.ietf.org>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6B036.CC40F2E9
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

=20

	-----Original Message-----
	From: Ong, Lyndon [mailto:Lyong@Ciena.com]=20
	Sent: Tuesday, July 25, 2006 2:39 PM
	To: Drake, John E; ccamp@ops.ietf.org
	Subject: RE: Proposed response to OIF on OSPF ENNI
=09
=09
	Hi John,
	=20
	If you wish to discuss how the tests were carried out, you can
talk to the=20
	7 major carriers that provided lab sites and the 13 router and
switch vendors that participated
	in the 2005 demo.=20
	=20
	JD:  Just as I suspected=20
	=20
	In what sense does IETF use the term interoperability test?=20
	=20
	JD:  You know, the stuff required to advance to proposed
standard
	=20
	Is there an RFC on this?=20
	=20
	JD:  I'm sure.
	=20
	I was unaware that IETF ran interoperability tests.=20
	=20
	JD:  I didn't say it did, and I don't know if it does.=20
	=20
	Cheers,
	=20
	Lyndon

________________________________

	From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]
On Behalf Of Drake, John E
	Sent: Tuesday, July 25, 2006 2:28 PM
	To: ccamp@ops.ietf.org
	Subject: RE: Proposed response to OIF on OSPF ENNI
=09
=09
	 Snipped
	=20
	 Regarding Topic 2:

		=20

		=20

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

		=20

		JD:  I noticed that Jonathan has put in this plug
several times.  I am wondering whether these events are truly
interoperability tests, in the sense that the IETF uses the term, or
rather rigged demos?  I seem to remember that the OIF characterized
itself as a marketing organization. =20

	=09
________________________________

		=20

------_=_NextPart_001_01C6B036.CC40F2E9
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:v =3D=20
"urn:schemas-microsoft-com:vml" xmlns:o =3D=20
"urn:schemas-microsoft-com:office:office" xmlns:w =3D=20
"urn:schemas-microsoft-com:office:word" xmlns:p =3D=20
"urn:schemas-microsoft-com:office:powerpoint" xmlns:oa =3D=20
"urn:schemas-microsoft-com:office:activation" xmlns:st1 =3D=20
"urn:schemas-microsoft-com:office:smarttags"><HEAD><TITLE>Message</TITLE>=

<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1556" name=3DGENERATOR><!--[if !mso]>
<STYLE>v\:* {
	BEHAVIOR: url(#default#VML)
}
o\:* {
	BEHAVIOR: url(#default#VML)
}
w\:* {
	BEHAVIOR: url(#default#VML)
}
.shape {
	BEHAVIOR: url(#default#VML)
}
</STYLE>
<![endif]--><o:SmartTagType=20
downloadurl=3D"http://www.5iamas-microsoft-com:office:smarttags" =
name=3D"State"=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTagT=
ype><o:SmartTagType=20
downloadurl=3D"http://www.5iamas-microsoft-com:office:smarttags" =
name=3D"City"=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTagT=
ype><o:SmartTagType=20
downloadurl=3D"http://www.5iantlavalamp.com/" name=3D"place"=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTagT=
ype><o:SmartTagType=20
downloadurl=3D"http://www.microsoft.com" name=3D"PersonName"=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTagT=
ype><!--[if !mso]>
<STYLE>st1\:* {
	BEHAVIOR: url(#default#ieooui)
}
</STYLE>
<![endif]-->
<STYLE>@font-face {
	font-family: Wingdings;
}
@font-face {
	font-family: MS Mincho;
}
@font-face {
	font-family: Tahoma;
}
@font-face {
	font-family: @MS Mincho;
}
@page Section1 {size: 8.5in 11.0in; margin: 1.0in 1.25in 1.0in 1.25in; }
P.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
LI.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
DIV.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline
}
A:visited {
	COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlinkFollowed {
	COLOR: blue; TEXT-DECORATION: underline
}
PRE {
	FONT-SIZE: 10pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Courier New"
}
SPAN.EmailStyle18 {
	COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal
}
SPAN.EmailStyle19 {
	COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal
}
SPAN.EmailStyle20 {
	COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal
}
SPAN.EmailStyle21 {
	COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal-reply
}
DIV.Section1 {
	page: Section1
}
OL {
	MARGIN-BOTTOM: 0in
}
UL {
	MARGIN-BOTTOM: 0in
}
</STYLE>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]--></HEAD>
<BODY lang=3DEN-US vLink=3Dblue link=3Dblue><![if =
!supportLists]><![endif]><![if !supportLists]><![endif]><![if =
!supportLists]><![endif]><![if !supportLists]><![endif]><![if =
!supportLists]><![endif]>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT>&nbsp;</DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
  face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B> Ong, =
Lyndon=20
  [mailto:Lyong@Ciena.com] <BR><B>Sent:</B> Tuesday, July 25, 2006 2:39=20
  PM<BR><B>To:</B> Drake, John E; ccamp@ops.ietf.org<BR><B>Subject:</B> =
RE:=20
  Proposed response to OIF on OSPF ENNI<BR><BR></FONT></DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D693083121-25072006><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2>Hi John,</FONT></SPAN></DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D693083121-25072006><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D693083121-25072006><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2>If you wish to discuss how the tests were =
carried out,=20
  you can talk to the </FONT></SPAN></DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D693083121-25072006><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2>7 major carriers that provided lab sites and =
the 13=20
  router and switch vendors that participated</FONT></SPAN></DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D693083121-25072006><FONT =
face=3DArial><FONT=20
  color=3D#0000ff><FONT size=3D2>in the 2005 demo.<SPAN=20
  =
class=3D710560322-25072006>&nbsp;</SPAN></FONT></FONT></FONT></SPAN></DIV=
>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D693083121-25072006><FONT =
face=3DArial><FONT=20
  color=3D#0000ff><FONT size=3D2><SPAN=20
  =
class=3D710560322-25072006></SPAN></FONT></FONT></FONT></SPAN>&nbsp;</DIV=
>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D693083121-25072006><FONT =
face=3DArial><FONT=20
  color=3D#0000ff><FONT size=3D2><SPAN =
class=3D710560322-25072006>JD:&nbsp; Just as I=20
  suspected&nbsp;</SPAN></FONT></FONT></FONT></SPAN></DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D693083121-25072006><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D693083121-25072006><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2>In what sense does IETF use the term =
interoperability=20
  test?<SPAN =
class=3D710560322-25072006>&nbsp;</SPAN></FONT></SPAN></DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D693083121-25072006><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2><SPAN=20
  class=3D710560322-25072006></SPAN></FONT></SPAN>&nbsp;</DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D693083121-25072006><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2><SPAN class=3D710560322-25072006>JD:&nbsp; =
You know, the=20
  stuff required to advance&nbsp;to proposed =
standard</SPAN></FONT></SPAN></DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D693083121-25072006><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2><SPAN=20
  class=3D710560322-25072006>&nbsp;</SPAN></FONT></SPAN></DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN =
class=3D693083121-25072006><FONT><FONT=20
  face=3DArial><FONT color=3D#0000ff><FONT size=3D2>Is there an RFC on =
this?<SPAN=20
  =
class=3D710560322-25072006>&nbsp;</SPAN></FONT></FONT></FONT></FONT></SPA=
N></DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN =
class=3D693083121-25072006><FONT><FONT=20
  face=3DArial><FONT color=3D#0000ff><FONT size=3D2><SPAN=20
  =
class=3D710560322-25072006></SPAN></FONT></FONT></FONT></FONT></SPAN>&nbs=
p;</DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN =
class=3D693083121-25072006><FONT><FONT=20
  face=3DArial><FONT color=3D#0000ff><FONT size=3D2><SPAN=20
  class=3D710560322-25072006>JD:&nbsp; I'm=20
  sure.</SPAN></FONT></FONT></FONT></FONT></SPAN></DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN =
class=3D693083121-25072006><FONT><FONT=20
  face=3DArial><FONT color=3D#0000ff><FONT size=3D2><SPAN=20
  =
class=3D710560322-25072006>&nbsp;</SPAN></FONT></FONT></FONT></FONT></SPA=
N></DIV>
  <DIV dir=3Dltr align=3Dleft><FONT face=3DArial><FONT =
color=3D#0000ff><FONT=20
  size=3D2><SPAN class=3D693083121-25072006>I was unaware that IETF ran =
</SPAN><SPAN=20
  class=3D693083121-25072006>interoperability tests.<SPAN=20
  =
class=3D710560322-25072006>&nbsp;</SPAN></SPAN></FONT></FONT></FONT></DIV=
>
  <DIV dir=3Dltr align=3Dleft><FONT face=3DArial><FONT =
color=3D#0000ff><FONT=20
  size=3D2><SPAN class=3D693083121-25072006><SPAN=20
  =
class=3D710560322-25072006></SPAN></SPAN></FONT></FONT></FONT>&nbsp;</DIV=
>
  <DIV dir=3Dltr align=3Dleft><FONT face=3DArial><FONT =
color=3D#0000ff><FONT=20
  size=3D2><SPAN class=3D693083121-25072006><SPAN =
class=3D710560322-25072006>JD:&nbsp;=20
  I didn't say it did, and I don't know if it=20
  does.&nbsp;</SPAN></SPAN></FONT></FONT></FONT></DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D693083121-25072006><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D693083121-25072006><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2>Cheers,</FONT></SPAN></DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D693083121-25072006><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D693083121-25072006><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2>Lyndon</FONT></SPAN></DIV><BR>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
  <HR tabIndex=3D-1>
  <FONT face=3DTahoma size=3D2><B>From:</B> owner-ccamp@ops.ietf.org=20
  [mailto:owner-ccamp@ops.ietf.org] <B>On Behalf Of </B>Drake, John=20
  E<BR><B>Sent:</B> Tuesday, July 25, 2006 2:28 PM<BR><B>To:</B>=20
  ccamp@ops.ietf.org<BR><B>Subject:</B> RE: Proposed response to OIF on =
OSPF=20
  ENNI<BR></FONT><BR></DIV>
  <DIV></DIV>
  <DIV><FONT color=3Dnavy><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><SPAN=20
  class=3D105092221-25072006><FONT=20
  color=3D#0000ff>&nbsp;Snipped</FONT></SPAN></SPAN></FONT></DIV>
  <DIV><FONT color=3Dnavy><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><SPAN=20
  class=3D105092221-25072006></SPAN></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=3Dnavy><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><SPAN=20
  class=3D105092221-25072006>&nbsp;</SPAN>Regarding Topic=20
  2:<o:p></o:p></SPAN></FONT></DIV>
  <BLOCKQUOTE dir=3Dltr=20
  style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
    <DIV class=3DSection1>
    <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
    <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
    <P class=3DMsoNormal style=3D"MARGIN-LEFT: 9pt"><FONT =
color=3Dnavy><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Again I =
ask,=20
    wouldn&#8217;t it be better to look at this document which has been =
implemented by=20
    many vendors, and successfully interoperability tested many times =
over many=20
    years to see what can be leveraged instead of starting from =
scratch?<FONT=20
    color=3D#0000ff><SPAN=20
    class=3D105092221-25072006>&nbsp;</SPAN></FONT></SPAN></FONT></P>
    <P class=3DMsoNormal style=3D"MARGIN-LEFT: 9pt"><FONT =
color=3Dnavy><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><FONT=20
    color=3D#0000ff><SPAN=20
    class=3D105092221-25072006></SPAN></FONT></SPAN></FONT>&nbsp;</P>
    <P class=3DMsoNormal style=3D"MARGIN-LEFT: 9pt"><FONT =
color=3Dnavy><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><FONT=20
    color=3D#0000ff><SPAN class=3D105092221-25072006>JD:&nbsp; I noticed =
that=20
    Jonathan has put in this plug several times.&nbsp; I am wondering =
whether=20
    these events are truly interoperability tests, in the sense that the =
IETF=20
    uses the term, or rather rigged demos?&nbsp; I seem to remember that =
the OIF=20
    characterized itself as a marketing organization.=20
    </SPAN></FONT></SPAN></FONT><FONT face=3DArial color=3Dnavy =
size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
    <DIV>
    <DIV class=3DMsoNormal style=3D"TEXT-ALIGN: center" =
align=3Dcenter><FONT=20
    face=3D"Times New Roman" size=3D3><SPAN style=3D"FONT-SIZE: 12pt">
    <HR tabIndex=3D-1 align=3Dcenter width=3D"100%" SIZE=3D2>
    </SPAN></FONT></DIV>
    <P class=3DMsoNormal><FONT face=3DArial color=3D#0000ff=20
    =
size=3D2></FONT>&nbsp;</P></DIV></DIV></BLOCKQUOTE></BLOCKQUOTE></BODY></=
HTML>

------_=_NextPart_001_01C6B036.CC40F2E9--

Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 25 Jul 2006 21:45:52 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6B032.C6E99EBE"
Subject: RE: Proposed response to OIF on OSPF ENNI
Date: Tue, 25 Jul 2006 17:39:14 -0400
Message-ID: <0901D1988E815341A0103206A834DA07F1A2D4@mdmxm02.ciena.com>
Thread-Topic: Proposed response to OIF on OSPF ENNI
Thread-Index: Acas0Ha/aYxFikOBS5m873SVRoVJxgAACLxQAAHPZJAAnZ89IAACGznwAAEH8mAAAxLNQAAAS4QQACJG/RAAAkvKMAANb1UQAABQfIA=
From: "Ong, Lyndon" <Lyong@Ciena.com>
To: "Drake, John E" <John.E.Drake2@boeing.com>, <ccamp@ops.ietf.org>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6B032.C6E99EBE
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi John,
=20
If you wish to discuss how the tests were carried out, you can talk to
the=20
7 major carriers that provided lab sites and the 13 router and switch
vendors that participated
in the 2005 demo.
=20
In what sense does IETF use the term interoperability test? Is there an
RFC on this?
I was unaware that IETF ran interoperability tests.
=20
Cheers,
=20
Lyndon

________________________________

From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On
Behalf Of Drake, John E
Sent: Tuesday, July 25, 2006 2:28 PM
To: ccamp@ops.ietf.org
Subject: RE: Proposed response to OIF on OSPF ENNI

 Snipped
=20
 Regarding Topic 2:

	=20

	=20

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

	=20

	JD:  I noticed that Jonathan has put in this plug several times.
I am wondering whether these events are truly interoperability tests, in
the sense that the IETF uses the term, or rather rigged demos?  I seem
to remember that the OIF characterized itself as a marketing
organization. =20

=09
________________________________

	=20

------_=_NextPart_001_01C6B032.C6E99EBE
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:v =3D=20
"urn:schemas-microsoft-com:vml" xmlns:o =3D=20
"urn:schemas-microsoft-com:office:office" xmlns:w =3D=20
"urn:schemas-microsoft-com:office:word" xmlns:p =3D=20
"urn:schemas-microsoft-com:office:powerpoint" xmlns:oa =3D=20
"urn:schemas-microsoft-com:office:activation" xmlns:st1 =3D=20
"urn:schemas-microsoft-com:office:smarttags"><HEAD><TITLE>Message</TITLE>=

<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.2912" name=3DGENERATOR><!--[if !mso]>
<STYLE>v\:* {
	BEHAVIOR: url(#default#VML)
}
o\:* {
	BEHAVIOR: url(#default#VML)
}
w\:* {
	BEHAVIOR: url(#default#VML)
}
.shape {
	BEHAVIOR: url(#default#VML)
}
</STYLE>
<![endif]--><o:SmartTagType=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" =
name=3D"State"=20
downloadurl=3D"http://www.5iamas-microsoft-com:office:smarttags"></o:Smar=
tTagType><o:SmartTagType=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" =
name=3D"City"=20
downloadurl=3D"http://www.5iamas-microsoft-com:office:smarttags"></o:Smar=
tTagType><o:SmartTagType=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" =
name=3D"place"=20
downloadurl=3D"http://www.5iantlavalamp.com/"></o:SmartTagType><o:SmartTa=
gType=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" =
name=3D"PersonName"=20
downloadurl=3D"http://www.microsoft.com"></o:SmartTagType><!--[if !mso]>
<STYLE>st1\:* {
	BEHAVIOR: url(#default#ieooui)
}
</STYLE>
<![endif]-->
<STYLE>@font-face {
	font-family: Wingdings;
}
@font-face {
	font-family: MS Mincho;
}
@font-face {
	font-family: Tahoma;
}
@font-face {
	font-family: @MS Mincho;
}
@page Section1 {size: 8.5in 11.0in; margin: 1.0in 1.25in 1.0in 1.25in; }
P.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
LI.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
DIV.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline
}
A:visited {
	COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlinkFollowed {
	COLOR: blue; TEXT-DECORATION: underline
}
PRE {
	FONT-SIZE: 10pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Courier New"
}
SPAN.EmailStyle18 {
	COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal
}
SPAN.EmailStyle19 {
	COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal
}
SPAN.EmailStyle20 {
	COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal
}
SPAN.EmailStyle21 {
	COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal-reply
}
DIV.Section1 {
	page: Section1
}
OL {
	MARGIN-BOTTOM: 0in
}
UL {
	MARGIN-BOTTOM: 0in
}
</STYLE>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]--></HEAD>
<BODY lang=3DEN-US vLink=3Dblue link=3Dblue><![if =
!supportLists]><![endif]><![if !supportLists]><![endif]><![if =
!supportLists]><![endif]><![if !supportLists]><![endif]><![if =
!supportLists]><![endif]>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D693083121-25072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Hi John,</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D693083121-25072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D693083121-25072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>If you wish to discuss how the tests were =
carried out, you=20
can talk to the </FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D693083121-25072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>7 major carriers that provided lab sites and =
the 13 router=20
and switch vendors that participated</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D693083121-25072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>in the 2005 demo.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D693083121-25072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D693083121-25072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>In what sense does IETF use the term =
interoperability=20
test?&nbsp;Is there an RFC on this?</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D693083121-25072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>I was unaware that IETF ran </FONT></SPAN><SPAN =

class=3D693083121-25072006>interoperability=20
tests.</DIV>
<DIV dir=3Dltr align=3Dleft>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft>Cheers,</DIV>
<DIV dir=3Dltr align=3Dleft>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft>Lyndon</DIV> 
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
<HR tabIndex=3D-1>
From: owner-ccamp@ops.ietf.org=20
[mailto:owner-ccamp@ops.ietf.org] On Behalf Of Drake, John=20
E Sent: Tuesday, July 25, 2006 2:28 PM To:=20
ccamp@ops.ietf.org Subject: RE: Proposed response to OIF on =
OSPF=20
ENNI </DIV>
<DIV></DIV>
<DIV><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><SPAN=20
class=3D105092221-25072006><FONT=20
color=3D#0000ff>&nbsp;Snipped</DIV>
<DIV><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><SPAN=20
class=3D105092221-25072006>&nbsp;</DIV>
<DIV><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><SPAN=20
class=3D105092221-25072006>&nbsp;Regarding Topic=20
2:<o:p></o:p></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
 <DIV class=3DSection1>
 <SPAN=20
 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p>
 <SPAN=20
 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p>
 <SPAN=20
 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Again I =
ask, wouldn&#8217;t=20
 it be better to look at this document which has been implemented by =
many=20
 vendors, and successfully interoperability tested many times over many =
years=20
 to see what can be leveraged instead of starting from scratch?<FONT=20
 color=3D#0000ff><SPAN=20
 class=3D105092221-25072006>&nbsp;
 <SPAN=20
 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><FONT=20
 color=3D#0000ff><SPAN=20
 class=3D105092221-25072006>&nbsp;
 <SPAN=20
 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><FONT=20
 color=3D#0000ff>JD:&nbsp; I noticed =
that Jonathan=20
 has put in this plug several times.&nbsp; I am wondering whether these =
events=20
 are truly interoperability tests, in the sense that the IETF uses the =
term, or=20
 rather rigged demos?&nbsp; I seem to remember that the OIF =
characterized=20
 itself as a marketing organization. <FONT=20
 face=3DArial color=3Dnavy size=3D2><SPAN=20
 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p>
 <DIV>
 <DIV class=3DMsoNormal style=3D"TEXT-ALIGN: center" =
align=3Dcenter><FONT=20
 face=3D"Times New Roman" size=3D3>
 <HR tabIndex=3D-1 align=3Dcenter width=3D"100%" SIZE=3D2>
 </DIV>
 &nbsp;</DIV></DIV></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C6B032.C6E99EBE--

Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 25 Jul 2006 21:38:28 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Working Group Last Call on draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt
Date: Tue, 25 Jul 2006 16:37:38 -0500
Message-ID: <449B2580D802A443A923DABF3EAB82AF0C7757BB@OCCLUST04EVS1.ugd.att.com>
Thread-Topic: Working Group Last Call on draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt
Thread-Index: Acal7P/gp8mYn7liS4i0qCHMPY+nKQKOkEkA
From: "Brungard, Deborah A, ALABS" <dbrungard@att.com>
To: "Adrian Farrel" <adrian@olddog.co.uk>
Cc: <ccamp@ops.ietf.org>

Thanks Adrian.

We've allowed additional discussion on your response summary to continue
for some time, can you now please summarize if any changes have been
identified?

I noted your email on the MPLS list, I have not seen any issues
identified with the interpretation used by this document.

I did not identify any technical issues. I've run both the idnit check
and my personal American-English check tool (famous among my draft
co-authors), and found a couple of grammer nits/typos.

(1) Nit check gave one warning on a missing reference - a typo in
section 6.6.1: RFC3743 should be RFC3473.

(2) My check tool gave the following:
- inconsistent use of "Connection" and "connection" e.g. 5.2 uses the
small cap. I don't have a preference which is used.
- identified multiple instances where the addition of a comma would be
helpful (I'll send a marked up copy to you for consideration against
British use).
- 3.1, 6.2, 6.2.1, 6.5, 6.6, 8.1, 10.2 need to have a ":" before their
lists
- 3.3, 1st sentence: Segments capabilities --> Segment capabilities
- 5.4.1 ATTIBUTE --> ATTRIBUTE
- 5.5 "in favor of [RFC3471]" --> "and [RFC3471]"
- 6.1 "or if a further" --> "or if another"
- 6.2 "value is assigning" --> "value in assigning"
- 6.6.3 "for at least the five times" --> "for at least five times"
- 6.7 "link failures, and" "link failures, or"
- 6.7 "If an LSR" --> "If a node"
- 7.1 "domains do not share this sort of information." --> "domains do
not usually share this type of information."
- 9.1 "that the process of call establishment independent of LSP setup
may be used ..setup" --> "that as the process of call establishment is
independent of LSP setup, this may be used to apply an extra level of
authentication and policy compared to a hop-by-hop LSP setup"
- 9.1 "Insect" --> "IPsec"
- 11 "input to and" --> "input and"
- 12.1 "GMPLS-FUNCT" --> "RFC4426"

Thanks,
Deborah

-----Original Message-----
From: Adrian Farrel [mailto:adrian@olddog.co.uk]=20
Sent: Wednesday, July 12, 2006 3:54 PM
To: Brungard, Deborah A, ALABS
Cc: ccamp@ops.ietf.org
Subject: Re: Working Group Last Call on
draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt

Hi,

> The Working Group Last Call has closed on this document.
>
> Authors/editors please summarize the comments and document
> how they will be addressed.

Thanks Deborah, it's interesting to be on the receiving side for a
change
:-)

I noted the following comments during WG last call.

1. Desirability of liaison to ITU-T SG15 (Lyndon)
Lyndon suggested that this I-D should be liaised to SG15 prior to
becoming
an RFC to ensure that terminology is correct and that it meets the
requirments for supporting ASON calls.
Our response here is that:
a. This I-D is not specifically targeted at satisfying RFC4139.
b. An applicability statement will be produced describing how this and
   other I-Ds/RFCs can be used to meet the requirements set out in
   RFC4139. That work will definitely be liaised to the ITU-T.
c. The terms used in this document are not specific to ASON, but
   in general they have been taken from RFC4139 and RFC4397
   both of which received substantial and useful review by SG15.
No further action is planned by the authors.

2. Format of Long Call ID (Lyndon)
Lyndon points out that a format for the long call ID has been defined in
G.7713.2 and suggests that this might be included by reference.
The authors note that the format of an ASON call ID is defined in
several
places (including G.7713.1 and G.7713.2), but the intention of the draft
is
not to be limited to ASON applicability. Therefore other call ID formats
would also be supported, and the format is out of scope for the draft.
An applicability statement will be produced describing how this and
other
I-Ds/RFCs can be used to meet the requirements set out in RFC4139, and
that
will definitely include the encoding of ASON call IDs. That work will be
liaised to the ITU-T.
No further action is planned by the authors.

3. Location of Short Call ID in Path message (Lyndon and Ben)
Both Lyndon and Ben questioned the location of the short call ID in the
Session object.
a. Impact of existing, non-conformant implementations
   The draft currently describes the behavior if non-conformant transit
   LSRs react to the use of the previously reserved bits of the Session
   object. They might reject the Path message, or they might zero out
   the short call ID.
   Lyndon asked whether it might be better to use a separate object
   to avoid this issue completely.
   The authors had previously discussed this point at some length and
   believe that protocol design should not be shaped by the possiblity
   of dysfunctional implementations. Further, the use of a new object
    might also cause problems with defective implementations.
   The authors propose no changes to the I-D for this point, but will
   send mail to the MPLS mailing list to check that the 'owners' of
   RSVP-TE have no issue with this use of a previkously reserved
   field.
b. Illogicality of use of Session object
    Ben and Lyndon expressed the view that it would be more
    logical to place the short call ID in a new object than to
    complicate the concept of the Session. The possibility of
    using the Association object was also raised.
    The authors had discussed this at some length over the
    last two years that the I-D has been in production, and
    recently on the mailing list. Our conclusion is that:
    i. The Association object is for associating LSPs with
       each other. The call ID is used to associate LSPs
       with a call.
    ii. A separate object would be perfectly functional.
    iii. There is already some logical association between the
       session and the LSPs in the call, and it makes sense to
       extend this.
    iv. The key on the Notify message is the session.
    v. The current I-D is also perfectly functional, and has been
        successfully implemented.
Given that no specific draw-back to the current encoding has been put
forward except for a feeling of illogicality among some readers, the
authors
propose no further action except for polling the MPLS WG as described
above.

4. Procedures for including LINK_CAPABILITIES object
A comment was made that this appears to be totally optional without any
defined procedures for how an LSR should decide wheter to include the
object.
The authors agree with this view, and it is intentional. The draft
states...
   The LINK CAPABILITY object is introduced to support link capability
   exchange during Call setup and MAY be included in a Notify message
   used for Call setup. This optional object includes the bundled link
   local capabilities of the Call initiating node (or terminating node)
   indicated by the source address of the Notify message.
This text makes it quite clear that the object is completely optional.
The authors propose to make no changes for this point.

5. Question about processing rules in section 6.2.1
There was a detailed quesiton about the procedure in seciton 6.2.1.
The authors believe that this was answered and concluded on the mailing
list.
The authors propose to make no changes for this point.

6. Refresh Notify
Lyndon asked whether the refresh of the Notify message is really
necessary
if there are active LSPs in the call?  Possibly the LSP refresh
could be sufficient, since this carries the short Call ID. He also asked
if it possible that the call would be dropped while there are still
active LSPs.
The authors consider that you cannot infer the status of the call when
there
are no connections on the call. They believe that a single mechanism
should be used to monitor the call status in all circumstances.
The draft describes refresh failure of calls when connections already
exist
in section 6.7.

In short, we propose to make no changes to the document as a result of
WG=20
last call. We will notify the MPLS WG as described above.

Can this I-D now move on the ADs?

Thanks,
Adrian=20

Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 25 Jul 2006 21:28:31 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6B031.39727FFE"
Subject: RE: Proposed response to OIF on OSPF ENNI
Date: Tue, 25 Jul 2006 14:28:09 -0700
Message-ID: <626FC7C6A97381468FB872072AB5DDC8C2DC26@XCH-SW-42.sw.nos.boeing.com>
Thread-Topic: Proposed response to OIF on OSPF ENNI
Thread-Index: Acas0Ha/aYxFikOBS5m873SVRoVJxgAACLxQAAHPZJAAnZ89IAACGznwAAEH8mAAAxLNQAAAS4QQACJG/RAAAkvKMAANb1UQ
From: "Drake, John E" <John.E.Drake2@boeing.com>
To: <ccamp@ops.ietf.org>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6B031.39727FFE
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

 Snipped
=20
 Regarding Topic 2:

	=20

	=20

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

	=20

	JD:  I noticed that Jonathan has put in this plug several times.
I am wondering whether these events are truly interoperability tests, in
the sense that the IETF uses the term, or rather rigged demos?  I seem
to remember that the OIF characterized itself as a marketing
organization. =20

=09
________________________________

	=20

------_=_NextPart_001_01C6B031.39727FFE
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:v =3D=20
"urn:schemas-microsoft-com:vml" xmlns:o =3D=20
"urn:schemas-microsoft-com:office:office" xmlns:w =3D=20
"urn:schemas-microsoft-com:office:word" xmlns:p =3D=20
"urn:schemas-microsoft-com:office:powerpoint" xmlns:oa =3D=20
"urn:schemas-microsoft-com:office:activation" xmlns:st1 =3D=20
"urn:schemas-microsoft-com:office:smarttags"><HEAD><TITLE>Message</TITLE>=

<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1556" name=3DGENERATOR><!--[if !mso]>
<STYLE>v\:* {
	BEHAVIOR: url(#default#VML)
}
o\:* {
	BEHAVIOR: url(#default#VML)
}
w\:* {
	BEHAVIOR: url(#default#VML)
}
.shape {
	BEHAVIOR: url(#default#VML)
}
</STYLE>
<![endif]--><o:SmartTagType=20
downloadurl=3D"http://www.5iamas-microsoft-com:office:smarttags" =
name=3D"State"=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTagT=
ype><o:SmartTagType=20
downloadurl=3D"http://www.5iamas-microsoft-com:office:smarttags" =
name=3D"City"=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTagT=
ype><o:SmartTagType=20
downloadurl=3D"http://www.5iantlavalamp.com/" name=3D"place"=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTagT=
ype><o:SmartTagType=20
downloadurl=3D"http://www.microsoft.com" name=3D"PersonName"=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTagT=
ype><!--[if !mso]>
<STYLE>st1\:* {
	BEHAVIOR: url(#default#ieooui)
}
</STYLE>
<![endif]-->
<STYLE>@font-face {
	font-family: Wingdings;
}
@font-face {
	font-family: MS Mincho;
}
@font-face {
	font-family: Tahoma;
}
@font-face {
	font-family: @MS Mincho;
}
@page Section1 {size: 8.5in 11.0in; margin: 1.0in 1.25in 1.0in 1.25in; }
P.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
LI.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
DIV.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline
}
A:visited {
	COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlinkFollowed {
	COLOR: blue; TEXT-DECORATION: underline
}
PRE {
	FONT-SIZE: 10pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Courier New"
}
SPAN.EmailStyle18 {
	COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal
}
SPAN.EmailStyle19 {
	COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal
}
SPAN.EmailStyle20 {
	COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal
}
SPAN.EmailStyle21 {
	COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal-reply
}
DIV.Section1 {
	page: Section1
}
OL {
	MARGIN-BOTTOM: 0in
}
UL {
	MARGIN-BOTTOM: 0in
}
</STYLE>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]--></HEAD>
<BODY lang=3DEN-US vLink=3Dblue link=3Dblue><![if =
!supportLists]><![endif]><![if !supportLists]><![endif]><![if =
!supportLists]><![endif]><![if !supportLists]><![endif]><![if =
!supportLists]><![endif]>
<DIV><FONT color=3Dnavy><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><SPAN=20
class=3D105092221-25072006><FONT=20
color=3D#0000ff>&nbsp;Snipped</FONT></SPAN></SPAN></FONT></DIV>
<DIV><FONT color=3Dnavy><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><SPAN=20
class=3D105092221-25072006></SPAN></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3Dnavy><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><SPAN=20
class=3D105092221-25072006>&nbsp;</SPAN>Regarding Topic=20
2:<o:p></o:p></SPAN></FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DSection1>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal style=3D"MARGIN-LEFT: 9pt"><FONT =
color=3Dnavy><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Again I =
ask, wouldn&#8217;t=20
  it be better to look at this document which has been implemented by =
many=20
  vendors, and successfully interoperability tested many times over many =
years=20
  to see what can be leveraged instead of starting from scratch?<FONT=20
  color=3D#0000ff><SPAN=20
  class=3D105092221-25072006>&nbsp;</SPAN></FONT></SPAN></FONT></P>
  <P class=3DMsoNormal style=3D"MARGIN-LEFT: 9pt"><FONT =
color=3Dnavy><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><FONT=20
  color=3D#0000ff><SPAN=20
  class=3D105092221-25072006></SPAN></FONT></SPAN></FONT>&nbsp;</P>
  <P class=3DMsoNormal style=3D"MARGIN-LEFT: 9pt"><FONT =
color=3Dnavy><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><FONT=20
  color=3D#0000ff><SPAN class=3D105092221-25072006>JD:&nbsp; I noticed =
that Jonathan=20
  has put in this plug several times.&nbsp; I am wondering whether these =
events=20
  are truly interoperability tests, in the sense that the IETF uses the =
term, or=20
  rather rigged demos?&nbsp; I seem to remember that the OIF =
characterized=20
  itself as a marketing organization. </SPAN></FONT></SPAN></FONT><FONT=20
  face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <DIV>
  <DIV class=3DMsoNormal style=3D"TEXT-ALIGN: center" =
align=3Dcenter><FONT=20
  face=3D"Times New Roman" size=3D3><SPAN style=3D"FONT-SIZE: 12pt">
  <HR tabIndex=3D-1 align=3Dcenter width=3D"100%" SIZE=3D2>
  </SPAN></FONT></DIV>
  <P class=3DMsoNormal><FONT face=3DArial color=3D#0000ff=20
  size=3D2></FONT>&nbsp;</P></DIV></DIV></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C6B031.39727FFE--

Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 25 Jul 2006 21:26:37 +0000
Message-ID: <44C68C60.2020700@us.fujitsu.com>
Date: Tue, 25 Jul 2006 14:25:52 -0700
From: Richard Rabbat <richard@us.fujitsu.com>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: "Sadler, Jonathan B." <Jonathan.Sadler@tellabs.com>
CC: "Brungard, Deborah A, ALABS" <dbrungard@att.com>, "Ong, Lyndon" <Lyong@Ciena.com>, ccamp@ops.ietf.org, Adrian Farrel <adrian@olddog.co.uk>, Richard Rabbat <richard@us.fujitsu.com>
Subject: Re: Proposed response to OIF on OSPF ENNI
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

Hi Jonathan,
quick comment inline

Sadler, Jonathan B. wrote:
>
> 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.
>
Can you please elaborate on the issue discussed in the addressing draft? 
Which section are you talking about?
The goal of the draft in the abstract says:

   ... The aim 
   of this document is to facilitate and ensure better interworking of 
   GMPLS-capable Label Switching Routers (LSRs) based on experience 
   gained in deployments and interoperability testing and proper 
   interpretation of published RFCs. 

and the introduction:

   ... GMPLS supports a 
   control entity that is responsible for one or more data plane 
   entities, but for the purposes of this document, it is assumed that 
   there is a one-to-one correspondence between control plane and data 
   plane entities. 

Is this what you are referring to?
Thanks,
Richard.
>
> Given that:
>
> - CCAMP has a milestone to publish an ASON routing solution by Nov 2006,
>
> - CCAMP didnt have at the time this was liaised (doesnt 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:Lyong@Ciena.com]
> *Sent:* Monday, July 24, 2006 2: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,
>
> 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:* 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),
>
> 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:Jonathan.Sadler@tellabs.com]
> *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,
>
> I havent 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:* 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
>
> 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.
>
> 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-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 IETFs 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 IETFs 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 carriers 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
> ============================================================
>   

Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 25 Jul 2006 21:15:56 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Proposed response to OIF on OSPF ENNI
Date: Tue, 25 Jul 2006 17:10:42 -0400
Message-ID: <0901D1988E815341A0103206A834DA07F1A2CF@mdmxm02.ciena.com>
Thread-Topic: Proposed response to OIF on OSPF ENNI
Thread-Index: AcawFcD5668O9FcgTgiqRfldOQ7h9QAGFTUw
From: "Ong, Lyndon" <Lyong@Ciena.com>
To: <Dimitri.Papadimitriou@alcatel.be>
Cc: "Adrian Farrel" <adrian@olddog.co.uk>, <ccamp@ops.ietf.org>, "Brungard, Deborah A, ALABS" <dbrungard@att.com>, "Sadler, Jonathan B." <Jonathan.Sadler@tellabs.com>, <owner-ccamp@ops.ietf.org>

Hi Dimitri,

Regarding the scope, I don't think the scope is that complicated.
However, I will reflect to OIF that there is confusion about the scope
of the document and as editor will see what I
can do to help clarify these.=20

Cheers,

Lyndon

-----Original Message-----
From: Dimitri.Papadimitriou@alcatel.be
[mailto:Dimitri.Papadimitriou@alcatel.be]=20
Sent: Tuesday, July 25, 2006 11:11 AM
To: Ong, Lyndon
Cc: Adrian Farrel; ccamp@ops.ietf.org; Brungard, Deborah A, ALABS;
Sadler, Jonathan B.; owner-ccamp@ops.ietf.org
Subject: RE: Proposed response to OIF on OSPF ENNI

lyndon - see my reply to jonathan on this specific point -=20

i can sum'up the evaluation phases lead to different premises and ext.=20
guidelines (in addition to the specific OIF reachability information
encoding) hence, these extensions are not reconcilable without
reconsidering the protocol evaluation itself - it is the basic reason
why i have been so scrupulous in driving this evaluation work as
accurate as possible - and the reason why the proposed liaison text
directly referred to this Section 4.1

ps: could you answer to my previous post ? on OIF IA scope

"Ong, Lyndon" <Lyong@Ciena.com>
25/07/2006 20:01
=20
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     "Adrian Farrel" <adrian@olddog.co.uk>,=20
<ccamp@ops.ietf.org>, "Brungard, Deborah A, ALABS" <dbrungard@att.com>,
"Sadler, Jonathan B." <Jonathan.Sadler@tellabs.com>,
<owner-ccamp@ops.ietf.org>
        Subject:        RE: Proposed response to OIF on OSPF ENNI

Hi Dimitri,

Well, they could of course become agreed standard codepoints if CCAMP
adopted them (unlikely as that appears to be given the past history of
CCAMP and any protocol proposals made by other bodies) hence "at this
time" seemed like a required note.

OIF would of course be very happy if CCAMP agreed to adopt the formats
that were implemented during OIF prototype testing, this is still
possible :o)

Cheers,

Lyndon=20

-----Original Message-----
From: Dimitri.Papadimitriou@alcatel.be
[mailto:Dimitri.Papadimitriou@alcatel.be]
Sent: Tuesday, July 25, 2006 10:54 AM
To: Ong, Lyndon
Cc: Adrian Farrel; ccamp@ops.ietf.org; Brungard, Deborah A, ALABS;
Sadler, Jonathan B.; owner-ccamp@ops.ietf.org
Subject: RE: Proposed response to OIF on OSPF ENNI

lyndon - indeed this is mentioned - the concern here can be formulated
as
follows: section 1.2 of the OIF IA is unclear about positioning and
exact intention with the proposed extensions (in Appendix)=20

"These extensions use codepoints in the range reserved by IANA for
private and experimental use, and are not agreed standard codepoints at
this time.=20
Future developments may result in change to the codepoints and/or
formats of these extensions."=20

you wrote: "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."

the fact that the sentence combines "at this time" and points to
potential "standard codepoints" means that we have to warn OIF about
implication i.e. if OIF intents to change their status (toward standard
codepoints) then the extensions will be de-facto subject to the
MPLS/GMPLS change process from the IETF perspective

ps: this is also the reason why there is a direct relationship between
objective of the document (see previous post) and listed extensions -

"Ong, Lyndon" <Lyong@Ciena.com>
Sent by: owner-ccamp@ops.ietf.org
25/07/2006 18:55
=20
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Sadler,=20
Jonathan B." <Jonathan.Sadler@tellabs.com>
        cc:     "Adrian Farrel" <adrian@olddog.co.uk>,=20
<ccamp@ops.ietf.org>, "Brungard, Deborah A, ALABS" <dbrungard@att.com>,
<owner-ccamp@ops.ietf.org>
        Subject:        RE: Proposed response to OIF on OSPF ENNI

Hi Dimitri,

I completely agree with you that there is much unnecessary hubbub
going on.  The document does in fact point to IETF (and ITU) for
standard extensions to the routing protocols.

>From the discussion I have the sense that there is some unhappiness with
the
document focusing on requirements that are still in the process of being

addressed within CCAMP, but since it points to the drafts being done
here
if anything it should focus reader's attention on the work here in CCAMP
rather than anywhere else.=20

Cheers,

Lyndon

-----Original Message-----
From: Dimitri.Papadimitriou@alcatel.be
[mailto:Dimitri.Papadimitriou@alcatel.be]=20
Sent: Tuesday, July 25, 2006 3:18 AM
To: Sadler, Jonathan B.; Ong, Lyndon
Cc: Adrian Farrel; ccamp@ops.ietf.org; Brungard, Deborah A, ALABS;
owner-ccamp@ops.ietf.org
Subject: RE: Proposed response to OIF on OSPF ENNI

jonathan & lyndon

o) During Dallas CCAMP meeting, IETF 66, we have had the following
discussion (extracted from the meeting minutes)=20

"Kireeti: What would make me happy is not to have extensions defined in
IAs=20
         Work has been done in the IETF. Instead, we will have objects
in the specs and IAs=20
         Putting the extensions in an informational appendix is still
confusing, especially=20
         as vendors have implemented them for demos=20
         I would prefer that you just point to IETF so as extensions
evolve in the IETF, you=20
         stay coordinated
Jim: We [the OIF] don't think that differently=20
     One of our goals is to align and converge.=20
     We understand we are using experimental codepoints"=20

so, it is rather unclear why there is so much hubub when IETF proposes
to achieve this objective ? if i well understand your opinion is that
IETF should not target this objective ? let's assume this is the case,
it still does not allow OIF to bypass the MPLS-GMPLS change process=20

o) concerning the alignment of IETF vs G.7715 and G.7715.1, from the
IETF liaison webpage you will see that a set of exchanges between bodies
has been conducted to ensure such alignment; however, as ITU should be
defining ASON routing requirements your statement "I cannot say that
they are aligned with the requirements of the OIF" is totally unclear to
me.=20
Does OIF has its own requirements or are OIF requirements not fully
aligned with ITU G.7715/.1 ? This question should be reflected in the
liaison to OIF - as a CLEAR response from OIF will surely help sorting
the present situation=20

o) what is the real "issue" by pointing to the addressing i-d, the
latter just provides recommendation in case of 1:1 corr. between data
and control plane entities; i thought ASON was looking at larger scope -
so what's the point beside trying to mis-use any IETF production to
corroborate the GMPLS OSPF digression of Section 4.1 of the OIF IA ?

o) the tone of the OIF IA is its first sections is totally inappropriate
and misleading - so requires major revision - by reading one got the
impression by reading that a) OIF puts premises of a new protocol
recommendation while also stating it is a demo code reporting for a
single level - this must be seriously revisited b) OIF has apparently
discovered major holes and flaws, while issue is limited to unnumbered
links with overlapping ID space per TE Router ID (as detailed in section
5.7 of the eval doc) - alignment on these aspect(s) is also more than
recommended imho=20

o) at the end, the major concern is that it is totally unclear what the
purpose of the OIF IA OSPF extensions are, if the intention of OIF is to
push them outside OIF demo scope (which seems to be the case since the
document passes through OIF ballot process and thus will be openly
available after this phase), then de-facto it is an OIF dutty to ask
IETF for in-depth revision and full alignment before publication=20

ps: to achieve a standard you need running code, but not any running
code becomes a standard even informational (hopefully);

-d.

"Sadler, Jonathan B." <Jonathan.Sadler@tellabs.com> Sent by:
owner-ccamp@ops.ietf.org
24/07/2006 22:31
=20
        To:     "Brungard, Deborah A, ALABS" <dbrungard@att.com>, "Ong,=20
Lyndon" <Lyong@Ciena.com>, <ccamp@ops.ietf.org>
        cc:     "Adrian Farrel" <adrian@olddog.co.uk>
        Subject:        RE: Proposed response to OIF on OSPF ENNI

Hi Deborah, Lyndon, et al,
=20
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.
=20
Given that:
-          CCAMP has a milestone to publish an ASON routing solution by=20
Nov 2006,=20
-          CCAMP didn't have at the time this was liaised (doesn't have=20
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...
=20
Regards,
=20
Jonathan Sadler
=20

From: Ong, Lyndon [mailto:Lyong@Ciena.com]
Sent: Monday, July 24, 2006 2: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
=20
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
-- 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.
=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 conclusions are no
different.
=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".=20
=20
I think we're experiencing a significant miscommunication...
=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"=20
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]
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:=20
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.      What is the intent of this document? Will it be published as an=20
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=20
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.      Section 4.1/Table 1 and the statement under the table
identifying=20
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).=20
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

Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 25 Jul 2006 21:06:19 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6B02E.02E50918"
Subject: RE: Proposed response to OIF on OSPF ENNI
Date: Tue, 25 Jul 2006 14:05:09 -0700
Message-ID: <626FC7C6A97381468FB872072AB5DDC8C2DC25@XCH-SW-42.sw.nos.boeing.com>
Thread-Topic: Proposed response to OIF on OSPF ENNI
Thread-Index: Acas0Ha/aYxFikOBS5m873SVRoVJxgAACLxQAAHPZJAAnZ89IAACGznwAAEH8mAAAxLNQAAAS4QQACJG/RAAAkvKMAAMx4RA
From: "Drake, John E" <John.E.Drake2@boeing.com>
To: <ccamp@ops.ietf.org>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6B02E.02E50918
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

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

	-----Original Message-----
	From: Sadler, Jonathan B. [mailto:Jonathan.Sadler@tellabs.com]=20
	Sent: Tuesday, July 25, 2006 9:29 AM
	To: Brungard, Deborah A, ALABS; Ong, Lyndon; ccamp@ops.ietf.org
	Cc: Adrian Farrel
	Subject: RE: Proposed response to OIF on OSPF ENNI
=09
=09

	Hi Deborah,

	=20

	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

	=20

	Regarding Topic 1:

	=20

	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"

	=20

	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.

	=20

	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.

	=20

	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.

	=20

	Regarding Topic 2:

	=20

	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.

	=20

	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?

	=20

	Regarding Topic 3:

	=20

	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.

	=20

	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.

	=20

	I look forward to reviewing the new liaison text.

	=20

	Jonathan Sadler

	=20

=09
________________________________

	From: Brungard, Deborah A, ALABS [mailto:dbrungard@att.com]=20
	Sent: Tuesday, July 25, 2006 9:58 AM
	To: Sadler, Jonathan B.; Ong, Lyndon; ccamp@ops.ietf.org
	Cc: Adrian Farrel
	Subject: RE: Proposed response to OIF on OSPF ENNI

	=20

	Hi Jonathan,

	=20

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

=09
https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=3D150

	=20

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

	=20

	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.

	=20

	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.

	=20

	"Significant" Thanks on the confusion;-)

	Deborah

	=20

=09
________________________________

	From: Sadler, Jonathan B. [mailto:Jonathan.Sadler@tellabs.com]=20
	Sent: Monday, July 24, 2006 5:38 PM
	To: Brungard, Deborah A, ALABS; Ong, Lyndon; ccamp@ops.ietf.org
	Cc: Adrian Farrel
	Subject: RE: Proposed response to OIF on OSPF ENNI

	Hi Deborah,

	=20

	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.

	=20

	Regards,

	=20

	Jonathan Sadler

	=20

=09
________________________________

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

	=20

	Hi Jonathan,

	=20

	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.

	=20

	Thanks,

	Deborah

	=20

=09
________________________________

	From: Sadler, Jonathan B. [mailto:Jonathan.Sadler@tellabs.com]=20
	Sent: Monday, July 24, 2006 4:32 PM
	To: Brungard, Deborah A, ALABS; Ong, Lyndon; ccamp@ops.ietf.org
	Cc: Adrian Farrel
	Subject: RE: Proposed response to OIF on OSPF ENNI

	Hi Deborah, Lyndon, et al,

	=20

	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.

	=20

	Given that:

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

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

	=20

	Regards,

	=20

	Jonathan Sadler

	=20

=09
________________________________

	From: Ong, Lyndon [mailto:Lyong@Ciena.com]=20
	Sent: Monday, July 24, 2006 2: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

	=20

	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

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

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

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

	=20

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

	=20

	Cheers,

	=20

	Lyndon

	=20

=09
________________________________

	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

=09
________________________________

	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

=09
________________________________

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

	=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
	=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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_01C6B02E.02E50918
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:v =3D=20
"urn:schemas-microsoft-com:vml" xmlns:o =3D=20
"urn:schemas-microsoft-com:office:office" xmlns:w =3D=20
"urn:schemas-microsoft-com:office:word" xmlns:p =3D=20
"urn:schemas-microsoft-com:office:powerpoint" xmlns:oa =3D=20
"urn:schemas-microsoft-com:office:activation" xmlns:st1 =3D=20
"urn:schemas-microsoft-com:office:smarttags"><HEAD><TITLE>Message</TITLE>=

<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1556" name=3DGENERATOR><!--[if !mso]>
<STYLE>v\:* {
	BEHAVIOR: url(#default#VML)
}
o\:* {
	BEHAVIOR: url(#default#VML)
}
w\:* {
	BEHAVIOR: url(#default#VML)
}
.shape {
	BEHAVIOR: url(#default#VML)
}
</STYLE>
<![endif]--><o:SmartTagType=20
downloadurl=3D"http://www.5iamas-microsoft-com:office:smarttags" =
name=3D"State"=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTagT=
ype><o:SmartTagType=20
downloadurl=3D"http://www.5iamas-microsoft-com:office:smarttags" =
name=3D"City"=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTagT=
ype><o:SmartTagType=20
downloadurl=3D"http://www.5iantlavalamp.com/" name=3D"place"=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTagT=
ype><o:SmartTagType=20
downloadurl=3D"http://www.microsoft.com" name=3D"PersonName"=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTagT=
ype><!--[if !mso]>
<STYLE>st1\:* {
	BEHAVIOR: url(#default#ieooui)
}
</STYLE>
<![endif]-->
<STYLE>@font-face {
	font-family: Wingdings;
}
@font-face {
	font-family: MS Mincho;
}
@font-face {
	font-family: Tahoma;
}
@font-face {
	font-family: @MS Mincho;
}
@page Section1 {size: 8.5in 11.0in; margin: 1.0in 1.25in 1.0in 1.25in; }
P.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
LI.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
DIV.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline
}
A:visited {
	COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlinkFollowed {
	COLOR: blue; TEXT-DECORATION: underline
}
PRE {
	FONT-SIZE: 10pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Courier New"
}
SPAN.EmailStyle18 {
	COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal
}
SPAN.EmailStyle19 {
	COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal
}
SPAN.EmailStyle20 {
	COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal
}
SPAN.EmailStyle21 {
	COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal-reply
}
DIV.Section1 {
	page: Section1
}
OL {
	MARGIN-BOTTOM: 0in
}
UL {
	MARGIN-BOTTOM: 0in
}
</STYLE>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]--></HEAD>
<BODY lang=3DEN-US vLink=3Dblue link=3Dblue>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D966220321-25072006>Is=20
Jonathan showing off the fact that he just completed a typing=20
class?</SPAN></FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
  face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B> =
Sadler, Jonathan=20
  B. [mailto:Jonathan.Sadler@tellabs.com] <BR><B>Sent:</B> Tuesday, July =
25,=20
  2006 9:29 AM<BR><B>To:</B> Brungard, Deborah A, ALABS; Ong, Lyndon;=20
  ccamp@ops.ietf.org<BR><B>Cc:</B> Adrian Farrel<BR><B>Subject:</B> RE: =
Proposed=20
  response to OIF on OSPF ENNI<BR><BR></FONT></DIV>
  <DIV class=3DSection1>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Hi=20
  Deborah,<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">It seems =
that your=20
  response centers on three topics:<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal=20
  style=3D"MARGIN-LEFT: 21pt; TEXT-INDENT: -0.25in; mso-list: l0 level1 =
lfo3"><![if !supportLists]><FONT=20
  face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><SPAN=20
  style=3D"mso-list: Ignore">1.<FONT face=3D"Times New Roman" =
size=3D1><SPAN=20
  style=3D"FONT: 7pt 'Times New =
Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </SPAN></FONT></SPAN></SPAN></FONT><![endif]><FONT face=3DArial =
color=3Dnavy=20
  size=3D2><SPAN style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">The=20
  alignment of the IETF architecture/eval documents with the=20
  requirements/architecture of other =
groups,<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal=20
  style=3D"MARGIN-LEFT: 21pt; TEXT-INDENT: -0.25in; mso-list: l0 level1 =
lfo3"><![if !supportLists]><FONT=20
  face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><SPAN=20
  style=3D"mso-list: Ignore">2.<FONT face=3D"Times New Roman" =
size=3D1><SPAN=20
  style=3D"FONT: 7pt 'Times New =
Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </SPAN></FONT></SPAN></SPAN></FONT><![endif]><FONT face=3DArial =
color=3Dnavy=20
  size=3D2><SPAN style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">The OIF=20
  <st1:place w:st=3D"on"><st1:City w:st=3D"on">Draft</st1:City> =
<st1:State=20
  w:st=3D"on">IA</st1:State></st1:place> making statements regarding the =

identifiers used by GMPLS routing when carried by OSPF,=20
 and<o:p></o:p>
 <![if !supportLists]><FONT=20
 face=3DArial color=3Dnavy size=3D2><SPAN=20
 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><SPAN=20
 style=3D"mso-list: Ignore">3.<SPAN=20
 style=3D"FONT: 7pt 'Times New =
Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
 <![endif]>Whether=20
 the participants in the design teams did so in any official capacity =
on behalf=20
 of other groups<o:p></o:p>
 <SPAN=20
 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p>
 <SPAN=20
 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Regarding =
Topic=20
 1:<o:p></o:p>
 <SPAN=20
 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p>
 It&#8217;s too=20
 bad that your exhibit makes my point well &#8211; that the text was =
NOT liaised to=20
 the ITU for review/agreement prior to sending it for publication. =
&nbsp;If you=20
 look at the liaison you provided:<o:p></o:p>
 <![if !supportLists]><FONT=20
 face=3DArial color=3Dnavy size=3D2><SPAN=20
 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><SPAN=20
 style=3D"mso-list: Ignore">-<SPAN=20
 style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;=20
 <![endif]>you will=20
 see it says &#8220;for information&#8221;, not for action meaning =
there is no intent to=20
 find out if it is aligned, and<o:p></o:p>
 <![if !supportLists]><FONT=20
 face=3DArial color=3Dnavy size=3D2><SPAN=20
 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><SPAN=20
 style=3D"mso-list: Ignore">-<SPAN=20
 style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;=20
 <![endif]>you will=20
 note the email you provided states it was notifying ITU of =
publication.=20
 Witness the specific text:<o:p></o:p>
 <FONT=20
 face=3DArial color=3Dnavy size=3D2><SPAN=20
 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">&#8220;The =
CCAMP working=20
 group is pleased to inform you of the _<SPAN=20
 style=3D"FONT-STYLE: italic">publication_ of RFC=20
 4258"<o:p></o:p>
 <SPAN=20
 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p>
 Again, I=20
 state that the final IETF requirements and IETF evaluation documents =
were not=20
 liaised to the ITU for review/agreement, so it is impossible to say if =
they=20
 are aligned with the OIF requirements.<o:p></o:p>
 <SPAN=20
 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p>
 To=20
 remove any potential receiver confusion what this statement means, let =
me put=20
 in another way:<o:p></o:p>
 <FONT=20
 face=3DArial color=3Dnavy size=3D2><SPAN=20
 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">WHEREAS,&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
 the ITU has developed a set of requirements and architecture for ASON =
routing=20
 commonly known as G.8080, G.7715 and G.7715.1,=20
and<o:p></o:p>
 <FONT=20
 face=3DArial color=3Dnavy size=3D2><SPAN=20
 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">WHEREAS,&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
 the members of the OIF are on record that the requirements and =
architecture=20
 specified in G.8080, G.7715 and G.7715.1 are the requirements and =
architecture=20
 to be followed by the OIF, and<o:p></o:p>
 <FONT=20
 face=3DArial color=3Dnavy size=3D2><SPAN=20
 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">WHEREAS,&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
 the IETF has been working on documents which purport to be accurate=20
 restatements of the requirements and architecture specified by ITU for =
ASON=20
 routing, and<o:p></o:p>
 <FONT=20
 face=3DArial color=3Dnavy size=3D2><SPAN=20
 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">WHEREAS,&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
 the final documents of the IETF have not been liaised to the ITU for =
the=20
 purposes of review or agreement prior to publication, allowing =
determination=20
 that they are accurate restatements, <o:p></o:p>
 <FONT=20
 face=3DArial color=3Dnavy size=3D2><SPAN=20
 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">THEREFORE,&nbsp;&nbsp;=20
 it cannot be said that the documents of the IETF are aligned with the=20
 requirements or architecture specified by the ITU,=20
 and<o:p></o:p>
 <FONT=20
 face=3DArial color=3Dnavy size=3D2><SPAN=20
 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">THEREFORE,&nbsp;&nbsp;=20
 it cannot be said that the documents of the IETF are aligned with the=20
 requirements or architecture of the OIF.<o:p></o:p>
 <SPAN=20
 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p>
 Please=20
 be aware the reason that the OIF did NOT restate the ITU Requirements =
and=20
 Architecture documents (unlike CCAMP), and instead went on record =
saying that=20
 the ITU documents were the requirements and architecture documents to =
be=20
 followed was to REMOVE the possibility of OIF-speak, and support =
convergence=20
 on well-defined ITU-speak. This goes a long way to removing=20
 confusion.<o:p></o:p>
 <SPAN=20
 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p>
 <SPAN=20
 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Regarding =
Topic=20
 2:<o:p></o:p>
 <SPAN=20
 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p>
 The IETF=20
 requirements and evaluation documents don&#8217;t make any specific =
statements about=20
 the fitness of IETF protocols for ASON routing. The OIF document text =
(which=20
 predates even the IETF requirements document) is making specific =
statements=20
 about OSPF &#8211; statements that are based on Section 10 of G.8080. =
CCAMP has not=20
 finished (started?) a document that makes any specific statements =
about=20
 OSPF.<o:p></o:p>
 <SPAN=20
 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p>
 Again I=20
 ask, wouldn&#8217;t it be better to look at this document which has =
been implemented=20
 by many vendors, and successfully interoperability tested many times =
over many=20
 years to see what can be leveraged instead of starting from=20
 scratch?<o:p></o:p>
 <SPAN=20
 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p>
 <SPAN=20
 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Regarding =
Topic=20
 3:<o:p></o:p>
 <SPAN=20
 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p>
 While=20
 Lyndon and I are participants in the ITU and OIF, we are not =
authorized to=20
 make statements on behalf of either organization other than the =
statements=20
 authorized by those organizations. &nbsp;Our participation in the =
design teams=20
 were not as official representatives of the ITU or OIF.&nbsp; The only =
way for=20
 the documents to be considered aligned would be to liaise them prior =
to=20
 publication to the ITU or OIF for review/agreement and wait for the=20
 response.&nbsp; Again, since this was not done, it is unclear if the =
documents=20
 are in alignment.<o:p></o:p>
 <SPAN=20
 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p>
 It=20
 should also be noted that the OIF has been interested in setting up a =
formal=20
 OIF-IETF liaison relationship to remove this misconception, while =
CCAMP has=20
 prevented it. &nbsp;It seems that the confusion in the IETF would be =
lower if=20
 the liaison relationship was formed.&nbsp; Certainly, this level of =
confusion=20
 does not exist in the ITU where an OIF-ITU liaison relationship has =
existed=20
 for many years.<o:p></o:p>
 <SPAN=20
 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p>
 <SPAN=20
 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">I look =
forward to=20
 reviewing the new liaison text.<o:p></o:p>
 <SPAN=20
 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p>
 <st1:PersonName=20
 style=3D"BACKGROUND-POSITION: left bottom; BACKGROUND-IMAGE: =
url(res://ietag.dll/#34/#1001); BACKGROUND-REPEAT: repeat-x"=20
 w:st=3D"on"><SPAN=20
 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Jonathan=20
 Sadler</st1:PersonName><SPAN=20
 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p></o:p>
 <SPAN=20
 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p>
 <DIV>
 <DIV class=3DMsoNormal style=3D"TEXT-ALIGN: center" =
align=3Dcenter><FONT=20
 face=3D"Times New Roman" size=3D3>
 <HR tabIndex=3D-1 align=3Dcenter width=3D"100%" SIZE=3D2>
 </DIV>
 <SPAN=20
 style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma">From:<FONT=20
 face=3DTahoma size=3D2>=20
 Brungard, Deborah A, ALABS [mailto:dbrungard@att.com] <SPAN=20
 style=3D"FONT-WEIGHT: bold">Sent: Tuesday, July 25, 2006 =
9:58=20
 AM To: Sadler, =
Jonathan B.;=20
 Ong, Lyndon; ccamp@ops.ietf.org <SPAN=20
 style=3D"FONT-WEIGHT: bold">Cc: Adrian Farrel <SPAN=20
 style=3D"FONT-WEIGHT: bold">Subject: RE: Proposed response =
to OIF on=20
 OSPF ENNI<o:p></o:p></DIV>
 <SPAN=20
 style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p>
 <SPAN=20
 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Hi=20
 Jonathan,<o:p></o:p>
 <SPAN=20
 style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p>
 <SPAN=20
 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">I think you =
meant OIF=20
 below, as ITU and IETF work on ASON has been tightly coordinated e.g. =
a quick=20
 back search:<o:p></o:p>
 <SPAN=20
 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial"><A=20
 =
href=3D"https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=3D=
150">https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=3D1=
50</A><o:p></o:p>
 <SPAN=20
 style=3D"FONT-SIZE: 12pt; COLOR: =
navy"><o:p>&nbsp;</o:p>
 <SPAN=20
 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">This =
mis-match is=20
 always the concern when work is duplicated&nbsp;in other groups.For =
OIF=20
 to&nbsp;be progressing&nbsp;a document identifying issues with GMPLS =
for=20
 supporting ASON when already CCAMP has finished their document is not =
only a=20
 misuse of people's time (both in OIF and IETF),<SPAN=20
 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"> =
<FONT=20
 face=3DArial color=3Dblue size=3D2><SPAN=20
 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">it also =
causes=20
 confusion in the industry (we now have ITU-speak, CCAMP-speak, and=20
 OIF-speak).<SPAN=20
 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p></o:p>
 <SPAN=20
 style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p>
 <SPAN=20
 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">As the hope =
of the=20
 CCAMP's ASON Design Teams was to have a representation of ITU, OIF, =
and CCAMP=20
 (especially considering Lyndon is OIF's Liaison to CCAMP (and editor =
of the=20
 OIF document) and you as chair),&nbsp;if both of you have difficulty =
judging=20
 the alignment of this document vs. ASON requirements and CCAMP's work, =
then=20
 the document is not helping either OIF's intention to&nbsp;develop =
standards=20
 in&nbsp;alignment with ITU and IETF&nbsp;or CCAMP's ability to develop =
an ASON=20
 solution.<SPAN=20
 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p></o:p>
 <SPAN=20
 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p>
 <SPAN=20
 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">We should =
re-spin the=20
 Liaison&nbsp;to inform OIF that this work has been completed in =
CCAMP&nbsp;and=20
 to&nbsp;request that&nbsp;OIF's evaluation sections be removed and =
replaced=20
 with references to the Evaluation document (vs. trying to do =
multiple-speak=20
 which has us all confused) and expand on the comments (Dimitri's mail =
which=20
 Lyndon has agreed is very useful). I'll work on it today, and send=20
 later.<SPAN=20
 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p></o:p>
 <SPAN=20
 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p>
 <SPAN=20
 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
Arial">"Significant" Thanks=20
 on the confusion;-)<o:p></o:p>
 <SPAN=20
 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
Arial">Deborah<o:p></o:p>
 <SPAN=20
 style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p>
 <DIV class=3DMsoNormal style=3D"TEXT-ALIGN: center" =
align=3Dcenter><FONT=20
 face=3D"Times New Roman" size=3D3>
 <HR tabIndex=3D-1 align=3Dcenter width=3D"100%" SIZE=3D2>
 </DIV>
 <SPAN=20
 style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma">From:<FONT=20
 face=3DTahoma size=3D2> Sadler,=20
 Jonathan B. [mailto:Jonathan.Sadler@tellabs.com] <SPAN=20
 style=3D"FONT-WEIGHT: bold">Sent: Monday, July 24, 2006 =
5:38=20
 PM To: Brungard, =
Deborah A,=20
 ALABS; Ong, Lyndon; ccamp@ops.ietf.org <SPAN=20
 style=3D"FONT-WEIGHT: bold">Cc: Adrian Farrel <SPAN=20
 style=3D"FONT-WEIGHT: bold">Subject: RE: Proposed response =
to OIF on=20
 OSPF ENNI<o:p></o:p>
 <SPAN=20
 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Hi=20
 Deborah,<o:p></o:p>
 <SPAN=20
 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p>
 <SPAN=20
 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">While I do =
not speak=20
 for the OIF, I can say that the members of the OIF are on record (by =
motion)=20
 to follow the Requirements and Architecture specified in G.8080, =
G.7715 and=20
 G.7715.1. &nbsp;Since the final IETF requirements and IETF evaluations =

documents were never liaised to the ITU for comment/agreement before =
they were=20
 sent for publication, I cannot say that they are aligned with the =
requirements=20
 of the OIF.<o:p></o:p>
 <SPAN=20
 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p>
 <SPAN=20
 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">Regards,<o:p></o:p>
 <SPAN=20
 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p>
 <st1:PersonName=20
 style=3D"BACKGROUND-POSITION: left bottom; BACKGROUND-IMAGE: =
url(res://ietag.dll/#34/#1001); BACKGROUND-REPEAT: repeat-x"=20
 w:st=3D"on"><SPAN=20
 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Jonathan=20
 Sadler</st1:PersonName><SPAN=20
 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p></o:p>
 <SPAN=20
 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p>
 <DIV>
 <DIV class=3DMsoNormal style=3D"TEXT-ALIGN: center" =
align=3Dcenter><FONT=20
 face=3D"Times New Roman" size=3D3>
 <HR tabIndex=3D-1 align=3Dcenter width=3D"100%" SIZE=3D2>
 </DIV>
 <SPAN=20
 style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma">From:<FONT=20
 face=3DTahoma size=3D2>=20
 Brungard, Deborah A, ALABS [mailto:dbrungard@att.com] <SPAN=20
 style=3D"FONT-WEIGHT: bold">Sent: Monday, July 24, 2006 =
4:31=20
 PM To: Sadler, =
Jonathan B.;=20
 Ong, Lyndon; ccamp@ops.ietf.org <SPAN=20
 style=3D"FONT-WEIGHT: bold">Cc: Adrian Farrel <SPAN=20
 style=3D"FONT-WEIGHT: bold">Subject: RE: Proposed response =
to OIF on=20
 OSPF ENNI<o:p></o:p></DIV>
 <SPAN=20
 style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p>
 <SPAN=20
 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Hi=20
 Jonathan,<o:p></o:p>
 <SPAN=20
 style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p>
 <SPAN=20
 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">I just sent =
mail to=20
 Lyndon to ask if he felt CCAMP's work was aligned. From your mail =
below, you=20
 do believe that CCAMP's ASON requirements document and evaluation =
document=20
 meet the needs of OIF? As the OIF Liaison stated it specified =
requirements, we=20
 do&nbsp;want to ensure that the work is =
aligned.<o:p></o:p>
 <SPAN=20
 style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p>
 <SPAN=20
 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
Arial">Thanks,<o:p></o:p>
 <SPAN=20
 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
Arial">Deborah<o:p></o:p>
 <SPAN=20
 style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p>
 <DIV class=3DMsoNormal style=3D"TEXT-ALIGN: center" =
align=3Dcenter><FONT=20
 face=3D"Times New Roman" size=3D3>
 <HR tabIndex=3D-1 align=3Dcenter width=3D"100%" SIZE=3D2>
 </DIV>
 <SPAN=20
 style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma">From:<FONT=20
 face=3DTahoma size=3D2> Sadler,=20
 Jonathan B. [mailto:Jonathan.Sadler@tellabs.com] <SPAN=20
 style=3D"FONT-WEIGHT: bold">Sent: Monday, July 24, 2006 =
4:32=20
 PM To: Brungard, =
Deborah A,=20
 ALABS; Ong, Lyndon; ccamp@ops.ietf.org <SPAN=20
 style=3D"FONT-WEIGHT: bold">Cc: Adrian Farrel <SPAN=20
 style=3D"FONT-WEIGHT: bold">Subject: RE: Proposed response =
to OIF on=20
 OSPF ENNI<o:p></o:p>
 <SPAN=20
 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Hi Deborah, =
Lyndon,=20
 et al,<o:p></o:p>
 <SPAN=20
 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p>
 <SPAN=20
 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Some =
additional=20
 comments:<o:p></o:p>
 <SPAN=20
 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">&nbsp;- The =

  hierarchical model discussed in the draft IA liaised may be supported =
without=20
  any modifications to OSPF.&nbsp; As discussed in earlier emails, it =
can be=20
  implemented solely through the import/export of information described =
in=20
  Appendix I of G.7715.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">&nbsp;- The =
draft IA=20
  also recognizes namespace issues exist between Router ID and the IP =
Address=20
  that messages are sent to (ITU calls this the RC PC SCN =
address).&nbsp; This=20
  issue is also discussed in=20
  draft-ietf-ccamp-gmpls-addressing.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Given=20
  that:<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal style=3D"MARGIN-LEFT: 21pt; TEXT-INDENT: =
-0.25in"><FONT=20
  face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">-</SPAN></FONT><FONT=20
  color=3Dnavy size=3D1><SPAN=20
  style=3D"FONT-SIZE: 7pt; COLOR: =
navy">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </SPAN></FONT><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">CCAMP has a =
milestone=20
  to publish an ASON routing solution by Nov 2006, =
<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal style=3D"MARGIN-LEFT: 21pt; TEXT-INDENT: =
-0.25in"><FONT=20
  face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">-</SPAN></FONT><FONT=20
  color=3Dnavy size=3D1><SPAN=20
  style=3D"FONT-SIZE: 7pt; COLOR: =
navy">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </SPAN></FONT><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">CCAMP =
didn&#8217;t have at=20
  the time this was liaised (doesn&#8217;t have today?) a working group =
document,=20
  and<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal style=3D"MARGIN-LEFT: 21pt; TEXT-INDENT: =
-0.25in"><FONT=20
  face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">-</SPAN></FONT><FONT=20
  color=3Dnavy size=3D1><SPAN=20
  style=3D"FONT-SIZE: 7pt; COLOR: =
navy">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </SPAN></FONT><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">the draft =
IA has been=20
  successfully implemented by more than a dozen vendors and =
interop-tested many=20
  times,<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">I would =
expect that=20
  we should be looking at this as experience/text that could be=20
  leveraged...&nbsp; &#8220;Running code&#8230;&#8221; and all =
that&#8230;<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">Regards,<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><st1:PersonName=20
  style=3D"BACKGROUND-POSITION: left bottom; BACKGROUND-IMAGE: =
url(res://ietag.dll/#34/#1001); BACKGROUND-REPEAT: repeat-x"=20
  w:st=3D"on"><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Jonathan=20
  Sadler</SPAN></FONT></st1:PersonName><FONT face=3DArial color=3Dnavy =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <DIV>
  <DIV class=3DMsoNormal style=3D"TEXT-ALIGN: center" =
align=3Dcenter><FONT=20
  face=3D"Times New Roman" size=3D3><SPAN style=3D"FONT-SIZE: 12pt">
  <HR tabIndex=3D-1 align=3Dcenter width=3D"100%" SIZE=3D2>
  </SPAN></FONT></DIV>
  <P class=3DMsoNormal><B><FONT face=3DTahoma size=3D2><SPAN=20
  style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma">From:</SPAN></FONT></B><FONT=20
  face=3DTahoma size=3D2><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma"> Ong,=20
  Lyndon [mailto:Lyong@Ciena.com] <BR><B><SPAN=20
  style=3D"FONT-WEIGHT: bold">Sent:</SPAN></B> Monday, July 24, 2006 =
2:33=20
  PM<BR><B><SPAN style=3D"FONT-WEIGHT: bold">To:</SPAN></B> Brungard, =
Deborah A,=20
  ALABS; Sadler, Jonathan B.; ccamp@ops.ietf.org<BR><B><SPAN=20
  style=3D"FONT-WEIGHT: bold">Cc:</SPAN></B> Adrian Farrel<BR><B><SPAN=20
  style=3D"FONT-WEIGHT: bold">Subject:</SPAN></B> RE: Proposed response =
to OIF on=20
  OSPF ENNI</SPAN></FONT><o:p></o:p></P></DIV>
  <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
  style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Hi=20
  Deborah,</SPAN></FONT><o:p></o:p></P>
  <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
  style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Here's what =
I would=20
  say&nbsp;is in and not in the OIF =
document:</SPAN></FONT><o:p></o:p></P>
  <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
  style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">-- G.7715, =
G.7715.1=20
  and the IETF eval and solutions draft all identify a need to support=20
  hierarchical</SPAN></FONT><o:p></o:p></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">routing =
areas for=20
  ASON, I am perplexed as to why this seems to be viewed as a new=20
  feature.</SPAN></FONT><o:p></o:p></P>
  <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
  style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">-- the =
document does=20
  not specify the domain of usage and leaves this to the carrier.&nbsp; =
This is=20
  no different</SPAN></FONT><o:p></o:p></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">from =
G.7715.1 and=20
  IETF drafts that do not explicitly state whether they are used for =
intra- or=20
  inter-domain</SPAN></FONT><o:p></o:p></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
Arial">interfaces.</SPAN></FONT><o:p></o:p></P>
  <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
  style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">-- GMPLS =
OSPF does=20
  not support a 1:N or N:1 relationship between routing controller and=20
  transport</SPAN></FONT><o:p></o:p></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">node, hence =

extensions are felt to be required - and are proposed in the eval =
solutions=20
 draft. The <o:p></o:p>
 <SPAN=20
 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">conclusions =
are no=20
 different.<o:p></o:p>
 <SPAN=20
 style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p>
 <SPAN=20
 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">-- the =
document does=20
 not in fact define any standard extensions to the protocols, and =
points to=20
 future work<o:p></o:p>
 <SPAN=20
 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">in IETF and =
ITU to=20
 provide these.&nbsp; Therefore I cannot understand where you say "new=20
 extensions to<o:p></o:p>
 <SPAN=20
 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">OSPF are =
specified"=20
 and "none...align with the CCAMP's GMPLS-ASON work".&nbsp;=20
 <o:p></o:p>
 <DIV>
 <SPAN=20
 style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p></DIV>
 <DIV>
 <SPAN=20
 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">I think =
we're=20
 experiencing a significant=20
 miscommunication...<o:p></o:p></DIV>
 <DIV>
 <SPAN=20
 style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p></DIV>
 <DIV>
 <SPAN=20
 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
Arial">Cheers,<o:p></o:p></DIV>
 <DIV>
 <SPAN=20
 style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p></DIV>
 <DIV>
 <SPAN=20
 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
Arial">Lyndon<o:p></o:p></DIV>
 <SPAN=20
 style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p>
 <DIV class=3DMsoNormal style=3D"TEXT-ALIGN: center" =
align=3Dcenter><FONT=20
 face=3D"Times New Roman" size=3D3>
 <HR tabIndex=3D-1 align=3Dcenter width=3D"100%" SIZE=3D2>
 </DIV>
 <SPAN=20
 style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma">From:<FONT=20
 face=3DTahoma size=3D2>=20
 owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] <SPAN=20
 style=3D"FONT-WEIGHT: bold">On Behalf Of Brungard, Deborah =
A,=20
 ALABS Sent: Monday, =
July 24,=20
 2006 12:15 PM To: =
Sadler,=20
 Jonathan B.; ccamp@ops.ietf.org <SPAN=20
 style=3D"FONT-WEIGHT: bold">Cc: Adrian Farrel <SPAN=20
 style=3D"FONT-WEIGHT: bold">Subject: RE: Proposed response =
to OIF on=20
 OSPF ENNI<o:p></o:p>
 <SPAN=20
 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Hi =
Jonathan, (and=20
 Lyndon),<o:p></o:p>
 <SPAN=20
 style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p>
 <SPAN=20
 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Thanks to =
both of you=20
 for responding.<o:p></o:p>
 <SPAN=20
 style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p>
 <SPAN=20
 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
Arial">"Significant" was=20
 referencing:<o:p></o:p>
 <SPAN=20
 style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p>
 <SPAN=20
 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">-=20
 supports&nbsp;a&nbsp;(new) hierarchical OSPF=20
model<o:p></o:p>
 <SPAN=20
 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
Arial">-&nbsp;supports&nbsp;inter-domain=20
 (inter-carrier) OSPF (not supported by today's=20
 OSPF)<o:p></o:p>
 <SPAN=20
 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">- =
identifies=20
 namespace issues with GMPLS OSPF which do not exist, and proposes =
extensions=20
 to "fix"<o:p></o:p>
 <SPAN=20
 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">- new =
extensions to=20
 OSPF are specified<o:p></o:p>
 <SPAN=20
 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">- none of =
the=20
 proposed extensions align with CCAMP's GMPLS-ASON=20
 work<o:p></o:p>
 <SPAN=20
 style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p>
 <SPAN=20
 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Did you =
have another=20
 adjective to suggest? We&nbsp;were thinking&nbsp;"significant" was =
rather soft=20
 considering the above. Though if it's just ITU-speak differences, why =
does the=20
 OIF liaison state it reflects several years of work including testing? =
Any=20
 insight (alignment mapping to CCAMP's work) which you or Lyndon can =
provide=20
 would be helpful.&nbsp;The divergence is&nbsp;baffling to=20
 us.<o:p></o:p>
 <SPAN=20
 style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p>
 <SPAN=20
 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
Arial">Deborah<o:p></o:p>
 <SPAN=20
 style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p>
 <SPAN=20
 style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p>
 <DIV class=3DMsoNormal style=3D"TEXT-ALIGN: center" =
align=3Dcenter><FONT=20
 face=3D"Times New Roman" size=3D3>
 <HR tabIndex=3D-1 align=3Dcenter width=3D"100%" SIZE=3D2>
 </DIV>
 <SPAN=20
 style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma">From:<FONT=20
 face=3DTahoma size=3D2> Sadler,=20
 Jonathan B. [mailto:Jonathan.Sadler@tellabs.com] <SPAN=20
 style=3D"FONT-WEIGHT: bold">Sent: Friday, July 21, 2006 =
11:34=20
 AM To: Brungard, =
Deborah A,=20
 ALABS; ccamp@ops.ietf.org Cc:=20
 Adrian Farrel Subject: RE:=20
 Proposed response to OIF on OSPF ENNI<o:p></o:p>
 <SPAN=20
 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Hi Deborah =
and=20
 Adrian,<o:p></o:p>
 <SPAN=20
 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p>
 <SPAN=20
 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">I =
haven&#8217;t seen much=20
 discussion of the OIF E-NNI Routing document on the CCAMP list. =
&nbsp;Can you=20
 tell me what parts of the document are &#8220;significant =
modifications to the=20
 operation of OSPF&#8221;?<o:p></o:p>
 <SPAN=20
 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p>
 <SPAN=20
 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">Thanks,<o:p></o:p>
 <SPAN=20
 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p>
 <st1:PersonName=20
 style=3D"BACKGROUND-POSITION: left bottom; BACKGROUND-IMAGE: =
url(res://ietag.dll/#34/#1001); BACKGROUND-REPEAT: repeat-x"=20
 w:st=3D"on"><SPAN=20
 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Jonathan=20
 Sadler</st1:PersonName><SPAN=20
 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p></o:p>
 <SPAN=20
 style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p>
 <DIV>
 <DIV class=3DMsoNormal style=3D"TEXT-ALIGN: center" =
align=3Dcenter><FONT=20
 face=3D"Times New Roman" size=3D3>
 <HR tabIndex=3D-1 align=3Dcenter width=3D"100%" SIZE=3D2>
 </DIV>
 <SPAN=20
 style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma">From:<FONT=20
 face=3DTahoma size=3D2>=20
 owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] <SPAN=20
 style=3D"FONT-WEIGHT: bold">On Behalf Of Brungard, Deborah =
A,=20
 ALABS Sent: Friday, =
July 21,=20
 2006 9:38 AM To:=20
 ccamp@ops.ietf.org Cc: Adrian=20
 Farrel Subject: =
Proposed=20
 response to OIF on OSPF ENNI<o:p></o:p></DIV>
 <SPAN=20
 style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p>
 <SPAN=20
 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
Arial">Hi,<o:p></o:p>
 <SPAN=20
 style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p>
 <SPAN=20
 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">We had a=20
 communication from OIF on their OSPF ENNI specification. You can see =
the=20
 original files on <A=20
 href=3D"http://www.olddog.co.uk/ccamp.htm"><SPAN=20
 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial">http://www.olddog.co.uk/ccamp.htm</A><FONT=20
 face=3DArial color=3Dblue size=3D2><SPAN=20
 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">. Having =
assembled=20
 comments from several people and our discussions in <st1:place=20
 w:st=3D"on"><st1:City w:st=3D"on">Montreal</st1:City></st1:place>, we =
have put=20
 together the following response.<o:p></o:p>
 <SPAN=20
 style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p>
 <DIV>
 <SPAN=20
 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Please =
comment on the=20
 list in the next week.<o:p></o:p></DIV>
 <DIV>
 <SPAN=20
 style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p></DIV>
 <DIV>
 <SPAN=20
 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
Arial">Thanks,<o:p></o:p></DIV>
 <DIV>
 <SPAN=20
 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Adrian and=20
 Deborah<o:p></o:p></DIV>
 <SPAN=20
 style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p>
 <DIV>
 <SPAN=20
 style=3D"FONT-SIZE: 12pt">=3D =3D =3D =3D =3D =3D =3D =3D =3D =
=3D<o:p></o:p>
 <SPAN=20
 style=3D"FONT-SIZE: 12pt">Dear Jim,<o:p></o:p>
 <SPAN=20
 style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p>
 <SPAN=20
 style=3D"FONT-SIZE: 12pt">We thank you for sending us the OIF ENNI =
document in=20
 response to our request. While we appreciate the document being =
provided for=20
 information, it is concerning that this document has not been =
previously=20
 shared with CCAMP or the OSPF WG considering the document contains =
significant=20
 modifications to the operation of OSPF and reflects OIF work over the =
last=20
 several years. CCAMP has been working on GMPLS ASON for several years =
and our=20
 Design Teams include OIF participants. Even though a reply was not =
requested,=20
 we are replying, as we strongly recommend that the document not be =
published=20
 for public information in its current =
form.<o:p></o:p>
 <SPAN=20
 style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p>
 <SPAN=20
 style=3D"FONT-SIZE: 12pt">Of most concern to CCAMP is that it is not =
aligned=20
 with RFC 4258 (Requirements for Generalized Multi-Protocol Label =
Switching=20
 (GMPLS) Routing for the Automatically Switched Optical Network (ASON)) =
or the=20
 to-be-published: <A=20
 =
href=3D"ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpls-ason-rou=
ting-eval-03.txt">ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpl=
s-ason-routing-eval-03.txt</A>.=20
 Considering notable OIF participants are authors of both these IETF =
documents=20
 (and the same participants are contributors and the Editor for the OIF =

  document), the non-alignment is perplexing. Considering the IETF =
document is=20
  ready for publication, we suggest in the interests of time, that you =
align=20
  your document with the IETF document. If any questions on the =
interpretation=20
  of the IETF&#8217;s work, we recommend that you either utilize the =
CCAMP mail=20
  exploder or send a communication.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
  style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
  style=3D"FONT-SIZE: 12pt">Specific comments=20
include:<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal style=3D"MARGIN-LEFT: 0.25in; TEXT-INDENT: =
-0.25in"><FONT=20
  face=3D"Times New Roman" size=3D3><SPAN=20
  style=3D"FONT-SIZE: 12pt">1.</SPAN></FONT><FONT size=3D1><SPAN=20
  style=3D"FONT-SIZE: 7pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</SPAN></FONT>What is=20
  the intent of this document? Will it be published as an Implementation =

  Agreement (IA)?<BR>The title indicates it will be an Implementation =
Agreement=20
  on GMPLS OSPF extensions, but the main body of the document is a list =
of=20
  issues with GMPLS OSPF. Further, your communication to us stated the =
document=20
  was requirements on and use of OSPF-TE at the ENNI. These three views =
seem to=20
  be inconsistent.<o:p></o:p></P>
  <P class=3DMsoNormal style=3D"MARGIN-LEFT: 0.25in; TEXT-INDENT: =
-0.25in"><I><FONT=20
  face=3D"Times New Roman" size=3D3><SPAN=20
  style=3D"FONT-SIZE: 12pt; FONT-STYLE: =
italic">2.</SPAN></FONT></I><I><FONT=20
  size=3D1><SPAN=20
  style=3D"FONT-SIZE: 7pt; FONT-STYLE: =
italic">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </SPAN></FONT></I>The list of changes from the previous version =
(listed under=20
  the Table of Contents) includes &#8220;<I><SPAN style=3D"FONT-STYLE: =
italic">removed=20
  &#8220;intra-carrier&#8221; limitation</SPAN></I>&#8221; and the =
inclusion of Figure 1 showing=20
  the OSPF ENNI for use between vendor domains and between carrier =
domains.=20
  GMPLS OSPF-TE already supports inter-vendor operations. <BR>The =
IETF&#8217;s GMPLS=20
  ASON routing focus has been on the use of a link-state based protocol =
to=20
  support a hierarchical routing architecture (G.7715.1) within a =
carrier&#8217;s=20
  domain. Requirements for using a link state protocol as an =
inter-domain=20
  protocol between carriers are significantly different. We strongly =
disagree if=20
  you intend to publish this document as an inter-carrier OSPF ENNI=20
  Implementation Agreement claiming alignment with IETF RFCs without =
review (or=20
  agreement) by any of the IETF Working Groups.<I><SPAN=20
  style=3D"FONT-STYLE: italic"><o:p></o:p></SPAN></I></P>
  <P class=3DMsoNormal style=3D"MARGIN-LEFT: 0.25in; TEXT-INDENT: =
-0.25in"><FONT=20
  face=3D"Times New Roman" size=3D3><SPAN=20
  style=3D"FONT-SIZE: 12pt">3.</SPAN></FONT><FONT size=3D1><SPAN=20
  style=3D"FONT-SIZE: 7pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</SPAN></FONT>Section=20
  4.1/Table 1 and the statement under the table identifying issues with =
GMPLS=20
  identifier namespaces are not correct. GMPLS identifier namespaces do =
meet=20
  ASON requirements for namespace separation of the transport plane and =
control=20
  plane (Section 5.2 and 5.3/Evaluation). Perhaps you are confusing OSPF =
and=20
  GMPLS OSPF? As you also identified in your liaison that the key area =
needing=20
  review was the support of independence of functional component to =
physical=20
  location, this appears to be a key area of misunderstanding on GMPLS. =
We=20
  recommend reviewing RFC3945 (GMPLS Architecture) to understand that =
the key=20
  architecture difference between GMPLS and MPLS is the decoupling of =
the=20
  transport plane and control plane. Additionally, RFC4394, RFC4397, and =

RFC4258, provide a mapping to ITU terminology which may be helpful=20
 reading.<o:p></o:p>
 <SPAN=20
 style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p>
 <SPAN=20
 style=3D"FONT-SIZE: 12pt">We request an additional round of =
communication of=20
 this document to the IETF before approval to allow us to work with you =
to=20
 produce convergence between OIF and IETF work which, we believe, will =
be in=20
 the best interests of the industry.<o:p></o:p>
 <SPAN=20
 style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p>
 <SPAN=20
 style=3D"FONT-SIZE: 12pt">Best regards,<o:p></o:p>
 <st1:PersonName=20
 style=3D"BACKGROUND-POSITION: left bottom; BACKGROUND-IMAGE: =
url(res://ietag.dll/#34/#1001); BACKGROUND-REPEAT: repeat-x"=20
 w:st=3D"on"><SPAN=20
 style=3D"FONT-SIZE: 12pt">Adrian Farrel</st1:PersonName> =
and=20
 Deborah Brungard,<o:p></o:p>
 <SPAN=20
 style=3D"FONT-SIZE: 12pt">CCAMP =
co-chairs<o:p></o:p></DIV><PRE>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<o:p></o:p></PRE><PRE><=
FONT face=3D"Courier New" size=3D2>The =
information contained in this message may be =
privileged<o:p></o:p></PRE><PRE>and confidential and protected =
from disclosure. If the reader<o:p></o:p></PRE><PRE>of this =
message is not the intended recipient, or an =
employee<o:p></o:p></PRE><PRE>or agent responsible for =
delivering this message to the<o:p></o:p></PRE><PRE>intended =
recipient, you are hereby notified that any =
reproduction,<o:p></o:p></PRE><PRE>dissemination or =
distribution of this communication is =
strictly<o:p></o:p></PRE><PRE>prohibited. If you have =
received this communication in =
error,<o:p></o:p></PRE><PRE>please notify us immediately by =
replying to the message and<o:p></o:p></PRE><PRE>deleting =
it from your computer. Thank you. =
Tellabs<o:p></o:p></PRE><PRE>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<o:p></o:p></PRE><PRE><=
FONT face=3D"Courier New" size=3D2>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<o:p></o:p></PRE><PRE><=
FONT face=3D"Courier New" size=3D2>The =
information contained in this message may be =
privileged<o:p></o:p></PRE><PRE>and confidential and protected =
from disclosure. If the reader<o:p></o:p></PRE><PRE>of this =
message is not the intended recipient, or an =
employee<o:p></o:p></PRE><PRE>or agent responsible for =
delivering this message to the<o:p></o:p></PRE><PRE>intended =
recipient, you are hereby notified that any =
reproduction,<o:p></o:p></PRE><PRE>dissemination or =
distribution of this communication is =
strictly<o:p></o:p></PRE><PRE>prohibited. If you have =
received this communication in =
error,<o:p></o:p></PRE><PRE>please notify us immediately by =
replying to the message and<o:p></o:p></PRE><PRE>deleting =
it from your computer. Thank you. =
Tellabs<o:p></o:p></PRE><PRE>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<o:p></o:p></PRE><PRE><=
FONT face=3D"Courier New" size=3D2>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<o:p></o:p></PRE><PRE><=
FONT face=3D"Courier New" size=3D2>The =
information contained in this message may be =
privileged<o:p></o:p></PRE><PRE>and confidential and protected =
from disclosure. If the reader<o:p></o:p></PRE><PRE>of this =
message is not the intended recipient, or an =
employee<o:p></o:p></PRE><PRE>or agent responsible for =
delivering this message to the<o:p></o:p></PRE><PRE>intended =
recipient, you are hereby notified that any =
reproduction,<o:p></o:p></PRE><PRE>dissemination or =
distribution of this communication is =
strictly<o:p></o:p></PRE><PRE>prohibited. If you have =
received this communication in =
error,<o:p></o:p></PRE><PRE>please notify us immediately by =
replying to the message and<o:p></o:p></PRE><PRE>deleting =
it from your computer. Thank you. =
Tellabs<o:p></o:p></PRE><PRE>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<o:p></o:p></PRE></DIV>=
<PRE>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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
</PRE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C6B02E.02E50918--

Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 25 Jul 2006 20:33:20 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6B029.5FB98297"
Subject: RE: Proposed response to OIF on OSPF ENNI
Date: Tue, 25 Jul 2006 15:29:08 -0500
Message-ID: <A1A52203CA93634BA1748887B9993AEA03035194@USNVEX1.tellabs-west.tellabsinc.net>
Thread-Topic: Proposed response to OIF on OSPF ENNI
Thread-Index: Acas0Ha/aYxFikOBS5m873SVRoVJxgAACLxQAAHPZJAAnZ89IAACGznwAAEH8mAAAxLNQAAAS4QQACJG/RAAAkvKMAAGeikgAAJ/CNA=
From: "Sadler, Jonathan B." <Jonathan.Sadler@tellabs.com>
To: "Brungard, Deborah A, ALABS" <dbrungard@att.com>, "Ong, Lyndon" <Lyong@Ciena.com>, <ccamp@ops.ietf.org>
Cc: "Adrian Farrel" <adrian@olddog.co.uk>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6B029.5FB98297
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="us-ascii"

Hello Deborah,

=20

Again, you make my point.  The outgoing liaison you have included below
(https://datatracker.ietf.org/documents/LIAISON/file132.txt) is the ONLY
liaison sent to the ITU for review/comment on the IETF eval document.
It should also be noted that this outgoing liaison is for
draft-ietf-ccamp-gmpls-ason-routing-eval-00, while -03 is the version
that was sent for publication.

=20

And if you look at the response from the ITU (the other liaison you
include https://datatracker.ietf.org/documents/LIAISON/file151.doc) you
will note the response a comment section 6 regarding inclusion of a
scenario where multiple Ri announce on behalf of an Li.  Inclusion of
this scenario was discussed in the design team and pushed by the
"cross-participants".  Still, Section 6 of the document in the RFC
editors queue
(http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-routing
-eval-03.txt) does not contain such a scenario.

=20

It would be interesting to see what a liaison to ITU for
review/agreement would say about this document...  But, until one is
sent, it is impossible to say that the documents are completely aligned.
Likewise, it is unwise to say that it is completely aligned with the
requirements of the OIF.

=20

Regards,

=20

Jonathan Sadler

=20

________________________________

From: Brungard, Deborah A, ALABS [mailto:dbrungard@att.com]=20
Sent: Tuesday, July 25, 2006 2:04 PM
To: Sadler, Jonathan B.; Ong, Lyndon; ccamp@ops.ietf.org
Cc: Adrian Farrel
Subject: RE: Proposed response to OIF on OSPF ENNI

=20

Jonathan,

=20

These statements are not only not correct, they don't make sense
considering you were involved in the work, do a refresh and go back in
the years, and you will see ITU-IETF liaisons (prior to publication):

https://datatracker.ietf.org/documents/LIAISON/file151.doc

=20

and:

https://datatracker.ietf.org/documents/LIAISON/file132.txt

=20

and there are many more. My co-chair, our previous ccamp co-chair, and
Kam (ITU's Q14 Rap) have worked together over these past couple of years
to ensure the ASON work progressed - jointly. Considering the number of
cross-participants, a lack of IETF-OIF liaison can not be used as the
basis of the current confusion and duplication in work. And anyone can
participate and access IETF documents - it's an open process.

=20

If this OIF document is on an OSPF implementation "has been implemented
by many vendors" and the vendors intend it to be production use (vs.
experimental), then the OIF (or a vendor) needs to follow the IETF
process. That's a different subject.

=20

The current liaison was scoped as requirements which is why we are
trying to understand it.

=20

Lyndon has already responded saying he believes there is no
mis-alignment. Thanks Lyndon. We will go with that.

=20

Thanks,

Deborah

=20

________________________________

From: Sadler, Jonathan B. [mailto:Jonathan.Sadler@tellabs.com]=20
Sent: Tuesday, July 25, 2006 12:29 PM
To: Brungard, Deborah A, ALABS; Ong, Lyndon; ccamp@ops.ietf.org
Cc: Adrian Farrel
Subject: RE: Proposed response to OIF on OSPF ENNI

Hi Deborah,

=20

It seems that your response centers on three topics:

1=2E       The alignment of the IETF architecture/eval documents with the
requirements/architecture of other groups,

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

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

=20

Regarding Topic 1:

=20

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"

=20

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.

=20

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=2E7715.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,=20

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.

=20

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.

=20

Regarding Topic 2:

=20

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.

=20

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?

=20

Regarding Topic 3:

=20

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.

=20

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.

=20

I look forward to reviewing the new liaison text.

=20

Jonathan Sadler

=20

________________________________

From: Brungard, Deborah A, ALABS [mailto:dbrungard@att.com]=20
Sent: Tuesday, July 25, 2006 9:58 AM
To: Sadler, Jonathan B.; Ong, Lyndon; ccamp@ops.ietf.org
Cc: Adrian Farrel
Subject: RE: Proposed response to OIF on OSPF ENNI

=20

Hi Jonathan,

=20

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

=20

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

=20

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.

=20

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.

=20

"Significant" Thanks on the confusion;-)

Deborah

=20

________________________________

From: Sadler, Jonathan B. [mailto:Jonathan.Sadler@tellabs.com]=20
Sent: Monday, July 24, 2006 5:38 PM
To: Brungard, Deborah A, ALABS; Ong, Lyndon; ccamp@ops.ietf.org
Cc: Adrian Farrel
Subject: RE: Proposed response to OIF on OSPF ENNI

Hi Deborah,

=20

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.

=20

Regards,

=20

Jonathan Sadler

=20

________________________________

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

=20

Hi Jonathan,

=20

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.

=20

Thanks,

Deborah

=20

________________________________

From: Sadler, Jonathan B. [mailto:Jonathan.Sadler@tellabs.com]=20
Sent: Monday, July 24, 2006 4:32 PM
To: Brungard, Deborah A, ALABS; Ong, Lyndon; ccamp@ops.ietf.org
Cc: Adrian Farrel
Subject: RE: Proposed response to OIF on OSPF ENNI

Hi Deborah, Lyndon, et al,

=20

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.

=20

Given that:

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

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

=20

Regards,

=20

Jonathan Sadler

=20

________________________________

From: Ong, Lyndon [mailto:Lyong@Ciena.com]=20
Sent: Monday, July 24, 2006 2: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

=20

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

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

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

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

=20

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

=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
<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
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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_01C6B029.5FB98297
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset="us-ascii"

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:p=3D"urn:schemas-microsoft-com:office:powerpoint" xmlns:oa=3D"urn:sch=
emas-microsoft-com:office:activation" xmlns:st1=3D"urn:schemas-microsoft-co=
m:office:smarttags" xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]--><o:SmartTagType
 namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" name=3D"State"
 downloadurl=3D"http://www.5iamas-microsoft-com:office:smarttags"/>
<o:SmartTagType namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"City" downloadurl=3D"http://www.5iamas-microsoft-com:office:smartt=
ags"/>
<o:SmartTagType namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"place" downloadurl=3D"http://www.5iantlavalamp.com/"/>
<o:SmartTagType namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"PersonName" downloadurl=3D"http://www.microsoft.com"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"MS Mincho";
	panose-1:2 2 6 9 4 2 5 8 3 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:"\@MS Mincho";
	panose-1:2 2 6 9 4 2 5 8 3 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:blue;
	text-decoration:underline;}
pre
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
span.EmailStyle18
	{mso-style-type:personal;
	font-family:Arial;
	color:navy;}
span.EmailStyle19
	{mso-style-type:personal;
	font-family:Arial;
	color:navy;}
span.EmailStyle20
	{mso-style-type:personal;
	font-family:Arial;
	color:navy;}
span.EmailStyle21
	{mso-style-type:personal;
	font-family:Arial;
	color:navy;}
span.EmailStyle22
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dblue>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Hello Deborah,<o:p></o:p></span></font=
></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Again, you make my point.&nbsp; The ou=
tgoing
liaison you have included below (</span></font><font size=3D2 color=3Dblue
face=3DArial><span style=3D'font-size:10.0pt;font-family:Arial;color:blue'>=
<a
href=3D"https://datatracker.ietf.org/documents/LIAISON/file132.txt">https:/=
/datatracker.ietf.org/documents/LIAISON/file132.txt</a>)
</span></font><font size=3D2 color=3Dnavy face=3DArial><span style=3D'font-=
size:10.0pt;
font-family:Arial;color:navy'>is the ONLY liaison sent to the ITU for
review/comment on the IETF eval document. &nbsp;It should also be noted that
this outgoing liaison is for draft-ietf-ccamp-gmpls-ason-routing-eval-00, w=
hile
-03 is the version that was sent for publication.<o:p></o:p></span></font><=
/p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

And if you look at the response from t=
he
ITU (the other liaison you include =
<a
href=3D"https://datatracker.ietf.org/documents/LIAISON/file151.doc">https:/=
/datatracker.ietf.org/documents/LIAISON/file151.doc</a>)
you will note the response a comment section =
6 regarding
inclusion of a scenario where multiple Ri announce on behalf of an Li. &nbs=
p;Inclusion
of this scenario was discussed in the design team and pushed by the &#8220;=
cross-participants&#8221;.&nbsp;
Still, Section 6 of the document in the RFC editors queue (http://www.ietf.=
org/internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-eval-03.txt)
does not contain such a scenario.<o:p></o:p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>It would be interesting to see what a
liaison to ITU for review/agreement would say about this document&#8230;&nb=
sp; But,
until one is sent, it is impossible to say that the documents are completel=
y aligned.&nbsp;
Likewise, it is unwise to say that it is completely aligned with the
requirements of the OIF.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Regards,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><st1:PersonName w:st=3D"on"><font size=3D2 color=3Dnavy
 face=3DArial><span style=3D'font-size:10.0pt;font-family:Arial;color:navy'=
>Jonathan
 Sadler</span></font></st1:PersonName><font size=3D2 color=3Dnavy face=3DAr=
ial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p></o:p></span><=
/font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font siz=
e=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span style=3D'font-si=
ze:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'> Brungard,
Deborah A, ALABS [mailto:dbrungard@att.com] <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Tuesday, July 25, 2006=
 2:04
PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Sadler, Jonathan B.; Ong,
Lyndon; ccamp@ops.ietf.org<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> Adrian Farrel<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: Proposed respon=
se to
OIF on OSPF ENNI</span></font><o:p></o:p></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Jonathan,</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>These statements are not only not corr=
ect,
they don't make sense considering you were involved in the work, do a refre=
sh
and go back in the years, and you will see ITU-IETF liaisons&nbsp;(prior to
publication):</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'><a
href=3D"https://datatracker.ietf.org/documents/LIAISON/file151.doc">https:/=
/datatracker.ietf.org/documents/LIAISON/file151.doc</a></span></font><o:p><=
/o:p></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>and:</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'><a
href=3D"https://datatracker.ietf.org/documents/LIAISON/file132.txt">https:/=
/datatracker.ietf.org/documents/LIAISON/file132.txt</a></span></font><o:p><=
/o:p></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

and there are many more. My co-chair, =
our
previous ccamp co-chair, and Kam (ITU's Q14 Rap) have&nbsp;worked&nbsp;toge=
ther
over these past couple of years to ensure the ASON work progressed - jointl=
y=2E
Considering the number of cross-participants, a lack of IETF-OIF liaison can
not be&nbsp;used as&nbsp;the basis of the current confusion and duplication=
 in
work. And anyone&nbsp;can participate and access IETF documents - it's an o=
pen
process.<o:p></o:p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

If this OIF document is on an OSPF
implementation &quot;has been implemented by many vendors&quot;&nbsp;and the
vendors intend it&nbsp;to be production use (vs. experimental), then the OIF
(or a vendor)&nbsp;needs to&nbsp;follow the IETF process. That's a different
subject.<o:p></o:p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>The current liaison was scoped as
requirements which is why we are trying to understand it.</span></font><o:p=
></o:p></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

Lyndon has already responded saying he
believes there is no mis-alignment. Thanks Lyndon. We will go with that.</s=
pan><o:p></o:p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Thanks,</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Deborah</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font siz=
e=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabIndex=3D-1>

</span></font></div>

From:=
=
 Sadler,
Jonathan B. [mailto:Jonathan.Sadler@tellabs.com] 
Sent: Tuesday, July 25, 2006=
 12:29
PM 
To: Brungard, Deborah A, ALA=
BS;
Ong, Lyndon; ccamp@ops.ietf.org 
Cc: Adrian Farrel 
Subject: RE: Proposed respon=
se to
OIF on OSPF ENNI<o:p></o:p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Hi Deborah,<o:p></o:p></span></font></=
p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>It seems that your response centers on
three topics:<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:21.0pt;text-indent:-.25in'><font =
size=3D2
color=3Dnavy face=3DArial><span style=3D'font-size:10.0pt;font-family:Arial;
color:navy'>1.</span></font><font size=3D1 color=3Dnavy><span style=3D'font=
-size:
7=2E0pt;color:navy'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></font><font
size=3D2 color=3Dnavy face=3DArial><span style=3D'font-size:10.0pt;font-fam=
ily:Arial;
color:navy'>The alignment of the IETF architecture/eval documents with the
requirements/architecture of other groups,<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:21.0pt;text-indent:-.25in'><font =
size=3D2
color=3Dnavy face=3DArial><span style=3D'font-size:10.0pt;font-family:Arial;
color:navy'>2.</span></font><font size=3D1 color=3Dnavy><span style=3D'font=
-size:
7=2E0pt;color:navy'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></font><font
size=3D2 color=3Dnavy face=3DArial><span style=3D'font-size:10.0pt;font-fam=
ily:Arial;
color:navy'>The OIF <st1:place w:st=3D"on"><st1:City w:st=3D"on">Draft</st1=
:City> <st1:State
 w:st=3D"on">IA</st1:State></st1:place> making statements regarding the
identifiers used by GMPLS routing when carried by OSPF, and<o:p></o:p></spa=
n></font></p>

<p class=3DMsoNormal style=3D'margin-left:21.0pt;text-indent:-.25in'><font =
size=3D2
color=3Dnavy face=3DArial><span style=3D'font-size:10.0pt;font-family:Arial;
color:navy'>3.</span></font><font size=3D1 color=3Dnavy><span style=3D'font=
-size:
7=2E0pt;color:navy'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></font><font
size=3D2 color=3Dnavy face=3DArial><span style=3D'font-size:10.0pt;font-fam=
ily:Arial;
color:navy'>Whether the participants in the design teams did so in any offi=
cial
capacity on behalf of other groups<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Regarding Topic 1:<o:p></o:p></span></=
font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

=
It&#8217;s
too bad that your exhibit makes my point well &#8211; that the text was NOT
liaised to the ITU for review/agreement prior to sending it for publication.
&nbsp;If you look at the liaison you provided:<o:p></o:p>

<p class=3DMsoNormal style=3D'margin-left:27.0pt;text-indent:-9.0pt'><font =
size=3D2
color=3Dnavy face=3DArial><span style=3D'font-size:10.0pt;font-family:Arial;
color:navy'>-</span></font><font size=3D1 color=3Dnavy><span style=3D'font-=
size:7.0pt;
color:navy'>&nbsp;&nbsp;&nbsp; </span></font><font size=3D2 color=3Dnavy
face=3DArial><span style=3D'font-size:10.0pt;font-family:Arial;color:navy'>=
you will
see it says &#8220;for information&#8221;, not for action meaning there is =
no
intent to find out if it is aligned, and<o:p></o:p></span></font></p>

-&nbsp;&nbsp;&nbsp; =
you will
note the email you provided states it was notifying ITU of publication. Wit=
ness
the specific text:<o:p></o:p>

<p class=3DMsoNormal style=3D'mso-margin-top-alt:0in;margin-right:461.25pt;
margin-bottom:0in;margin-left:.5in;margin-bottom:.0001pt'><font size=3D2
color=3Dnavy face=3DArial><span style=3D'font-size:10.0pt;font-family:Arial;
color:navy'>&#8220;The CCAMP working group is pleased to inform you of the =
_<i><span
style=3D'font-style:italic'>publication</span></i>_ of RFC 4258&quot;<o:p><=
/o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-right:461.25pt'><font size=3D2 color=
=3Dnavy
face=3DArial><span style=3D'font-size:10.0pt;font-family:Arial;color:navy'>=
<o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:9.0pt'><font size=3D2 color=3Dnavy
face=3DArial><span style=3D'font-size:10.0pt;font-family:Arial;color:navy'>=
Again, I
state that the final IETF requirements and IETF evaluation documents were n=
ot liaised
to the ITU for review/agreement, so it is impossible to say if they are ali=
gned
with the OIF requirements.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:9.0pt'><font size=3D2 color=3Dnavy
face=3DArial><span style=3D'font-size:10.0pt;font-family:Arial;color:navy'>=
To
remove any potential receiver confusion what this statement means, let me p=
ut
in another way:<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'mso-margin-top-alt:0in;margin-right:461.25pt;
margin-bottom:0in;margin-left:1.5in;margin-bottom:.0001pt;text-indent:-1.0i=
n'><font
size=3D2 color=3Dnavy face=3DArial><span style=3D'font-size:10.0pt;font-fam=
ily:Arial;
color:navy'>WHEREAS,&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the ITU has developed a =
set
of requirements and architecture for ASON routing commonly known as G.8080,
G=2E7715 and G.7715.1, and<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'mso-margin-top-alt:0in;margin-right:461.25pt;
margin-bottom:0in;margin-left:1.5in;margin-bottom:.0001pt;text-indent:-1.0i=
n'><font
size=3D2 color=3Dnavy face=3DArial><span style=3D'font-size:10.0pt;font-fam=
ily:Arial;
color:navy'>WHEREAS,&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the members of the OIF a=
re
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 OI=
F,
and<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'mso-margin-top-alt:0in;margin-right:461.25pt;
margin-bottom:0in;margin-left:1.5in;margin-bottom:.0001pt;text-indent:-1.0i=
n'><font
size=3D2 color=3Dnavy face=3DArial><span style=3D'font-size:10.0pt;font-fam=
ily:Arial;
color:navy'>WHEREAS,&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the IETF has been workin=
g on
documents which purport to be accurate restatements of the requirements and
architecture specified by ITU for ASON routing, and<o:p></o:p></span></font=
></p>

<p class=3DMsoNormal style=3D'mso-margin-top-alt:0in;margin-right:461.25pt;
margin-bottom:0in;margin-left:1.5in;margin-bottom:.0001pt;text-indent:-1.0i=
n'><font
size=3D2 color=3Dnavy face=3DArial><span style=3D'font-size:10.0pt;font-fam=
ily:Arial;
color:navy'>WHEREAS,&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the final documents of t=
he
IETF have not been liaised to the ITU for the purposes of review or agreeme=
nt
prior to publication, allowing determination that they are accurate
restatements, <o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'mso-margin-top-alt:0in;margin-right:461.25pt;
margin-bottom:0in;margin-left:1.5in;margin-bottom:.0001pt;text-indent:-1.0i=
n'><font
size=3D2 color=3Dnavy face=3DArial><span style=3D'font-size:10.0pt;font-fam=
ily:Arial;
color:navy'>THEREFORE,&nbsp;&nbsp; it cannot be said that the documents of =
the
IETF are aligned with the requirements or architecture specified by the ITU,
and<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'mso-margin-top-alt:0in;margin-right:461.25pt;
margin-bottom:0in;margin-left:1.5in;margin-bottom:.0001pt;text-indent:-1.0i=
n'><font
size=3D2 color=3Dnavy face=3DArial><span style=3D'font-size:10.0pt;font-fam=
ily:Arial;
color:navy'>THEREFORE,&nbsp;&nbsp; it cannot be said that the documents of =
the
IETF are aligned with the requirements or architecture of the OIF.<o:p></o:=
p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:9.0pt'><font size=3D2 color=3Dnavy

face=3DArial>=
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 th=
at
the ITU documents were the requirements and architecture documents to be
followed was to REMOVE the possibility of OIF-speak, and support convergenc=
e on
well-defined ITU-speak. This goes a long way to removing confusion.<o:p></o=
:p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Regarding Topic 2:<o:p></o:p></span></=
font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

=
The IETF
requirements and evaluation documents don&#8217;t make any specific stateme=
nts
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 &#8211; statements that are based on Section 10 of
G=2E8080. CCAMP has not finished (started?) a document that makes any speci=
fic
statements about OSPF.<o:p></o:p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:9.0pt'><font size=3D2 color=3Dnavy
face=3DArial><span style=3D'font-size:10.0pt;font-family:Arial;color:navy'>=
Again I
ask, wouldn&#8217;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?<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Regarding Topic 3:<o:p></o:p></span></=
font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

=
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. &nbsp;Our participation in the design te=
ams
were not as official representatives of the ITU or OIF.&nbsp; 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.&nbsp; Again, since this was not done, it is unclear if the docume=
nts
are in alignment.<o:p></o:p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

=
It should
also be noted that the OIF has been interested in setting up a formal OIF-I=
ETF
liaison relationship to remove this misconception, while CCAMP has prevented
it. &nbsp;It seems that the confusion in the IETF would be lower if the lia=
ison
relationship was formed.&nbsp; Certainly, this level of confusion does not
exist in the ITU where an OIF-ITU liaison relationship has existed for many
years.<o:p></o:p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>I look forward to reviewing the new
liaison text.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><st1:PersonName w:st=3D"on"><font size=3D2 color=3Dnavy
 face=3DArial><span style=3D'font-size:10.0pt;font-family:Arial;color:navy'=
>Jonathan
 Sadler</span></font></st1:PersonName><font size=3D2 color=3Dnavy face=3DAr=
ial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p></o:p></span><=
/font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font siz=
e=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabIndex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span style=3D'font-si=
ze:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'> Brungard=
, Deborah
A, ALABS [mailto:dbrungard@att.com] <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Tuesday, July 25, 2006=
 9:58
AM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Sadler, Jonathan B.; Ong,
Lyndon; ccamp@ops.ietf.org<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> Adrian Farrel<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: Proposed respon=
se to
OIF on OSPF ENNI</span></font><o:p></o:p></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Hi Jonathan,</span></font><o:p></o:p><=
/p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

I think you meant OIF below, as ITU and
IETF work on ASON has been tightly coordinated e.g. a quick back search:</s=
pan><o:p></o:p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'><a
href=3D"https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=3D=
150">https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=3D150=
</a></span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 color=3Dnavy face=3D"Times New Roman"><=
span
style=3D'font-size:12.0pt;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>This mis-match is always the concern w=
hen
work is duplicated&nbsp;in other groups.For OIF to&nbsp;be progressing&nbsp=
;a
document identifying issues with GMPLS for supporting ASON when already CCA=
MP
has finished their document is not only a misuse of people's time (both in =
OIF
and IETF),</span></font><font size=3D2 color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy'> </span></font><font
size=3D2 color=3Dblue face=3DArial><span style=3D'font-size:10.0pt;font-fam=
ily:Arial;
color:blue'>it also causes confusion in the industry (we now have ITU-speak,
CCAMP-speak, and OIF-speak).</span></font><font size=3D2 color=3Dnavy face=
=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p></o:p></span><=
/font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

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 documen=
t)
and you as chair),&nbsp;if both of you have difficulty judging the alignmen=
t of
this document vs. ASON requirements and CCAMP's work, then the document is =
not
helping either OIF's intention to&nbsp;develop standards in&nbsp;alignment =
with
ITU and IETF&nbsp;or CCAMP's ability to develop an ASON solution.</f=
ont><o=
:p></o:p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

We should re-spin the Liaison&nbsp;to
inform OIF that this work has been completed in CCAMP&nbsp;and to&nbsp;requ=
est
that&nbsp;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 agree=
d is
very useful). I'll work on it today, and send later.<o:p></o:p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>&quot;Significant&quot; Thanks on the
confusion;-)</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Deborah</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font siz=
e=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabIndex=3D-1>

</span></font></div>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><b><font size=3D2 face=
=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma;font-weight:bold'>From:</span>=
</font></b><font
size=3D2 face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'>=
 Sadler, Jonathan
B=2E [mailto:Jonathan.Sadler@tellabs.com] <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Monday, July 24, 2006 =
5:38
PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Brungard, Deborah A, ALA=
BS;
Ong, Lyndon; ccamp@ops.ietf.org<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> Adrian Farrel<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: Proposed respon=
se to
OIF on OSPF ENNI</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Hi Deborah,<o:p></o:p></span></font></=
p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

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.
&nbsp;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.<o:p></o:p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Regards,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><st1:PersonName w:st=3D"on"><font size=3D2 color=3Dnavy
 face=3DArial><span style=3D'font-size:10.0pt;font-family:Arial;color:navy'=
>Jonathan
 Sadler</span></font></st1:PersonName><font size=3D2 color=3Dnavy face=3DAr=
ial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p></o:p></span><=
/font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font siz=
e=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabIndex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span style=3D'font-si=
ze:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'> Brungard,
Deborah A, ALABS [mailto:dbrungard@att.com] <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Monday, July 24, 2006 =
4:31
PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Sadler, Jonathan B.; Ong,
Lyndon; ccamp@ops.ietf.org<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> Adrian Farrel<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: Proposed respon=
se to
OIF on OSPF ENNI</span></font><o:p></o:p></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Hi Jonathan,</span></font><o:p></o:p><=
/p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

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&nbsp;want to
ensure that the work is aligned.<o:p></o:p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Thanks,</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Deborah</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font siz=
e=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabIndex=3D-1>

</span></font></div>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><b><font size=3D2 face=
=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma;font-weight:bold'>From:</span>=
</font></b><font
size=3D2 face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'>=
 Sadler, Jonathan
B=2E [mailto:Jonathan.Sadler@tellabs.com] <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Monday, July 24, 2006 =
4:32
PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Brungard, Deborah A, ALA=
BS;
Ong, Lyndon; ccamp@ops.ietf.org<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> Adrian Farrel<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: Proposed respon=
se to
OIF on OSPF ENNI</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Hi Deborah, Lyndon, et al,<o:p></o:p><=
/span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Some additional comments:<o:p></o:p></=
span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;- The hierarchical model discuss=
ed
in the draft IA liaised may be supported without any modifications to
OSPF.&nbsp; As discussed in earlier emails, it can be implemented solely
through the import/export of information described in Appendix I of G.7715.=
<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;- The draft IA also recognizes
namespace issues exist between Router ID and the IP Address that messages a=
re
sent to (ITU calls this the RC PC SCN address).&nbsp; This issue is also
discussed in draft-ietf-ccamp-gmpls-addressing.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Given that:<o:p></o:p></span></font></=
p>

<p class=3DMsoNormal style=3D'margin-left:21.0pt;text-indent:-.25in'><font =
size=3D2
color=3Dnavy face=3DArial><span style=3D'font-size:10.0pt;font-family:Arial;
color:navy'>-</span></font><font size=3D1 color=3Dnavy><span style=3D'font-=
size:7.0pt;
color:navy'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span><=
/font><font
size=3D2 color=3Dnavy face=3DArial><span style=3D'font-size:10.0pt;font-fam=
ily:Arial;
color:navy'>CCAMP has a milestone to publish an ASON routing solution by Nov
2006, <o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:21.0pt;text-indent:-.25in'><font =
size=3D2
color=3Dnavy face=3DArial><span style=3D'font-size:10.0pt;font-family:Arial;
color:navy'>-</span></font><font size=3D1 color=3Dnavy><span style=3D'font-=
size:7.0pt;
color:navy'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span><=
/font><font
size=3D2 color=3Dnavy face=3DArial><span style=3D'font-size:10.0pt;font-fam=
ily:Arial;
color:navy'>CCAMP didn&#8217;t have at the time this was liaised (doesn&#82=
17;t
have today?) a working group document, and<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:21.0pt;text-indent:-.25in'><font =
size=3D2
color=3Dnavy face=3DArial><span style=3D'font-size:10.0pt;font-family:Arial;
color:navy'>-</span></font><font size=3D1 color=3Dnavy><span style=3D'font-=
size:7.0pt;
color:navy'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span><=
/font><font
size=3D2 color=3Dnavy face=3DArial><span style=3D'font-size:10.0pt;font-fam=
ily:Arial;
color:navy'>the draft IA has been successfully implemented by more than a d=
ozen
vendors and interop-tested many times,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>I would expect that we should be looki=
ng
at this as experience/text that could be leveraged...&nbsp; &#8220;Running
code&#8230;&#8221; and all that&#8230;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Regards,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><st1:PersonName w:st=3D"on"><font size=3D2 color=3Dnavy
 face=3DArial><span style=3D'font-size:10.0pt;font-family:Arial;color:navy'=
>Jonathan
 Sadler</span></font></st1:PersonName><font size=3D2 color=3Dnavy face=3DAr=
ial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p></o:p></span><=
/font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font siz=
e=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabIndex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span style=3D'font-si=
ze:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'> Ong, Lyn=
don
[mailto:Lyong@Ciena.com] <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Monday, July 24, 2006 =
2:33
PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Brungard, Deborah A, ALA=
BS;
Sadler, Jonathan B.; ccamp@ops.ietf.org<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> Adrian Farrel<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: Proposed respon=
se to
OIF on OSPF ENNI</span></font><o:p></o:p></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Hi Deborah,</span></font><o:p></o:p></=
p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Here's what I would say&nbsp;is in and=
 not
in the OIF document:</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>-- G.7715, G.7715.1 and the IETF eval =
and
solutions draft all identify a need to support hierarchical</span></font><o=
:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>routing areas for ASON, I am perplexed=
 as
to why this seems to be viewed as a new feature.</span></font><o:p></o:p></=
p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>-- the document does not specify the
domain of usage and leaves this to the carrier.&nbsp; This is no different<=
/span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>from G.7715.1 and IETF drafts that do =
not
explicitly state whether they are used for intra- or inter-domain</span></f=
ont><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>interfaces.</span></font><o:p></o:p></=
p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>-- GMPLS OSPF does not support a 1:N or
N:1 relationship between routing controller and transport</span></font><o:p=
></o:p></p>

node, hence extensions are felt to be
required - and are proposed in the eval solutions draft. The =
<o:p></o:p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>conclusions are no different.</span></=
font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>-- the document does not in fact define
any standard extensions to the protocols, and points to future work</span><=
/font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>in IETF and ITU to provide these.&nbsp;
Therefore I cannot understand where you say &quot;new extensions to</span><=
/font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>OSPF are specified&quot; and
&quot;none...align with the CCAMP's GMPLS-ASON work&quot;.&nbsp; </span></f=
ont><o:p></o:p></p>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>I think we're experiencing a significa=
nt
miscommunication...</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Cheers,</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Lyndon</span></font><o:p></o:p></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font siz=
e=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabIndex=3D-1>

</span></font></div>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><b><font size=3D2 face=
=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma;font-weight:bold'>From:</span>=
</font></b><font
size=3D2 face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'>=
 owner-ccamp@ops.ietf.org
[mailto:owner-ccamp@ops.ietf.org] <b><span style=3D'font-weight:bold'>On Be=
half
Of </span></b>Brungard, Deborah A, ALABS<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Monday, July 24, 2006 =
12:15
PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Sadler, Jonathan B.;
ccamp@ops.ietf.org<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> Adrian Farrel<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: Proposed respon=
se to
OIF on OSPF ENNI</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Hi Jonathan, (and Lyndon),</span></fon=
t><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Thanks to both of you for responding.<=
/span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>&quot;Significant&quot; was referencin=
g:</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>- supports&nbsp;a&nbsp;(new) hierarchi=
cal
OSPF model</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>-&nbsp;supports&nbsp;inter-domain
(inter-carrier) OSPF (not supported by today's OSPF)</span></font><o:p></o:=
p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>- identifies namespace issues with GMP=
LS
OSPF which do not exist, and proposes extensions to &quot;fix&quot;</span><=
/font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>- new extensions to OSPF are specified=
</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>- none of the proposed extensions align
with CCAMP's GMPLS-ASON work</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

Did you have another adjective to sugg=
est?
We&nbsp;were thinking&nbsp;&quot;significant&quot; 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.&nbsp;The divergence is&nbsp;baffling to us.<o:p></o:=
p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Deborah</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font siz=
e=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabIndex=3D-1>

</span></font></div>

From:=
=
 Sadler,
Jonathan B. [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<o:p></o:p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Hi Deborah and Adrian,<o:p></o:p></spa=
n></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

I haven&#8217;t seen much discussion of
the OIF E-NNI Routing document on the CCAMP list. &nbsp;Can you tell me what
parts of the document are &#8220;significant modifications to the operation=
 of
OSPF&#8221;?<o:p></o:p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Thanks,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><st1:PersonName w:st=3D"on"><font size=3D2 color=3Dnavy
 face=3DArial><span style=3D'font-size:10.0pt;font-family:Arial;color:navy'=
>Jonathan
 Sadler</span></font></st1:PersonName><font size=3D2 color=3Dnavy face=3DAr=
ial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p></o:p></span><=
/font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font siz=
e=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabIndex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span style=3D'font-si=
ze:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'>
owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] <b><span
style=3D'font-weight:bold'>On Behalf Of </span></b>Brungard, Deborah A, ALA=
BS<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Friday, July 21, 2006 =
9:38
AM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> ccamp@ops.ietf.org<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> Adrian Farrel<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> Proposed response t=
o OIF
on OSPF ENNI</span></font><o:p></o:p></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Hi,</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

We had a communication from OIF on the=
ir
OSPF ENNI specification. You can see the original files on <a
href=3D"http://www.olddog.co.uk/ccamp.htm">http://www.olddog.co.uk/ccamp.=
htm</a>. Having assembled comments from several people and our discuss=
ions
in <st1:place w:st=3D"on"><st1:City w:st=3D"on">Montreal</st1:City></st1:pl=
ace>, we
have put together the following response.<o:p></o:p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Please comment on the list in the next
week.</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Thanks,</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Adrian and Deborah</span></font><o:p><=
/o:p></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>=3D =3D =3D =3D =3D =3D =3D =3D =3D =3D<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>Dear Jim,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

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.<o:p></o:p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

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: <a
href=3D"ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpls-ason-routi=
ng-eval-03.txt">ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpls-as=
on-routing-eval-03.txt</a>.
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&#8217;s work, we recommend that you either utilize the CCAMP mail expl=
oder
or send a communication.<o:p></o:p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>Specific comments include:<o:p></o:p></span></font></p>

1.<=
font
size=3D1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </s=
pan>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></o:p>

<p class=3DMsoNormal style=3D'margin-left:.25in;text-indent:-.25in'><i><font
size=3D3 face=3D"Times New Roman"><span style=3D'font-size:12.0pt;font-styl=
e:italic'>2.</span></font></i><i><font
size=3D1><span style=3D'font-size:7.0pt;font-style:italic'>&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;
</span></font></i>The list of changes from the previous version (listed und=
er
the Table of Contents) includes &#8220;<i><span style=3D'font-style:italic'=
>removed
&#8220;intra-carrier&#8221; limitation</span></i>&#8221; 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. <b=
r>
The IETF&#8217;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&#8217;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.<i><span style=3D'font-style:i=
talic'><o:p></o:p></span></i></p>

3.<=
font
size=3D1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </s=
pan>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.<o:p></o:p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>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.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>Best regards,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><st1:PersonName w:st=3D"on"><font size=3D3 face=3D"Tim=
es New Roman"><span
 style=3D'font-size:12.0pt'>Adrian Farrel</span></font></st1:PersonName> and
Deborah Brungard,<o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>CCAMP co-chairs<o:p></o:p></span></font></p>

</div>

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

<pre>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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
</pre></body>

</html>

------_=_NextPart_001_01C6B029.5FB98297--

Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 25 Jul 2006 19:59:56 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Proposed response to OIF on OSPF ENNI
Date: Tue, 25 Jul 2006 14:58:34 -0500
Message-ID: <449B2580D802A443A923DABF3EAB82AF0C7756E4@OCCLUST04EVS1.ugd.att.com>
Thread-Topic: Proposed response to OIF on OSPF ENNI
Thread-Index: AcavdNm23DacerUoR2eeOhvtB9cVwQAqe5Vw
From: "Brungard, Deborah A, ALABS" <dbrungard@att.com>
To: "Tomohiro Otani" <otani@kddilabs.jp>
Cc: <ccamp@ops.ietf.org>, "Adrian Farrel" <adrian@olddog.co.uk>

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

Regards,
Deborah
=20

-----Original Message-----
From: Tomohiro Otani [mailto:otani@kddilabs.jp]=20
Sent: Monday, July 24, 2006 7:00 PM
To: Brungard, Deborah A, ALABS
Cc: ccamp@ops.ietf.org; Adrian Farrel
Subject: Re: Proposed response to OIF on OSPF ENNI

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:
> Hi,
> =20
> We had a communication from OIF on their OSPF ENNI specification. You=20
> can see the original files on _http://www.olddog.co.uk/ccamp.htm_.=20
> Having assembled comments from several people and our discussions in=20
> Montreal, we have put together the following response.
> =20
> Please comment on the list in the next week.
> =20
> Thanks,
> Adrian and Deborah
> =20
>=20
> =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D
>=20
> Dear Jim,
>=20
> =20
>=20
> We thank you for sending us the OIF ENNI document in response to our=20
> request. While we appreciate the document being provided for=20
> information, it is concerning that this document has not been
previously=20
> shared with CCAMP or the OSPF WG considering the document contains=20
> significant modifications to the operation of OSPF and reflects OIF
work=20
> over the last several years. CCAMP has been working on GMPLS ASON for=20
> several years and our Design Teams include OIF participants. Even
though=20
> a reply was not requested, we are replying, as we strongly recommend=20
> that the document not be published for public information in its
current=20
> form.
>=20
> =20
>=20
> Of most concern to CCAMP is that it is not aligned with RFC 4258=20
> (Requirements for Generalized Multi-Protocol Label Switching (GMPLS)=20
> Routing for the Automatically Switched Optical Network (ASON)) or the=20
> to-be-published:=20
>
ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-ev
al-03.txt.=20
> Considering notable OIF participants are authors of both these IETF=20
> documents (and the same participants are contributors and the Editor
for=20
> the OIF document), the non-alignment is perplexing. Considering the
IETF=20
> document is ready for publication, we suggest in the interests of
time,=20
> that you align your document with the IETF document. If any questions
on=20
> the interpretation of the IETF's work, we recommend that you either=20
> utilize the CCAMP mail exploder or send a communication.
>=20
> =20
>=20
> Specific comments include:
>=20
> 1.      What is the intent of this document? Will it be published as
an=20
> Implementation Agreement (IA)?
> The title indicates it will be an Implementation Agreement on GMPLS
OSPF=20
> 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=20
> requirements on and use of OSPF-TE at the ENNI. These three views seem

> to be inconsistent.
>=20
> /2.      /The list of changes from the previous version (listed under=20
> the Table of Contents) includes "/removed "intra-carrier" limitation/"

> and the inclusion of Figure 1 showing the OSPF ENNI for use between=20
> vendor domains and between carrier domains. GMPLS OSPF-TE already=20
> supports inter-vendor operations.
> The IETF's GMPLS ASON routing focus has been on the use of a
link-state=20
> based protocol to support a hierarchical routing architecture
(G.7715.1)=20
> within a carrier's domain. Requirements for using a link state
protocol=20
> as an inter-domain protocol between carriers are significantly=20
> different. We strongly disagree if you intend to publish this document

> as an inter-carrier OSPF ENNI Implementation Agreement claiming=20
> alignment with IETF RFCs without review (or agreement) by any of the=20
> IETF Working Groups.//
>=20
> 3.      Section 4.1/Table 1 and the statement under the table=20
> identifying issues with GMPLS identifier namespaces are not correct.=20
> GMPLS identifier namespaces do meet ASON requirements for namespace=20
> separation of the transport plane and control plane (Section 5.2 and=20
> 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=20
> support of independence of functional component to physical location,=20
> this appears to be a key area of misunderstanding on GMPLS. We
recommend=20
> reviewing RFC3945 (GMPLS Architecture) to understand that the key=20
> architecture difference between GMPLS and MPLS is the decoupling of
the=20
> transport plane and control plane. Additionally, RFC4394, RFC4397, and

> RFC4258, provide a mapping to ITU terminology which may be helpful
reading.
>=20
> =20
>=20
> We request an additional round of communication of this document to
the=20
> IETF before approval to allow us to work with you to produce
convergence=20
> between OIF and IETF work which, we believe, will be in the best=20
> interests of the industry.
>=20
> =20
>=20
> Best regards,
>=20
> Adrian Farrel and Deborah Brungard,
>=20
> CCAMP co-chairs
>=20

Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 25 Jul 2006 19:05:03 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6B01D.11BB6ACE"
Subject: RE: Proposed response to OIF on OSPF ENNI
Date: Tue, 25 Jul 2006 14:03:51 -0500
Message-ID: <449B2580D802A443A923DABF3EAB82AF0C77563B@OCCLUST04EVS1.ugd.att.com>
Thread-Topic: Proposed response to OIF on OSPF ENNI
Thread-Index: Acas0Ha/aYxFikOBS5m873SVRoVJxgAACLxQAAHPZJAAnZ89IAACGznwAAEH8mAAAxLNQAAAS4QQACJG/RAAAkvKMAAGeikg
From: "Brungard, Deborah A, ALABS" <dbrungard@att.com>
To: "Sadler, Jonathan B." <Jonathan.Sadler@tellabs.com>, "Ong, Lyndon" <Lyong@Ciena.com>, <ccamp@ops.ietf.org>
Cc: "Adrian Farrel" <adrian@olddog.co.uk>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6B01D.11BB6ACE
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Jonathan,
=20
These statements are not only not correct, they don't make sense
considering you were involved in the work, do a refresh and go back in
the years, and you will see ITU-IETF liaisons (prior to publication):
https://datatracker.ietf.org/documents/LIAISON/file151.doc
=20
and:
https://datatracker.ietf.org/documents/LIAISON/file132.txt
=20
and there are many more. My co-chair, our previous ccamp co-chair, and
Kam (ITU's Q14 Rap) have worked together over these past couple of years
to ensure the ASON work progressed - jointly. Considering the number of
cross-participants, a lack of IETF-OIF liaison can not be used as the
basis of the current confusion and duplication in work. And anyone can
participate and access IETF documents - it's an open process.
=20
If this OIF document is on an OSPF implementation "has been implemented
by many vendors" and the vendors intend it to be production use (vs.
experimental), then the OIF (or a vendor) needs to follow the IETF
process. That's a different subject.
=20
The current liaison was scoped as requirements which is why we are
trying to understand it.
=20
Lyndon has already responded saying he believes there is no
mis-alignment. Thanks Lyndon. We will go with that.
=20
Thanks,
Deborah

________________________________

From: Sadler, Jonathan B. [mailto:Jonathan.Sadler@tellabs.com]=20
Sent: Tuesday, July 25, 2006 12:29 PM
To: Brungard, Deborah A, ALABS; Ong, Lyndon; ccamp@ops.ietf.org
Cc: Adrian Farrel
Subject: RE: Proposed response to OIF on OSPF ENNI

Hi Deborah,

=20

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

=20

Regarding Topic 1:

=20

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"

=20

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.

=20

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

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.

=20

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.

=20

Regarding Topic 2:

=20

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.

=20

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?

=20

Regarding Topic 3:

=20

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.

=20

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.

=20

I look forward to reviewing the new liaison text.

=20

Jonathan Sadler

=20

________________________________

From: Brungard, Deborah A, ALABS [mailto:dbrungard@att.com]=20
Sent: Tuesday, July 25, 2006 9:58 AM
To: Sadler, Jonathan B.; Ong, Lyndon; ccamp@ops.ietf.org
Cc: Adrian Farrel
Subject: RE: Proposed response to OIF on OSPF ENNI

=20

Hi Jonathan,

=20

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

=20

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

=20

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.

=20

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.

=20

"Significant" Thanks on the confusion;-)

Deborah

=20

________________________________

From: Sadler, Jonathan B. [mailto:Jonathan.Sadler@tellabs.com]=20
Sent: Monday, July 24, 2006 5:38 PM
To: Brungard, Deborah A, ALABS; Ong, Lyndon; ccamp@ops.ietf.org
Cc: Adrian Farrel
Subject: RE: Proposed response to OIF on OSPF ENNI

Hi Deborah,

=20

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.

=20

Regards,

=20

Jonathan Sadler

=20

________________________________

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

=20

Hi Jonathan,

=20

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.

=20

Thanks,

Deborah

=20

________________________________

From: Sadler, Jonathan B. [mailto:Jonathan.Sadler@tellabs.com]=20
Sent: Monday, July 24, 2006 4:32 PM
To: Brungard, Deborah A, ALABS; Ong, Lyndon; ccamp@ops.ietf.org
Cc: Adrian Farrel
Subject: RE: Proposed response to OIF on OSPF ENNI

Hi Deborah, Lyndon, et al,

=20

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.

=20

Given that:

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

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

=20

Regards,

=20

Jonathan Sadler

=20

________________________________

From: Ong, Lyndon [mailto:Lyong@Ciena.com]=20
Sent: Monday, July 24, 2006 2: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

=20

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

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

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

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

=20

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

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

=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
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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_01C6B01D.11BB6ACE
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:v =3D=20
"urn:schemas-microsoft-com:vml" xmlns:o =3D=20
"urn:schemas-microsoft-com:office:office" xmlns:w =3D=20
"urn:schemas-microsoft-com:office:word" xmlns:p =3D=20
"urn:schemas-microsoft-com:office:powerpoint" xmlns:oa =3D=20
"urn:schemas-microsoft-com:office:activation" xmlns:st1 =3D=20
"urn:schemas-microsoft-com:office:smarttags"><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.2914" name=3DGENERATOR><!--[if !mso]>
<STYLE>v\:* {
	BEHAVIOR: url(#default#VML)
}
o\:* {
	BEHAVIOR: url(#default#VML)
}
w\:* {
	BEHAVIOR: url(#default#VML)
}
.shape {
	BEHAVIOR: url(#default#VML)
}
</STYLE>
<![endif]--><o:SmartTagType=20
downloadurl=3D"http://www.5iamas-microsoft-com:office:smarttags" =
name=3D"State"=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTagT=
ype><o:SmartTagType=20
downloadurl=3D"http://www.5iamas-microsoft-com:office:smarttags" =
name=3D"City"=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTagT=
ype><o:SmartTagType=20
downloadurl=3D"http://www.5iantlavalamp.com/" name=3D"place"=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTagT=
ype><o:SmartTagType=20
downloadurl=3D"http://www.microsoft.com" name=3D"PersonName"=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTagT=
ype><!--[if !mso]>
<STYLE>st1\:* {
	BEHAVIOR: url(#default#ieooui)
}
</STYLE>
<![endif]-->
<STYLE>@font-face {
	font-family: Wingdings;
}
@font-face {
	font-family: MS Mincho;
}
@font-face {
	font-family: Tahoma;
}
@font-face {
	font-family: @MS Mincho;
}
@page Section1 {size: 8.5in 11.0in; margin: 1.0in 1.25in 1.0in 1.25in; }
P.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
LI.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
DIV.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline
}
A:visited {
	COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlinkFollowed {
	COLOR: blue; TEXT-DECORATION: underline
}
PRE {
	FONT-SIZE: 10pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Courier New"
}
SPAN.EmailStyle18 {
	COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal
}
SPAN.EmailStyle19 {
	COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal
}
SPAN.EmailStyle20 {
	COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal
}
SPAN.EmailStyle21 {
	COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal-reply
}
DIV.Section1 {
	page: Section1
}
OL {
	MARGIN-BOTTOM: 0in
}
UL {
	MARGIN-BOTTOM: 0in
}
</STYLE>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]--></HEAD>
<BODY lang=3DEN-US vLink=3Dblue link=3Dblue>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D327550218-25072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Jonathan,</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D327550218-25072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D327550218-25072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>These statements are not only not correct, they =
don't make=20
sense considering you were involved in the work, do a refresh and go =
back in the=20
years, and you will see ITU-IETF liaisons&nbsp;(prior to=20
publication):</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D327550218-25072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2><A=20
href=3D"https://datatracker.ietf.org/documents/LIAISON/file151.doc">https=
://datatracker.ietf.org/documents/LIAISON/file151.doc</A></FONT></SPAN></=
DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D327550218-25072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D327550218-25072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>and:</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D327550218-25072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2><A=20
href=3D"https://datatracker.ietf.org/documents/LIAISON/file132.txt">https=
://datatracker.ietf.org/documents/LIAISON/file132.txt</A></FONT></SPAN></=
DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D327550218-25072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D327550218-25072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>and there are many more. My co-chair, our =
previous ccamp=20
co-chair, and Kam (ITU's Q14 Rap) have&nbsp;worked&nbsp;together over =
these past=20
couple of years to ensure the ASON work progressed - jointly. =
Considering the=20
number of cross-participants, a lack of IETF-OIF liaison can not =
be&nbsp;used=20
as&nbsp;the basis of the current confusion and duplication in work. And=20
anyone&nbsp;can participate and access IETF documents - it's an open=20
process.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D327550218-25072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D327550218-25072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>If this OIF document is on an OSPF =
implementation "has been=20
implemented by many vendors"&nbsp;and the vendors intend it&nbsp;to be=20
production use (vs. experimental), then the OIF (or a vendor)&nbsp;needs =

to&nbsp;follow the IETF process. That's a different =
subject.</DIV>
<DIV dir=3Dltr align=3Dleft>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft>The current liaison was scoped as requirements =
which is why=20
we are trying to understand it.</DIV>
<DIV dir=3Dltr align=3Dleft>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft>Lyndon has already responded saying he believes =
there is no=20
mis-alignment. Thanks Lyndon. We will go with that.</DIV>
<DIV dir=3Dltr align=3Dleft>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft>Thanks,</DIV>
<DIV dir=3Dltr align=3Dleft>Deborah</DIV> 
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
<HR tabIndex=3D-1>
From: Sadler, Jonathan B.=20
[mailto:Jonathan.Sadler@tellabs.com] Sent: Tuesday, July 25, =
2006=20
12:29 PM To: Brungard, Deborah A, ALABS; Ong, Lyndon;=20
ccamp@ops.ietf.org Cc: Adrian Farrel Subject: RE: =
Proposed=20
response to OIF on OSPF ENNI </DIV>
<DIV></DIV>
<DIV class=3DSection1>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Hi=20
Deborah,<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">It seems that =
your=20
response centers on three topics:<o:p></o:p>
<![if !supportLists]><FONT=20
face=3DArial color=3Dnavy size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><SPAN=20
style=3D"mso-list: Ignore">1.<SPAN=20
style=3D"FONT: 7pt 'Times New =
Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
<![endif]>The=20
alignment of the IETF architecture/eval documents with the=20
requirements/architecture of other groups,<o:p></o:p>
<![if !supportLists]><FONT=20
face=3DArial color=3Dnavy size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><SPAN=20
style=3D"mso-list: Ignore">2.<SPAN=20
style=3D"FONT: 7pt 'Times New =
Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
<![endif]>The OIF=20
<st1:place w:st=3D"on"><st1:City w:st=3D"on">Draft</st1:City> <st1:State =

w:st=3D"on">IA</st1:State></st1:place> making statements regarding the =
identifiers=20
used by GMPLS routing when carried by OSPF, =
and<o:p></o:p>
<![if !supportLists]><FONT=20
face=3DArial color=3Dnavy size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><SPAN=20
style=3D"mso-list: Ignore">3.<SPAN=20
style=3D"FONT: 7pt 'Times New =
Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
<![endif]>Whether=20
the participants in the design teams did so in any official capacity on =
behalf=20
of other groups<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Regarding =
Topic=20
1:<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p>
It&#8217;s too=20
bad that your exhibit makes my point well &#8211; that the text was NOT =
liaised to the=20
ITU for review/agreement prior to sending it for publication. &nbsp;If =
you look=20
at the liaison you provided:<o:p></o:p>
<![if !supportLists]><FONT=20
face=3DArial color=3Dnavy size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><SPAN=20
style=3D"mso-list: Ignore">-<SPAN=20
style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;=20
<![endif]>you will=20
see it says &#8220;for information&#8221;, not for action meaning there =
is no intent to find=20
out if it is aligned, and<o:p></o:p>
<![if !supportLists]><FONT=20
face=3DArial color=3Dnavy size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><SPAN=20
style=3D"mso-list: Ignore">-<SPAN=20
style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;=20
<![endif]>you will=20
note the email you provided states it was notifying ITU of publication. =
Witness=20
the specific text:<o:p></o:p>
<FONT=20
face=3DArial color=3Dnavy size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">&#8220;The =
CCAMP working=20
group is pleased to inform you of the _<SPAN=20
style=3D"FONT-STYLE: italic">publication_ of RFC=20
4258"<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p>
Again, I=20
state that the final IETF requirements and IETF evaluation documents =
were not=20
liaised to the ITU for review/agreement, so it is impossible to say if =
they are=20
aligned with the OIF requirements.<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p>
To remove=20
any potential receiver confusion what this statement means, let me put =
in=20
another way:<o:p></o:p>
<FONT=20
face=3DArial color=3Dnavy size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">WHEREAS,&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
the ITU has developed a set of requirements and architecture for ASON =
routing=20
commonly known as G.8080, G.7715 and G.7715.1, =
and<o:p></o:p>
<FONT=20
face=3DArial color=3Dnavy size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">WHEREAS,&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
the members of the OIF are on record that the requirements and =
architecture=20
specified in G.8080, G.7715 and G.7715.1 are the requirements and =
architecture=20
to be followed by the OIF, and<o:p></o:p>
<FONT=20
face=3DArial color=3Dnavy size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">WHEREAS,&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
the IETF has been working on documents which purport to be accurate =
restatements=20
of the requirements and architecture specified by ITU for ASON routing,=20
and<o:p></o:p>
<FONT=20
face=3DArial color=3Dnavy size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">WHEREAS,&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
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=20
that they are accurate restatements, <o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal=20
style=3D"MARGIN-BOTTOM: 0pt; MARGIN-LEFT: 1.5in; TEXT-INDENT: -1in; =
MARGIN-RIGHT: 461.25pt; mso-margin-top-alt: 0in"><FONT=20
face=3DArial color=3Dnavy size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">THEREFORE,&nbsp;&nbsp;=20
it cannot be said that the documents of the IETF are aligned with the=20
requirements or architecture specified by the ITU,=20
and<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal=20
style=3D"MARGIN-BOTTOM: 0pt; MARGIN-LEFT: 1.5in; TEXT-INDENT: -1in; =
MARGIN-RIGHT: 461.25pt; mso-margin-top-alt: 0in"><FONT=20
face=3DArial color=3Dnavy size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">THEREFORE,&nbsp;&nbsp;=20
it cannot be said that the documents of the IETF are aligned with the=20
requirements or architecture of the OIF.<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=3DMsoNormal style=3D"MARGIN-LEFT: 9pt"><FONT face=3DArial =
color=3Dnavy=20
size=3D2><SPAN style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">Please be=20
aware the reason that the OIF did NOT restate the ITU Requirements and=20
Architecture documents (unlike CCAMP), and instead went on record saying =
that=20
the ITU documents were the requirements and architecture documents to be =

followed was to REMOVE the possibility of OIF-speak, and support =
convergence on=20
well-defined ITU-speak. This goes a long way to removing=20
confusion.<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Regarding =
Topic=20
2:<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p>
The IETF=20
requirements and evaluation documents don&#8217;t make any specific =
statements about=20
the fitness of IETF protocols for ASON routing. The OIF document text =
(which=20
predates even the IETF requirements document) is making specific =
statements=20
about OSPF &#8211; statements that are based on Section 10 of G.8080. =
CCAMP has not=20
finished (started?) a document that makes any specific statements about=20
OSPF.<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p>
Again I=20
ask, wouldn&#8217;t it be better to look at this document which has been =
implemented=20
by many vendors, and successfully interoperability tested many times =
over many=20
years to see what can be leveraged instead of starting from=20
scratch?<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Regarding =
Topic=20
3:<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p>
While=20
Lyndon and I are participants in the ITU and OIF, we are not authorized =
to make=20
statements on behalf of either organization other than the statements =
authorized=20
by those organizations. &nbsp;Our participation in the design teams were =
not as=20
official representatives of the ITU or OIF.&nbsp; The only way for the =
documents=20
to be considered aligned would be to liaise them prior to publication to =
the ITU=20
or OIF for review/agreement and wait for the response.&nbsp; Again, =
since this=20
was not done, it is unclear if the documents are in=20
alignment.<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p>
It should=20
also be noted that the OIF has been interested in setting up a formal =
OIF-IETF=20
liaison relationship to remove this misconception, while CCAMP has =
prevented it.=20
&nbsp;It seems that the confusion in the IETF would be lower if the =
liaison=20
relationship was formed.&nbsp; Certainly, this level of confusion does =
not exist=20
in the ITU where an OIF-ITU liaison relationship has existed for many=20
years.<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">I look =
forward to=20
reviewing the new liaison text.<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p>
<st1:PersonName w:st=3D"on">Jonathan=20
Sadler</st1:PersonName><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p>
<DIV>
<DIV class=3DMsoNormal style=3D"TEXT-ALIGN: center" align=3Dcenter><FONT =

face=3D"Times New Roman" size=3D3><SPAN style=3D"FONT-SIZE: 12pt">
<HR tabIndex=3D-1 align=3Dcenter width=3D"100%" SIZE=3D2>
</SPAN></FONT></DIV>
<P class=3DMsoNormal><B><FONT face=3DTahoma size=3D2><SPAN=20
style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma">From:</SPAN></FONT></B><FONT=20
face=3DTahoma size=3D2><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma"> Brungard,=20
Deborah A, ALABS [mailto:dbrungard@att.com] <BR><B><SPAN=20
style=3D"FONT-WEIGHT: bold">Sent:</SPAN></B> Tuesday, July 25, 2006 9:58 =

AM To: Sadler, =
Jonathan B.;=20
Ong, Lyndon; ccamp@ops.ietf.org <SPAN=20
style=3D"FONT-WEIGHT: bold">Cc: Adrian Farrel <SPAN=20
style=3D"FONT-WEIGHT: bold">Subject: RE: Proposed response to =
OIF on=20
OSPF ENNI<o:p></o:p></DIV>
<SPAN=20
style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Hi=20
Jonathan,<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">I think you =
meant OIF=20
below, as ITU and IETF work on ASON has been tightly coordinated e.g. a =
quick=20
back search:<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial"><A=20
href=3D"https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=3D=
150">https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=3D1=
50</A><o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 12pt; COLOR: =
navy"><o:p>&nbsp;</o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">This =
mis-match is=20
always the concern when work is duplicated&nbsp;in other groups.For OIF=20
to&nbsp;be progressing&nbsp;a document identifying issues with GMPLS for =

supporting ASON when already CCAMP has finished their document is not =
only a=20
misuse of people's time (both in OIF and IETF),<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"> =
<FONT=20
face=3DArial color=3Dblue size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">it also =
causes=20
confusion in the industry (we now have ITU-speak, CCAMP-speak, and=20
OIF-speak).<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">As the hope =
of the=20
CCAMP's ASON Design Teams was to have a representation of ITU, OIF, and =
CCAMP=20
(especially considering Lyndon is OIF's Liaison to CCAMP (and editor of =
the OIF=20
document) and you as chair),&nbsp;if both of you have difficulty judging =
the=20
alignment of this document vs. ASON requirements and CCAMP's work, then =
the=20
document is not helping either OIF's intention to&nbsp;develop standards =

in&nbsp;alignment with ITU and IETF&nbsp;or CCAMP's ability to develop =
an ASON=20
solution.<SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">We should =
re-spin the=20
Liaison&nbsp;to inform OIF that this work has been completed in =
CCAMP&nbsp;and=20
to&nbsp;request that&nbsp;OIF's evaluation sections be removed and =
replaced with=20
references to the Evaluation document (vs. trying to do multiple-speak =
which has=20
us all confused) and expand on the comments (Dimitri's mail which Lyndon =
has=20
agreed is very useful). I'll work on it today, and send=20
later.<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">"Significant" =
Thanks on=20
the confusion;-)<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
Arial">Deborah<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p>
<DIV class=3DMsoNormal style=3D"TEXT-ALIGN: center" align=3Dcenter><FONT =

face=3D"Times New Roman" size=3D3>
<HR tabIndex=3D-1 align=3Dcenter width=3D"100%" SIZE=3D2>
</DIV>
<SPAN=20
style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma">From:<FONT=20
face=3DTahoma size=3D2> Sadler,=20
Jonathan B. [mailto:Jonathan.Sadler@tellabs.com] <SPAN=20
style=3D"FONT-WEIGHT: bold">Sent: Monday, July 24, 2006 5:38=20
PM To: Brungard, =
Deborah A,=20
ALABS; Ong, Lyndon; ccamp@ops.ietf.org <SPAN=20
style=3D"FONT-WEIGHT: bold">Cc: Adrian Farrel <SPAN=20
style=3D"FONT-WEIGHT: bold">Subject: RE: Proposed response to =
OIF on=20
OSPF ENNI<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Hi=20
Deborah,<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">While I do =
not speak=20
for the OIF, I can say that the members of the OIF are on record (by =
motion) to=20
follow the Requirements and Architecture specified in G.8080, G.7715 and =

G.7715.1. &nbsp;Since the final IETF requirements and IETF evaluations =
documents=20
were never liaised to the ITU for comment/agreement before they were =
sent for=20
publication, I cannot say that they are aligned with the requirements of =
the=20
OIF.<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">Regards,<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p>
<st1:PersonName w:st=3D"on">Jonathan=20
Sadler</st1:PersonName><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p>
<DIV>
<DIV class=3DMsoNormal style=3D"TEXT-ALIGN: center" align=3Dcenter><FONT =

face=3D"Times New Roman" size=3D3>
<HR tabIndex=3D-1 align=3Dcenter width=3D"100%" SIZE=3D2>
</DIV>
<SPAN=20
style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma">From:<FONT=20
face=3DTahoma size=3D2> Brungard,=20
Deborah A, ALABS [mailto:dbrungard@att.com] <SPAN=20
style=3D"FONT-WEIGHT: bold">Sent: Monday, July 24, 2006 4:31=20
PM To: Sadler, =
Jonathan B.;=20
Ong, Lyndon; ccamp@ops.ietf.org <SPAN=20
style=3D"FONT-WEIGHT: bold">Cc: Adrian Farrel <SPAN=20
style=3D"FONT-WEIGHT: bold">Subject: RE: Proposed response to =
OIF on=20
OSPF ENNI<o:p></o:p></DIV>
<SPAN=20
style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Hi=20
Jonathan,<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">I just sent =
mail to=20
Lyndon to ask if he felt CCAMP's work was aligned. From your mail below, =
you do=20
believe that CCAMP's ASON requirements document and evaluation document =
meet the=20
needs of OIF? As the OIF Liaison stated it specified requirements, we=20
do&nbsp;want to ensure that the work is =
aligned.<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
Arial">Thanks,<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
Arial">Deborah<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p>
<DIV class=3DMsoNormal style=3D"TEXT-ALIGN: center" align=3Dcenter><FONT =

face=3D"Times New Roman" size=3D3>
<HR tabIndex=3D-1 align=3Dcenter width=3D"100%" SIZE=3D2>
</DIV>
<SPAN=20
style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma">From:<FONT=20
face=3DTahoma size=3D2> Sadler,=20
Jonathan B. [mailto:Jonathan.Sadler@tellabs.com] <SPAN=20
style=3D"FONT-WEIGHT: bold">Sent: Monday, July 24, 2006 4:32=20
PM To: Brungard, =
Deborah A,=20
ALABS; Ong, Lyndon; ccamp@ops.ietf.org <SPAN=20
style=3D"FONT-WEIGHT: bold">Cc: Adrian Farrel <SPAN=20
style=3D"FONT-WEIGHT: bold">Subject: RE: Proposed response to =
OIF on=20
OSPF ENNI<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Hi Deborah, =
Lyndon, et=20
al,<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Some =
additional=20
comments:<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">&nbsp;- The=20
hierarchical model discussed in the draft IA liaised may be supported =
without=20
any modifications to OSPF.&nbsp; As discussed in earlier emails, it can =
be=20
implemented solely through the import/export of information described in =

Appendix I of G.7715.<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">&nbsp;- The =
draft IA=20
also recognizes namespace issues exist between Router ID and the IP =
Address that=20
messages are sent to (ITU calls this the RC PC SCN address).&nbsp; This =
issue is=20
also discussed in=20
draft-ietf-ccamp-gmpls-addressing.<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Given=20
that:<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal style=3D"MARGIN-LEFT: 21pt; TEXT-INDENT: =
-0.25in"><FONT=20
face=3DArial color=3Dnavy size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">-</SPAN></FONT><FONT=20
color=3Dnavy size=3D1><SPAN=20
style=3D"FONT-SIZE: 7pt; COLOR: =
navy">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></FONT><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">CCAMP has a =
milestone=20
to publish an ASON routing solution by Nov 2006, =
<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal style=3D"MARGIN-LEFT: 21pt; TEXT-INDENT: =
-0.25in"><FONT=20
face=3DArial color=3Dnavy size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">-</SPAN></FONT><FONT=20
color=3Dnavy size=3D1><SPAN=20
style=3D"FONT-SIZE: 7pt; COLOR: =
navy">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></FONT><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">CCAMP =
didn&#8217;t have at=20
the time this was liaised (doesn&#8217;t have today?) a working group =
document,=20
and<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal style=3D"MARGIN-LEFT: 21pt; TEXT-INDENT: =
-0.25in"><FONT=20
face=3DArial color=3Dnavy size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">-</SPAN></FONT><FONT=20
color=3Dnavy size=3D1><SPAN=20
style=3D"FONT-SIZE: 7pt; COLOR: =
navy">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></FONT><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">the draft IA =
has been=20
successfully implemented by more than a dozen vendors and interop-tested =
many=20
times,<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">I would =
expect that we=20
should be looking at this as experience/text that could be =
leveraged...&nbsp;=20
&#8220;Running code&#8230;&#8221; and all =
that&#8230;<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">Regards,<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=3DMsoNormal><st1:PersonName w:st=3D"on"><FONT face=3DArial =
color=3Dnavy=20
size=3D2><SPAN style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">Jonathan=20
Sadler</SPAN></FONT></st1:PersonName><FONT face=3DArial color=3Dnavy =
size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<DIV>
<DIV class=3DMsoNormal style=3D"TEXT-ALIGN: center" align=3Dcenter><FONT =

face=3D"Times New Roman" size=3D3>
<HR tabIndex=3D-1 align=3Dcenter width=3D"100%" SIZE=3D2>
</DIV>
<SPAN=20
style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma">From:<FONT=20
face=3DTahoma size=3D2> Ong,=20
Lyndon [mailto:Lyong@Ciena.com] <SPAN=20
style=3D"FONT-WEIGHT: bold">Sent: Monday, July 24, 2006 2:33=20
PM To: Brungard, =
Deborah A,=20
ALABS; Sadler, Jonathan B.; ccamp@ops.ietf.org <SPAN=20
style=3D"FONT-WEIGHT: bold">Cc: Adrian Farrel <SPAN=20
style=3D"FONT-WEIGHT: bold">Subject: RE: Proposed response to =
OIF on=20
OSPF ENNI<o:p></o:p></DIV>
<SPAN=20
style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Hi=20
Deborah,<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Here's what I =
would=20
say&nbsp;is in and not in the OIF document:<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">-- G.7715, =
G.7715.1 and=20
the IETF eval and solutions draft all identify a need to support=20
hierarchical<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">routing areas =
for ASON,=20
I am perplexed as to why this seems to be viewed as a new=20
feature.<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">-- the =
document does=20
not specify the domain of usage and leaves this to the carrier.&nbsp; =
This is no=20
different<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">from G.7715.1 =
and IETF=20
drafts that do not explicitly state whether they are used for intra- or=20
inter-domain<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
Arial">interfaces.<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">-- GMPLS OSPF =
does not=20
support a 1:N or N:1 relationship between routing controller and=20
transport<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">node, hence =
extensions=20
are felt to be required - and are proposed in the eval solutions draft. =
The=20
<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">conclusions =
are no=20
different.<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">-- the =
document does=20
not in fact define any standard extensions to the protocols, and points =
to=20
future work<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">in IETF and =
ITU to=20
provide these.&nbsp; Therefore I cannot understand where you say "new =
extensions=20
to<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">OSPF are =
specified" and=20
"none...align with the CCAMP's GMPLS-ASON work".&nbsp;=20
<o:p></o:p>
<DIV>
<SPAN=20
style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p></DIV>
<DIV>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">I think we're =

experiencing a significant=20
miscommunication...</SPAN></FONT><o:p></o:p></P></DIV>
<DIV>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p></SPAN></FONT></P></DIV>
<DIV>
<P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
Arial">Cheers,</SPAN></FONT><o:p></o:p></P></DIV>
<DIV>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p></SPAN></FONT></P></DIV>
<DIV>
<P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
Arial">Lyndon</SPAN></FONT><o:p></o:p></P></DIV>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<DIV class=3DMsoNormal style=3D"TEXT-ALIGN: center" align=3Dcenter><FONT =

face=3D"Times New Roman" size=3D3><SPAN style=3D"FONT-SIZE: 12pt">
<HR tabIndex=3D-1 align=3Dcenter width=3D"100%" SIZE=3D2>
</SPAN></FONT></DIV>
<P class=3DMsoNormal style=3D"MARGIN-BOTTOM: 12pt"><B><FONT =
face=3DTahoma size=3D2><SPAN=20
style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma">From:</SPAN></FONT></B><FONT=20
face=3DTahoma size=3D2><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma">=20
owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] <B><SPAN=20
style=3D"FONT-WEIGHT: bold">On Behalf Of </SPAN></B>Brungard, Deborah A, =

ALABS Sent: Monday, =
July 24,=20
2006 12:15 PM To: =
Sadler,=20
Jonathan B.; ccamp@ops.ietf.org <SPAN=20
style=3D"FONT-WEIGHT: bold">Cc: Adrian Farrel <SPAN=20
style=3D"FONT-WEIGHT: bold">Subject: RE: Proposed response to =
OIF on=20
OSPF ENNI<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Hi Jonathan, =
(and=20
Lyndon),<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Thanks to =
both of you=20
for responding.<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">"Significant" =
was=20
referencing:<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">-=20
supports&nbsp;a&nbsp;(new) hierarchical OSPF =
model<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
Arial">-&nbsp;supports&nbsp;inter-domain=20
(inter-carrier) OSPF (not supported by today's=20
OSPF)<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">- identifies =
namespace=20
issues with GMPLS OSPF which do not exist, and proposes extensions to=20
"fix"<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">- new =
extensions to=20
OSPF are specified<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">- none of the =
proposed=20
extensions align with CCAMP's GMPLS-ASON =
work<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Did you have =
another=20
adjective to suggest? We&nbsp;were thinking&nbsp;"significant" was =
rather soft=20
considering the above. Though if it's just ITU-speak differences, why =
does the=20
OIF liaison state it reflects several years of work including testing? =
Any=20
insight (alignment mapping to CCAMP's work) which you or Lyndon can =
provide=20
would be helpful.&nbsp;The divergence is&nbsp;baffling to=20
us.<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
Arial">Deborah<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p>
<DIV class=3DMsoNormal style=3D"TEXT-ALIGN: center" align=3Dcenter><FONT =

face=3D"Times New Roman" size=3D3><SPAN style=3D"FONT-SIZE: 12pt">
<HR tabIndex=3D-1 align=3Dcenter width=3D"100%" SIZE=3D2>
</SPAN></FONT></DIV>
<P class=3DMsoNormal style=3D"MARGIN-BOTTOM: 12pt"><B><FONT =
face=3DTahoma size=3D2><SPAN=20
style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma">From:</SPAN></FONT></B><FONT=20
face=3DTahoma size=3D2><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma"> Sadler,=20
Jonathan B. [mailto:Jonathan.Sadler@tellabs.com] <BR><B><SPAN=20
style=3D"FONT-WEIGHT: bold">Sent:</SPAN></B> Friday, July 21, 2006 11:34 =

AM To: Brungard, =
Deborah A,=20
ALABS; ccamp@ops.ietf.org Cc:=20
Adrian Farrel Subject: RE:=20
Proposed response to OIF on OSPF ENNI<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Hi Deborah =
and=20
Adrian,<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">I =
haven&#8217;t seen much=20
discussion of the OIF E-NNI Routing document on the CCAMP list. =
&nbsp;Can you=20
tell me what parts of the document are &#8220;significant modifications =
to the=20
operation of OSPF&#8221;?<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">Thanks,<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p>
<st1:PersonName w:st=3D"on">Jonathan=20
Sadler</st1:PersonName><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p>
<DIV>
<DIV class=3DMsoNormal style=3D"TEXT-ALIGN: center" align=3Dcenter><FONT =

face=3D"Times New Roman" size=3D3><SPAN style=3D"FONT-SIZE: 12pt">
<HR tabIndex=3D-1 align=3Dcenter width=3D"100%" SIZE=3D2>
</SPAN></FONT></DIV>
<P class=3DMsoNormal><B><FONT face=3DTahoma size=3D2><SPAN=20
style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma">From:</SPAN></FONT></B><FONT=20
face=3DTahoma size=3D2><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma">=20
owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] <B><SPAN=20
style=3D"FONT-WEIGHT: bold">On Behalf Of </SPAN></B>Brungard, Deborah A, =

ALABS<BR><B><SPAN style=3D"FONT-WEIGHT: bold">Sent:</SPAN></B> Friday, =
July 21,=20
2006 9:38 AM<BR><B><SPAN style=3D"FONT-WEIGHT: bold">To:</SPAN></B>=20
ccamp@ops.ietf.org<BR><B><SPAN style=3D"FONT-WEIGHT: =
bold">Cc:</SPAN></B> Adrian=20
Farrel<BR><B><SPAN style=3D"FONT-WEIGHT: bold">Subject:</SPAN></B> =
Proposed=20
response to OIF on OSPF ENNI</SPAN></FONT><o:p></o:p></P></DIV>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
Arial">Hi,</SPAN></FONT><o:p></o:p></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">We had a =
communication=20
from OIF on their OSPF ENNI specification. You can see the original =
files on=20
</SPAN></FONT><A href=3D"http://www.olddog.co.uk/ccamp.htm"><FONT =
face=3DArial=20
size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial">http://www.olddog.co.uk/ccamp.htm</SPAN></FONT></A><FONT=20
face=3DArial color=3Dblue size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">. Having =
assembled=20
comments from several people and our discussions in <st1:place=20
w:st=3D"on"><st1:City w:st=3D"on">Montreal</st1:City></st1:place>, we =
have put=20
together the following response.</SPAN></FONT><o:p></o:p></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p></SPAN></FONT></P>
<DIV>
<P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Please =
comment on the=20
list in the next week.</SPAN></FONT><o:p></o:p></P></DIV>
<DIV>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p></SPAN></FONT></P></DIV>
<DIV>
<P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
Arial">Thanks,</SPAN></FONT><o:p></o:p></P></DIV>
<DIV>
<P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Adrian and=20
Deborah</SPAN></FONT><o:p></o:p></P></DIV>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p></SPAN></FONT></P>
<DIV>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">=3D =3D =3D =3D =3D =3D =3D =3D =3D =
=3D<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">Dear Jim,<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">We thank you for sending us the OIF ENNI =
document in=20
response to our request. While we appreciate the document being provided =
for=20
information, it is concerning that this document has not been previously =
shared=20
with CCAMP or the OSPF WG considering the document contains significant=20
modifications to the operation of OSPF and reflects OIF work over the =
last=20
several years. CCAMP has been working on GMPLS ASON for several years =
and our=20
Design Teams include OIF participants. Even though a reply was not =
requested, we=20
are replying, as we strongly recommend that the document not be =
published for=20
public information in its current form.<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">Of most concern to CCAMP is that it is not =
aligned with=20
RFC 4258 (Requirements for Generalized Multi-Protocol Label Switching =
(GMPLS)=20
Routing for the Automatically Switched Optical Network (ASON)) or the=20
to-be-published: <A=20
href=3D"ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpls-ason-rou=
ting-eval-03.txt">ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpl=
s-ason-routing-eval-03.txt</A>.=20
Considering notable OIF participants are authors of both these IETF =
documents=20
(and the same participants are contributors and the Editor for the OIF=20
document), the non-alignment is perplexing. Considering the IETF =
document is=20
ready for publication, we suggest in the interests of time, that you =
align your=20
document with the IETF document. If any questions on the interpretation =
of the=20
IETF&#8217;s work, we recommend that you either utilize the CCAMP mail =
exploder or=20
send a communication.<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">Specific comments =
include:<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal style=3D"MARGIN-LEFT: 0.25in; TEXT-INDENT: =
-0.25in"><FONT=20
face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">1.</SPAN></FONT><FONT size=3D1><SPAN=20
style=3D"FONT-SIZE: 7pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</SPAN></FONT>What is the=20
intent of this document? Will it be published as an Implementation =
Agreement=20
(IA)?<BR>The title indicates it will be an Implementation Agreement on =
GMPLS=20
OSPF extensions, but the main body of the document is a list of issues =
with=20
GMPLS OSPF. Further, your communication to us stated the document was=20
requirements on and use of OSPF-TE at the ENNI. These three views seem =
to be=20
inconsistent.<o:p></o:p></P>
<P class=3DMsoNormal style=3D"MARGIN-LEFT: 0.25in; TEXT-INDENT: =
-0.25in"><I><FONT=20
face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-STYLE: =
italic">2.</SPAN></FONT></I><I><FONT=20
size=3D1><SPAN=20
style=3D"FONT-SIZE: 7pt; FONT-STYLE: =
italic">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></FONT></I>The list of changes from the previous version (listed =
under=20
the Table of Contents) includes &#8220;<I><SPAN style=3D"FONT-STYLE: =
italic">removed=20
&#8220;intra-carrier&#8221; limitation</SPAN></I>&#8221; and the =
inclusion of Figure 1 showing the=20
OSPF ENNI for use between vendor domains and between carrier domains. =
GMPLS=20
OSPF-TE already supports inter-vendor operations. <BR>The IETF&#8217;s =
GMPLS ASON=20
routing focus has been on the use of a link-state based protocol to =
support a=20
hierarchical routing architecture (G.7715.1) within a carrier&#8217;s =
domain.=20
Requirements for using a link state protocol as an inter-domain protocol =
between=20
carriers are significantly different. We strongly disagree if you intend =
to=20
publish this document as an inter-carrier OSPF ENNI Implementation =
Agreement=20
claiming alignment with IETF RFCs without review (or agreement) by any =
of the=20
IETF Working Groups.<I><SPAN=20
style=3D"FONT-STYLE: italic"><o:p></o:p></SPAN></I></P>
<P class=3DMsoNormal style=3D"MARGIN-LEFT: 0.25in; TEXT-INDENT: =
-0.25in"><FONT=20
face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">3.</SPAN></FONT><FONT size=3D1><SPAN=20
style=3D"FONT-SIZE: 7pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</SPAN></FONT>Section=20
4.1/Table 1 and the statement under the table identifying issues with =
GMPLS=20
identifier namespaces are not correct. GMPLS identifier namespaces do =
meet ASON=20
requirements for namespace separation of the transport plane and control =
plane=20
(Section 5.2 and 5.3/Evaluation). Perhaps you are confusing OSPF and =
GMPLS OSPF?=20
As you also identified in your liaison that the key area needing review =
was the=20
support of independence of functional component to physical location, =
this=20
appears to be a key area of misunderstanding on GMPLS. We recommend =
reviewing=20
RFC3945 (GMPLS Architecture) to understand that the key architecture =
difference=20
between GMPLS and MPLS is the decoupling of the transport plane and =
control=20
plane. Additionally, RFC4394, RFC4397, and RFC4258, provide a mapping to =
ITU=20
terminology which may be helpful reading.<o:p></o:p></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">We request an additional round of =
communication of this=20
document to the IETF before approval to allow us to work with you to =
produce=20
convergence between OIF and IETF work which, we believe, will be in the =
best=20
interests of the industry.<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">Best regards,<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><st1:PersonName w:st=3D"on"><FONT face=3D"Times New =
Roman"=20
size=3D3><SPAN style=3D"FONT-SIZE: 12pt">Adrian=20
Farrel</SPAN></FONT></st1:PersonName> and Deborah =
Brungard,<o:p></o:p></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">CCAMP =
co-chairs<o:p></o:p></SPAN></FONT></P></DIV><PRE><FONT face=3D"Courier =
New" size=3D2><SPAN style=3D"FONT-SIZE: =
10pt">=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<o:p></o:p></SPAN></FONT></PRE><PRE><=
FONT face=3D"Courier New" size=3D2><SPAN style=3D"FONT-SIZE: 10pt">The =
information contained in this message may be =
privileged<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
size=3D2><SPAN style=3D"FONT-SIZE: 10pt">and confidential and protected =
from disclosure. If the reader<o:p></o:p></SPAN></FONT></PRE><PRE><FONT =
face=3D"Courier New" size=3D2><SPAN style=3D"FONT-SIZE: 10pt">of this =
message is not the intended recipient, or an =
employee<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
size=3D2><SPAN style=3D"FONT-SIZE: 10pt">or agent responsible for =
delivering this message to the<o:p></o:p></SPAN></FONT></PRE><PRE><FONT =
face=3D"Courier New" size=3D2><SPAN style=3D"FONT-SIZE: 10pt">intended =
recipient, you are hereby notified that any =
reproduction,<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier =
New" size=3D2><SPAN style=3D"FONT-SIZE: 10pt">dissemination or =
distribution of this communication is =
strictly<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
size=3D2><SPAN style=3D"FONT-SIZE: 10pt">prohibited. If you have =
received this communication in =
error,<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
size=3D2><SPAN style=3D"FONT-SIZE: 10pt">please notify us immediately by =
replying to the message and<o:p></o:p></SPAN></FONT></PRE><PRE><FONT =
face=3D"Courier New" size=3D2><SPAN style=3D"FONT-SIZE: 10pt">deleting =
it from your computer. Thank you. =
Tellabs<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
size=3D2><SPAN style=3D"FONT-SIZE: =
10pt">=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<o:p></o:p></SPAN></FONT></PRE><PRE><=
FONT face=3D"Courier New" size=3D2><SPAN style=3D"FONT-SIZE: =
10pt">=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<o:p></o:p></SPAN></FONT></PRE><PRE><=
FONT face=3D"Courier New" size=3D2><SPAN style=3D"FONT-SIZE: 10pt">The =
information contained in this message may be =
privileged<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
size=3D2><SPAN style=3D"FONT-SIZE: 10pt">and confidential and protected =
from disclosure. If the reader<o:p></o:p></SPAN></FONT></PRE><PRE><FONT =
face=3D"Courier New" size=3D2><SPAN style=3D"FONT-SIZE: 10pt">of this =
message is not the intended recipient, or an =
employee<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
size=3D2><SPAN style=3D"FONT-SIZE: 10pt">or agent responsible for =
delivering this message to the<o:p></o:p></SPAN></FONT></PRE><PRE><FONT =
face=3D"Courier New" size=3D2><SPAN style=3D"FONT-SIZE: 10pt">intended =
recipient, you are hereby notified that any =
reproduction,<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier =
New" size=3D2><SPAN style=3D"FONT-SIZE: 10pt">dissemination or =
distribution of this communication is =
strictly<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
size=3D2><SPAN style=3D"FONT-SIZE: 10pt">prohibited. If you have =
received this communication in =
error,<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
size=3D2><SPAN style=3D"FONT-SIZE: 10pt">please notify us immediately by =
replying to the message and<o:p></o:p></SPAN></FONT></PRE><PRE><FONT =
face=3D"Courier New" size=3D2><SPAN style=3D"FONT-SIZE: 10pt">deleting =
it from your computer. Thank you. =
Tellabs<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
size=3D2><SPAN style=3D"FONT-SIZE: =
10pt">=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<o:p></o:p></SPAN></FONT></PRE><PRE><=
FONT face=3D"Courier New" size=3D2><SPAN style=3D"FONT-SIZE: =
10pt">=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<o:p></o:p></SPAN></FONT></PRE><PRE><=
FONT face=3D"Courier New" size=3D2><SPAN style=3D"FONT-SIZE: 10pt">The =
information contained in this message may be =
privileged<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
size=3D2><SPAN style=3D"FONT-SIZE: 10pt">and confidential and protected =
from disclosure. If the reader<o:p></o:p></SPAN></FONT></PRE><PRE><FONT =
face=3D"Courier New" size=3D2><SPAN style=3D"FONT-SIZE: 10pt">of this =
message is not the intended recipient, or an =
employee<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
size=3D2><SPAN style=3D"FONT-SIZE: 10pt">or agent responsible for =
delivering this message to the<o:p></o:p></SPAN></FONT></PRE><PRE><FONT =
face=3D"Courier New" size=3D2><SPAN style=3D"FONT-SIZE: 10pt">intended =
recipient, you are hereby notified that any =
reproduction,<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier =
New" size=3D2><SPAN style=3D"FONT-SIZE: 10pt">dissemination or =
distribution of this communication is =
strictly<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
size=3D2><SPAN style=3D"FONT-SIZE: 10pt">prohibited. If you have =
received this communication in =
error,<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
size=3D2><SPAN style=3D"FONT-SIZE: 10pt">please notify us immediately by =
replying to the message and<o:p></o:p></SPAN></FONT></PRE><PRE><FONT =
face=3D"Courier New" size=3D2><SPAN style=3D"FONT-SIZE: 10pt">deleting =
it from your computer. Thank you. =
Tellabs<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
size=3D2><SPAN style=3D"FONT-SIZE: =
10pt">=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<o:p></o:p></SPAN></FONT></PRE></DIV>=
<PRE>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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
</PRE></BODY></HTML>

------_=_NextPart_001_01C6B01D.11BB6ACE--

Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 25 Jul 2006 18:11:52 +0000
To: "Ong, Lyndon" <Lyong@Ciena.com>
Cc: "Adrian Farrel" <adrian@olddog.co.uk>, ccamp@ops.ietf.org, "Brungard, Deborah A, ALABS" <dbrungard@att.com>, "Sadler, Jonathan B." <Jonathan.Sadler@tellabs.com>, owner-ccamp@ops.ietf.org
Subject: RE: Proposed response to OIF on OSPF ENNI
MIME-Version: 1.0
Message-ID: <OFFA1F9E22.BA240709-ONC12571B6.00631DA5-C12571B6.0063E931@netfr.alcatel.fr>
From: Dimitri.Papadimitriou@alcatel.be
Date: Tue, 25 Jul 2006 20:11:16 +0200
Content-Type: text/plain; charset="US-ASCII"

lyndon - see my reply to jonathan on this specific point - 

i can sum'up the evaluation phases lead to different premises and ext. 
guidelines (in addition to the specific OIF reachability information 
encoding) hence, these extensions are not reconcilable without 
reconsidering the protocol evaluation itself - it is the basic reason why 
i have been so scrupulous in driving this evaluation work as accurate as 
possible - and the reason why the proposed liaison text directly referred 
to this Section 4.1

ps: could you answer to my previous post ? on OIF IA scope

"Ong, Lyndon" <Lyong@Ciena.com>
25/07/2006 20:01

        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     "Adrian Farrel" <adrian@olddog.co.uk>, 
<ccamp@ops.ietf.org>, "Brungard, Deborah A, ALABS" <dbrungard@att.com>, 
"Sadler, Jonathan B." <Jonathan.Sadler@tellabs.com>, 
<owner-ccamp@ops.ietf.org>
        Subject:        RE: Proposed response to OIF on OSPF ENNI

Hi Dimitri,

Well, they could of course become agreed standard codepoints if
CCAMP adopted them (unlikely as that appears to be given the past
history of CCAMP and any protocol proposals made by other bodies)
hence "at this time" seemed like a required note.

OIF would of course be very happy if CCAMP agreed to adopt the
formats that were implemented during OIF prototype testing,
this is still possible :o)

Cheers,

Lyndon 

-----Original Message-----
From: Dimitri.Papadimitriou@alcatel.be
[mailto:Dimitri.Papadimitriou@alcatel.be] 
Sent: Tuesday, July 25, 2006 10:54 AM
To: Ong, Lyndon
Cc: Adrian Farrel; ccamp@ops.ietf.org; Brungard, Deborah A, ALABS;
Sadler, Jonathan B.; owner-ccamp@ops.ietf.org
Subject: RE: Proposed response to OIF on OSPF ENNI

lyndon - indeed this is mentioned - the concern here can be formulated
as
follows: section 1.2 of the OIF IA is unclear about positioning and
exact intention with 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." 

you wrote: "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."

the fact that the sentence combines "at this time" and points to
potential "standard codepoints" means that we have to warn OIF about
implication i.e. if OIF intents to change their status (toward standard
codepoints) then the extensions will be de-facto subject to the
MPLS/GMPLS change process from the IETF perspective

ps: this is also the reason why there is a direct relationship between
objective of the document (see previous post) and listed extensions -

"Ong, Lyndon" <Lyong@Ciena.com>
Sent by: owner-ccamp@ops.ietf.org
25/07/2006 18:55

        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Sadler, 
Jonathan B." <Jonathan.Sadler@tellabs.com>
        cc:     "Adrian Farrel" <adrian@olddog.co.uk>, 
<ccamp@ops.ietf.org>, "Brungard, Deborah A, ALABS" <dbrungard@att.com>, 
<owner-ccamp@ops.ietf.org>
        Subject:        RE: Proposed response to OIF on OSPF ENNI

Hi Dimitri,

I completely agree with you that there is much unnecessary hubbub
going on.  The document does in fact point to IETF (and ITU) for
standard extensions to the routing protocols.

>From the discussion I have the sense that there is some unhappiness with
the
document focusing on requirements that are still in the process of being

addressed within CCAMP, but since it points to the drafts being done
here
if anything it should focus reader's attention on the work here in CCAMP
rather than anywhere else. 

Cheers,

Lyndon

-----Original Message-----
From: Dimitri.Papadimitriou@alcatel.be
[mailto:Dimitri.Papadimitriou@alcatel.be] 
Sent: Tuesday, July 25, 2006 3:18 AM
To: Sadler, Jonathan B.; Ong, Lyndon
Cc: Adrian Farrel; ccamp@ops.ietf.org; Brungard, Deborah A, ALABS;
owner-ccamp@ops.ietf.org
Subject: RE: Proposed response to OIF on OSPF ENNI

jonathan & lyndon

o) During Dallas CCAMP meeting, IETF 66, we have had the following
discussion (extracted from the meeting minutes) 

"Kireeti: What would make me happy is not to have extensions defined in
IAs 
         Work has been done in the IETF. Instead, we will have objects
in the specs and IAs 
         Putting the extensions in an informational appendix is still
confusing, especially 
         as vendors have implemented them for demos 
         I would prefer that you just point to IETF so as extensions
evolve in the IETF, you 
         stay coordinated
Jim: We [the OIF] don't think that differently 
     One of our goals is to align and converge. 
     We understand we are using experimental codepoints" 

so, it is rather unclear why there is so much hubub when IETF proposes
to achieve this objective ? if i well understand your opinion is that
IETF should not target this objective ? let's assume this is the case,
it still does not allow OIF to bypass the MPLS-GMPLS change process 

o) concerning the alignment of IETF vs G.7715 and G.7715.1, from the
IETF liaison webpage you will see that a set of exchanges between bodies
has been conducted to ensure such alignment; however, as ITU should be
defining ASON routing requirements your statement "I cannot say that
they are aligned with the requirements of the OIF" is totally unclear to
me. 
Does OIF has its own requirements or are OIF requirements not fully
aligned with ITU G.7715/.1 ? This question should be reflected in the
liaison to OIF - as a CLEAR response from OIF will surely help sorting
the present situation 

o) what is the real "issue" by pointing to the addressing i-d, the
latter just provides recommendation in case of 1:1 corr. between data
and control plane entities; i thought ASON was looking at larger scope -
so what's the point beside trying to mis-use any IETF production to
corroborate the GMPLS OSPF digression of Section 4.1 of the OIF IA ?

o) the tone of the OIF IA is its first sections is totally inappropriate
and misleading - so requires major revision - by reading one got the
impression by reading that a) OIF puts premises of a new protocol
recommendation while also stating it is a demo code reporting for a
single level - this must be seriously revisited b) OIF has apparently
discovered major holes and flaws, while issue is limited to unnumbered
links with overlapping ID space per TE Router ID (as detailed in section
5.7 of the eval doc) - alignment on these aspect(s) is also more than
recommended imho 

o) at the end, the major concern is that it is totally unclear what the
purpose of the OIF IA OSPF extensions are, if the intention of OIF is to
push them outside OIF demo scope (which seems to be the case since the
document passes through OIF ballot process and thus will be openly
available after this phase), then de-facto it is an OIF dutty to ask
IETF for in-depth revision and full alignment before publication 

ps: to achieve a standard you need running code, but not any running
code becomes a standard even informational (hopefully);

-d.

"Sadler, Jonathan B." <Jonathan.Sadler@tellabs.com> Sent by:
owner-ccamp@ops.ietf.org
24/07/2006 22:31

        To:     "Brungard, Deborah A, ALABS" <dbrungard@att.com>, "Ong, 
Lyndon" <Lyong@Ciena.com>, <ccamp@ops.ietf.org>
        cc:     "Adrian Farrel" <adrian@olddog.co.uk>
        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:Lyong@Ciena.com]
Sent: Monday, July 24, 2006 2: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,

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: 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),

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:Jonathan.Sadler@tellabs.com]
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,

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

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.

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

Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 25 Jul 2006 18:07:56 +0000
To: "Sadler, Jonathan B." <Jonathan.Sadler@tellabs.com>
Cc: "Adrian Farrel" <adrian@olddog.co.uk>, ccamp@ops.ietf.org, "Brungard, Deborah A, ALABS" <dbrungard@att.com>, "Ong, Lyndon" <Lyong@Ciena.com>, owner-ccamp@ops.ietf.org
Subject: RE: Proposed response to OIF on OSPF ENNI
MIME-Version: 1.0
Message-ID: <OF488C1069.831FD749-ONC12571B6.005C8B90-C12571B6.00638C50@netfr.alcatel.fr>
From: Dimitri.Papadimitriou@alcatel.be
Date: Tue, 25 Jul 2006 20:07:18 +0200
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: base64

aGkgam9uYXRoYW4NCg0KPiBSZWdhcmRpbmcgVG9waWMgMjoNCj4gDQo+IFRoZSBJRVRGIHJlcXVp
cmVtZW50cyBhbmQgZXZhbHVhdGlvbiBkb2N1bWVudHMgZG9u4oCZdCBtYWtlIGFueSBzcGVjaWZp
YyANCnN0YXRlbWVudHMgYWJvdXQgdGhlIGZpdG5lc3Mgb2YgSUVURiBwcm90b2NvbHMgZm9yIEFT
T04gcm91dGluZy4gDQo+IENDQU1QIGhhcyBub3QgZmluaXNoZWQgKHN0YXJ0ZWQ/KSBhIGRvY3Vt
ZW50IHRoYXQgbWFrZXMgYW55IHNwZWNpZmljIA0Kc3RhdGVtZW50cyBhYm91dCBPU1BGLg0KDQpz
ZWN0aW9uIDcgb2YgdGhlIGV2YWwuIGRvYyAoU3VtbWFyeSBvZiBOZWNlc3NhcnkgQWRkaXRpb25z
IHRvIE9TUEYgYW5kIA0KSVMtSVMpIGlzIHByb2JhYmx5IHdoYXQgeW91J3JlIGxvb2tpbmcgYXQ7
IHRoZSBldmFsdWF0aW9uIGRvYyBwcm9wb3NlcyBhIA0KY2xlYXIgcGF0aCB0byBhY2hpZXZlIHRo
ZXNlIGV4dGVuc2lvbnMNCg0KdGhlIE9TUEYgc29sLiBkb2Mgd2FzIHBvbGxlZCBvbiB0aGlzIGxp
c3Qgc3RhcnRpbmcgZnJvbSBsYXN0IElFVEYgbWVldGluZywgDQp5ZXMsIGl0IG1heSBsb29rIGxp
a2Ugc2xvd2VyIHRoYW4gZXhwZWN0ZWQgYnV0IGkgcHJpdmlsZWdlIHJldmlld3MgJiANCnF1YWxp
dHkgb3ZlciBydXNoDQogDQo+IEFnYWluIEkgYXNrLCB3b3VsZG7igJl0IGl0IGJlIGJldHRlciB0
byBsb29rIGF0IHRoaXMgZG9jdW1lbnQgd2hpY2ggaGFzIA0KYmVlbiBpbXBsZW1lbnRlZCBieSBt
YW55IHZlbmRvcnMsIGFuZCBzdWNjZXNzZnVsbHkgaW50ZXJvcGVyYWJpbGl0eSANCj4gdGVzdGVk
IG1hbnkgdGltZXMgb3ZlciBtYW55IHllYXJzIHRvIHNlZSB3aGF0IGNhbiBiZSBsZXZlcmFnZWQg
aW5zdGVhZCANCm9mIHN0YXJ0aW5nIGZyb20gc2NyYXRjaD8NCg0KSUVURiBldmFsdWF0aW9uIGRv
YyBvdXRjb21lcyBhbmQgZ3VpZGVsaW5lcyBhcmUgbm90IGFsaWduZWQgd2l0aCBPSUYgDQpldmFs
dWF0aW9uIG91dGNvbWVzIC0gU2VjdGlvbiA0LjEgb2YgdGhlIE9JRiBJQSAoeW91IHdpbGwgYWxz
byBmaW5kIGhlcmUgDQp0aGUgcmF0aW9uYWxlIGZvciB0aGUgcG9pbnRlciB0byB0aGF0IHNlY3Rp
b24gaW4gdGhlIHByb3Bvc2VkIGxpYWlzb24gDQp0ZXh0KSBhbmQgYXNzdW1wdGlvbiBvbiBhZGRy
ZXNzaW5nIHNwYWNlcyBtYWtlcyB0aGUgT0lGIGV4dGVuc2lvbnMgbm90IA0KcmVjb25jaWxhYmxl
OyB0aGlzIGlzIHRoZSBzcGVjaWZpYyByZWFzb24gd2h5IE9JRiBhbGlnbm1lbnQgc2hvdWxkIC1p
ZiBzbyANCmRlc2lyZWQgYnkgT0lGLSBzdGFydCBmcm9tIHRoZSBwcm90b2NvbCBldmFsdWF0aW9u
IHBoYXNlIC0gDQoNCmkgYWdyZWUgd2l0aCBkZWJvcmFoIGhlcmUsIENDQU1QIHNob3VsZCBzZW5k
IHRoaXMgZG9jIHRvIE9JRiBmb3IgDQpjb25zaWRlcmF0aW9uLiANCg0KdGhhbmtzLA0KLSBkaW1p
dHJpLiANCg==

Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 25 Jul 2006 18:02:02 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Proposed response to OIF on OSPF ENNI
Date: Tue, 25 Jul 2006 14:01:14 -0400
Message-ID: <0901D1988E815341A0103206A834DA07F1A26C@mdmxm02.ciena.com>
Thread-Topic: Proposed response to OIF on OSPF ENNI
Thread-Index: AcawE2hvbwaEwyLNR+SnbPxTHPzE8QAACVgw
From: "Ong, Lyndon" <Lyong@Ciena.com>
To: <Dimitri.Papadimitriou@alcatel.be>
Cc: "Adrian Farrel" <adrian@olddog.co.uk>, <ccamp@ops.ietf.org>, "Brungard, Deborah A, ALABS" <dbrungard@att.com>, "Sadler, Jonathan B." <Jonathan.Sadler@tellabs.com>, <owner-ccamp@ops.ietf.org>

Hi Dimitri,

Well, they could of course become agreed standard codepoints if
CCAMP adopted them (unlikely as that appears to be given the past
history of CCAMP and any protocol proposals made by other bodies)
hence "at this time" seemed like a required note.

OIF would of course be very happy if CCAMP agreed to adopt the
formats that were implemented during OIF prototype testing,
this is still possible :o)

Cheers,

Lyndon=20

-----Original Message-----
From: Dimitri.Papadimitriou@alcatel.be
[mailto:Dimitri.Papadimitriou@alcatel.be]=20
Sent: Tuesday, July 25, 2006 10:54 AM
To: Ong, Lyndon
Cc: Adrian Farrel; ccamp@ops.ietf.org; Brungard, Deborah A, ALABS;
Sadler, Jonathan B.; owner-ccamp@ops.ietf.org
Subject: RE: Proposed response to OIF on OSPF ENNI

lyndon - indeed this is mentioned - the concern here can be formulated
as
follows: section 1.2 of the OIF IA is unclear about positioning and
exact intention with the proposed extensions (in Appendix)=20

"These extensions use codepoints in the range reserved by IANA for
private and experimental use, and are not agreed standard codepoints at
this time.=20
Future developments may result in change to the codepoints and/or
formats of these extensions."=20

you wrote: "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."

the fact that the sentence combines "at this time" and points to
potential "standard codepoints" means that we have to warn OIF about
implication i.e. if OIF intents to change their status (toward standard
codepoints) then the extensions will be de-facto subject to the
MPLS/GMPLS change process from the IETF perspective

ps: this is also the reason why there is a direct relationship between
objective of the document (see previous post) and listed extensions -

"Ong, Lyndon" <Lyong@Ciena.com>
Sent by: owner-ccamp@ops.ietf.org
25/07/2006 18:55
=20
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Sadler,=20
Jonathan B." <Jonathan.Sadler@tellabs.com>
        cc:     "Adrian Farrel" <adrian@olddog.co.uk>,=20
<ccamp@ops.ietf.org>, "Brungard, Deborah A, ALABS" <dbrungard@att.com>,=20
<owner-ccamp@ops.ietf.org>
        Subject:        RE: Proposed response to OIF on OSPF ENNI

Hi Dimitri,

I completely agree with you that there is much unnecessary hubbub
going on.  The document does in fact point to IETF (and ITU) for
standard extensions to the routing protocols.

>From the discussion I have the sense that there is some unhappiness with
the
document focusing on requirements that are still in the process of being

addressed within CCAMP, but since it points to the drafts being done
here
if anything it should focus reader's attention on the work here in CCAMP
rather than anywhere else.=20

Cheers,

Lyndon

-----Original Message-----
From: Dimitri.Papadimitriou@alcatel.be
[mailto:Dimitri.Papadimitriou@alcatel.be]=20
Sent: Tuesday, July 25, 2006 3:18 AM
To: Sadler, Jonathan B.; Ong, Lyndon
Cc: Adrian Farrel; ccamp@ops.ietf.org; Brungard, Deborah A, ALABS;
owner-ccamp@ops.ietf.org
Subject: RE: Proposed response to OIF on OSPF ENNI

jonathan & lyndon

o) During Dallas CCAMP meeting, IETF 66, we have had the following
discussion (extracted from the meeting minutes)=20

"Kireeti: What would make me happy is not to have extensions defined in
IAs=20
         Work has been done in the IETF. Instead, we will have objects
in the specs and IAs=20
         Putting the extensions in an informational appendix is still
confusing, especially=20
         as vendors have implemented them for demos=20
         I would prefer that you just point to IETF so as extensions
evolve in the IETF, you=20
         stay coordinated
Jim: We [the OIF] don't think that differently=20
     One of our goals is to align and converge.=20
     We understand we are using experimental codepoints"=20

so, it is rather unclear why there is so much hubub when IETF proposes
to achieve this objective ? if i well understand your opinion is that
IETF should not target this objective ? let's assume this is the case,
it still does not allow OIF to bypass the MPLS-GMPLS change process=20

o) concerning the alignment of IETF vs G.7715 and G.7715.1, from the
IETF liaison webpage you will see that a set of exchanges between bodies
has been conducted to ensure such alignment; however, as ITU should be
defining ASON routing requirements your statement "I cannot say that
they are aligned with the requirements of the OIF" is totally unclear to
me.=20
Does OIF has its own requirements or are OIF requirements not fully
aligned with ITU G.7715/.1 ? This question should be reflected in the
liaison to OIF - as a CLEAR response from OIF will surely help sorting
the present situation=20

o) what is the real "issue" by pointing to the addressing i-d, the
latter just provides recommendation in case of 1:1 corr. between data
and control plane entities; i thought ASON was looking at larger scope -
so what's the point beside trying to mis-use any IETF production to
corroborate the GMPLS OSPF digression of Section 4.1 of the OIF IA ?

o) the tone of the OIF IA is its first sections is totally inappropriate
and misleading - so requires major revision - by reading one got the
impression by reading that a) OIF puts premises of a new protocol
recommendation while also stating it is a demo code reporting for a
single level - this must be seriously revisited b) OIF has apparently
discovered major holes and flaws, while issue is limited to unnumbered
links with overlapping ID space per TE Router ID (as detailed in section
5.7 of the eval doc) - alignment on these aspect(s) is also more than
recommended imho=20

o) at the end, the major concern is that it is totally unclear what the
purpose of the OIF IA OSPF extensions are, if the intention of OIF is to
push them outside OIF demo scope (which seems to be the case since the
document passes through OIF ballot process and thus will be openly
available after this phase), then de-facto it is an OIF dutty to ask
IETF for in-depth revision and full alignment before publication=20

ps: to achieve a standard you need running code, but not any running
code becomes a standard even informational (hopefully);

-d.

"Sadler, Jonathan B." <Jonathan.Sadler@tellabs.com> Sent by:
owner-ccamp@ops.ietf.org
24/07/2006 22:31
=20
        To:     "Brungard, Deborah A, ALABS" <dbrungard@att.com>, "Ong,=20
Lyndon" <Lyong@Ciena.com>, <ccamp@ops.ietf.org>
        cc:     "Adrian Farrel" <adrian@olddog.co.uk>
        Subject:        RE: Proposed response to OIF on OSPF ENNI

Hi Deborah, Lyndon, et al,
=20
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.
=20
Given that:
-          CCAMP has a milestone to publish an ASON routing solution by=20
Nov 2006,=20
-          CCAMP didn't have at the time this was liaised (doesn't have=20
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...
=20
Regards,
=20
Jonathan Sadler
=20

From: Ong, Lyndon [mailto:Lyong@Ciena.com]
Sent: Monday, July 24, 2006 2: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
=20
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
-- 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.
=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 conclusions are no
different.
=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".=20
=20
I think we're experiencing a significant miscommunication...
=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"=20
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]
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:=20
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.      What is the intent of this document? Will it be published as an=20
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=20
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.      Section 4.1/Table 1 and the statement under the table
identifying=20
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).=20
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

Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 25 Jul 2006 17:55:36 +0000
To: "Ong, Lyndon" <Lyong@Ciena.com>
Cc: "Adrian Farrel" <adrian@olddog.co.uk>, ccamp@ops.ietf.org, "Brungard, Deborah A, ALABS" <dbrungard@att.com>, "Sadler, Jonathan B." <Jonathan.Sadler@tellabs.com>, owner-ccamp@ops.ietf.org
Subject: RE: Proposed response to OIF on OSPF ENNI
MIME-Version: 1.0
Message-ID: <OF422D072D.0D8CAEF6-ONC12571B6.005E2E71-C12571B6.00625D88@netfr.alcatel.fr>
From: Dimitri.Papadimitriou@alcatel.be
Date: Tue, 25 Jul 2006 19:54:23 +0200
Content-Type: text/plain; charset="US-ASCII"

lyndon - indeed this is mentioned - the concern here can be formulated as 
follows: section 1.2 of the OIF IA is unclear about positioning and exact 
intention with 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." 

you wrote: "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."

the fact that the sentence combines "at this time" and points to potential 
"standard codepoints" means that we have to warn OIF about implication 
i.e. if OIF intents to change their status (toward standard codepoints) 
then the extensions will be de-facto subject to the MPLS/GMPLS change 
process from the IETF perspective

ps: this is also the reason why there is a direct relationship between 
objective of the document (see previous post) and listed extensions -

"Ong, Lyndon" <Lyong@Ciena.com>
Sent by: owner-ccamp@ops.ietf.org
25/07/2006 18:55

        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Sadler, 
Jonathan B." <Jonathan.Sadler@tellabs.com>
        cc:     "Adrian Farrel" <adrian@olddog.co.uk>, 
<ccamp@ops.ietf.org>, "Brungard, Deborah A, ALABS" <dbrungard@att.com>, 
<owner-ccamp@ops.ietf.org>
        Subject:        RE: Proposed response to OIF on OSPF ENNI

Hi Dimitri,

I completely agree with you that there is much unnecessary hubbub
going on.  The document does in fact point to IETF (and ITU) for
standard extensions to the routing protocols.

>From the discussion I have the sense that there is some unhappiness with
the
document focusing on requirements that are still in the process of being

addressed within CCAMP, but since it points to the drafts being done
here
if anything it should focus reader's attention on the work here in CCAMP
rather than anywhere else. 

Cheers,

Lyndon

-----Original Message-----
From: Dimitri.Papadimitriou@alcatel.be
[mailto:Dimitri.Papadimitriou@alcatel.be] 
Sent: Tuesday, July 25, 2006 3:18 AM
To: Sadler, Jonathan B.; Ong, Lyndon
Cc: Adrian Farrel; ccamp@ops.ietf.org; Brungard, Deborah A, ALABS;
owner-ccamp@ops.ietf.org
Subject: RE: Proposed response to OIF on OSPF ENNI

jonathan & lyndon

o) During Dallas CCAMP meeting, IETF 66, we have had the following
discussion (extracted from the meeting minutes) 

"Kireeti: What would make me happy is not to have extensions defined in
IAs 
         Work has been done in the IETF. Instead, we will have objects
in the specs and IAs 
         Putting the extensions in an informational appendix is still
confusing, especially 
         as vendors have implemented them for demos 
         I would prefer that you just point to IETF so as extensions
evolve in the IETF, you 
         stay coordinated
Jim: We [the OIF] don't think that differently 
     One of our goals is to align and converge. 
     We understand we are using experimental codepoints" 

so, it is rather unclear why there is so much hubub when IETF proposes
to achieve this objective ? if i well understand your opinion is that
IETF should not target this objective ? let's assume this is the case,
it still does not allow OIF to bypass the MPLS-GMPLS change process 

o) concerning the alignment of IETF vs G.7715 and G.7715.1, from the
IETF liaison webpage you will see that a set of exchanges between bodies
has been conducted to ensure such alignment; however, as ITU should be
defining ASON routing requirements your statement "I cannot say that
they are aligned with the requirements of the OIF" is totally unclear to
me. 
Does OIF has its own requirements or are OIF requirements not fully
aligned with ITU G.7715/.1 ? This question should be reflected in the
liaison to OIF - as a CLEAR response from OIF will surely help sorting
the present situation 

o) what is the real "issue" by pointing to the addressing i-d, the
latter just provides recommendation in case of 1:1 corr. between data
and control plane entities; i thought ASON was looking at larger scope -
so what's the point beside trying to mis-use any IETF production to
corroborate the GMPLS OSPF digression of Section 4.1 of the OIF IA ?

o) the tone of the OIF IA is its first sections is totally inappropriate
and misleading - so requires major revision - by reading one got the
impression by reading that a) OIF puts premises of a new protocol
recommendation while also stating it is a demo code reporting for a
single level - this must be seriously revisited b) OIF has apparently
discovered major holes and flaws, while issue is limited to unnumbered
links with overlapping ID space per TE Router ID (as detailed in section
5.7 of the eval doc) - alignment on these aspect(s) is also more than
recommended imho 

o) at the end, the major concern is that it is totally unclear what the
purpose of the OIF IA OSPF extensions are, if the intention of OIF is to
push them outside OIF demo scope (which seems to be the case since the
document passes through OIF ballot process and thus will be openly
available after this phase), then de-facto it is an OIF dutty to ask
IETF for in-depth revision and full alignment before publication 

ps: to achieve a standard you need running code, but not any running
code becomes a standard even informational (hopefully);

-d.

"Sadler, Jonathan B." <Jonathan.Sadler@tellabs.com> Sent by:
owner-ccamp@ops.ietf.org
24/07/2006 22:31

        To:     "Brungard, Deborah A, ALABS" <dbrungard@att.com>, "Ong, 
Lyndon" <Lyong@Ciena.com>, <ccamp@ops.ietf.org>
        cc:     "Adrian Farrel" <adrian@olddog.co.uk>
        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:Lyong@Ciena.com]
Sent: Monday, July 24, 2006 2: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,

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: 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),

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:Jonathan.Sadler@tellabs.com]
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,

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

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.

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

Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 25 Jul 2006 17:18:31 +0000
To: "Ong, Lyndon" <Lyong@Ciena.com>
Cc: "Adrian Farrel" <adrian@olddog.co.uk>, ccamp@ops.ietf.org, "Brungard, Deborah A, ALABS" <dbrungard@att.com>, "Sadler, Jonathan B." <Jonathan.Sadler@tellabs.com>, owner-ccamp@ops.ietf.org
Subject: RE: Proposed response to OIF on OSPF ENNI
MIME-Version: 1.0
Message-ID: <OF5854A4B5.6FB3F498-ONC12571B6.005E6D06-C12571B6.005EEF14@netfr.alcatel.fr>
From: Dimitri.Papadimitriou@alcatel.be
Date: Tue, 25 Jul 2006 19:16:54 +0200
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: base64

bHluZG9uIC0gDQoNCmRvbid0IHlvdSB0aGluayBpdCBpcyBhIG5hdHVyYWwgcmVhY3Rpb24gdG8g
YXNrIE9JRiBpbnRlbnRpb25zIHdoZW4gdGhlIA0KcmVhZGVyIGlzIGNvbmZyb250ZWQgdG8gMyBk
aWZmZXJlbnQgb2JqZWN0aXZlcyBzdGF0ZWQgaW4gdGhlIE9JRiBJQQ0KDQpvKSBsaXN0IE9JRiBk
ZW1vIGV4dGVuc2lvbnMgKHBhZ2UgNSkNCm8pIGFkZHJlc3MgT0lGIHJlcXVpcmVtZW50cyAocGFn
ZSA0KQ0KbykgYWRkcmVzcyBHLjc3MTUuMSByZXF1aXJlbWVudHMgKHBhZ2UgNSkNCg0KYW5kIHRo
ZW4gcXVlc3Rpb24gYWJvdXQgT0lGIHJlcXVpcmVtZW50IGRlbHRhIHZzIEcuNzcxNS4xID8NCg0K
aSBob3BlIHlvdSBjYW4gaGVscCBhcyBlZGl0b3Igb2YgdGhpcyBkb2N1bWVudA0KDQp0aGFua3Ms
DQotIGQuDQoNCg0KDQoNCg0KDQoiT25nLCBMeW5kb24iIDxMeW9uZ0BDaWVuYS5jb20+DQpTZW50
IGJ5OiBvd25lci1jY2FtcEBvcHMuaWV0Zi5vcmcNCjI1LzA3LzIwMDYgMTg6MzANCiANCiAgICAg
ICAgVG86ICAgICAiQnJ1bmdhcmQsIERlYm9yYWggQSwgQUxBQlMiIDxkYnJ1bmdhcmRAYXR0LmNv
bT4sICJTYWRsZXIsIA0KSm9uYXRoYW4gQi4iIDxKb25hdGhhbi5TYWRsZXJAdGVsbGFicy5jb20+
LCA8Y2NhbXBAb3BzLmlldGYub3JnPg0KICAgICAgICBjYzogICAgICJBZHJpYW4gRmFycmVsIiA8
YWRyaWFuQG9sZGRvZy5jby51az4NCiAgICAgICAgU3ViamVjdDogICAgICAgIFJFOiBQcm9wb3Nl
ZCByZXNwb25zZSB0byBPSUYgb24gT1NQRiBFTk5JDQoNCg0KSGkgRGVib3JhaCwNCiANCkp1c3Qg
dG8gYmUgY2xlYXIsIGFzIGVkaXRvciBvZiB0aGUgT0lGIGRvY3VtZW50IGFuZCBjby1hdXRob3Ig
b2YgdGhlIGV2YWwgDQpkcmFmdCwgSSBzdGlsbCBiZWxpZXZlDQpib3RoIHRvIGJlIHZlcnkgbXVj
aCBpbiBhbGlnbm1lbnQuICBBbmQsIG9mIGNvdXJzZSwgdGhlIE9JRiBkb2N1bWVudCANCnBvaW50
cyBkaXJlY3RseSB0bw0KRy43NzE1LjEgYXMgd2VsbC4gIFRoZXJlIHNlZW1zIHRvIGJlIGEgcGVy
Y2VwdGlvbiBiZWluZyBlbmNvdXJhZ2VkIHRoYXQgDQp0aGVyZSBpcyBzb21lDQpzb3J0IG9mIG1p
c2FsaWdubWVudCwgYnV0IHRoaXMgaXMgbm90IHRydWUgYXQgYWxsLg0KIA0KQXMgdG8gdGhlIHJl
bGF0aXZlIHJlbGF0aW9uc2hpcHMgb2YgdGhlIGdyb3VwczogIHRoZSBldmFsIGRyYWZ0IGFuZCB0
aGUNCnNvbHV0aW9ucyBkcmFmdCBhcmUgYm90aCBJRVRGIGRvY3VtZW50cy4gIFRoZXkgYXJlIG5v
dCBPSUYgb3IgSVRVIA0KZG9jdW1lbnRzLCBhbmQNCmRlY2lzaW9ucyBtYWRlIGluIHRoZSBkcmFm
dHMgYXJlIElFVEYgZGVjaXNpb25zLiAgUmVsYXRlZCBkcmFmdHMgc3VjaCBhcyANCnRoZQ0KY2Fs
bCBzaWduYWxpbmcgZHJhZnQgYXJlIG5vdCBldmVuIGdvaW5nIHRvIGJlIHBhc3NlZCB0aHJvdWdo
IElUVSBvciBPSUYgDQpmb3IgZWl0aGVyIGdyb3VwIA0KdG8gcmV2aWV3LiAgSSBjYW4gYW5kIGRv
IGRpc2FncmVlIHdpdGggdGhhdCBkZWNpc2lvbiwgYnV0IG15IHZpZXdzIGFyZSANCnRyZWF0ZWQg
YXMgdGhvc2UNCm9mIGEgc2luZ2xlIElFVEYgcGFydGljaXBhbnQgd2l0aCBubyBncmVhdGVyIHdl
aWdodCB0aGFuIGFueSBvdGhlcnMnIA0KKG1heWJlIGxlc3MgOm8oDQogDQpTbyBwbGVhc2UsIGxl
dCdzIGNvbmZpbmUgb3Vyc2VsdmVzIHRvIGNvbW1lbnRpbmcgb24gYXJlYXMgZGVzY3JpYmluZyBH
TVBMUyANCihlc3AuIHRoZSB0YWJsZQ0KaW4gNC4xKSBhbmQgaWRlbnRpZmljYXRpb24gb2YgdGVj
aG5pY2FsIGNvbmNlcm5zIChzdWNoIGFzIHRoZSANCmludGVyL2ludHJhLWNhcnJpZXIgc2NvcGUp
IA0KYW5kIG5vdCB3b3JyeSBhYm91dCBPSUYncyAiaW50ZW50aW9ucyIgb3IgImFsaWdubWVudCIs
IHNpbmNlIA0KYSkgdGhpcyBpcyBub3QgYW4gSUVURiBkb2N1bWVudA0KYikgdGhlIGRvY3VtZW50
IHNwZWNpZmljYWxseSBwb2ludHMgdG8gSUVURi9JVFUgZm9yIHRoZSBwcm90b2NvbCANCnN0YW5k
YXJkcy4gDQogDQpDaGVlcnMsDQogDQpMeW5kb24NCg0KRnJvbTogQnJ1bmdhcmQsIERlYm9yYWgg
QSwgQUxBQlMgW21haWx0bzpkYnJ1bmdhcmRAYXR0LmNvbV0gDQpTZW50OiBUdWVzZGF5LCBKdWx5
IDI1LCAyMDA2IDc6NTggQU0NClRvOiBTYWRsZXIsIEpvbmF0aGFuIEIuOyBPbmcsIEx5bmRvbjsg
Y2NhbXBAb3BzLmlldGYub3JnDQpDYzogQWRyaWFuIEZhcnJlbA0KU3ViamVjdDogUkU6IFByb3Bv
c2VkIHJlc3BvbnNlIHRvIE9JRiBvbiBPU1BGIEVOTkkNCg0KSGkgSm9uYXRoYW4sDQogDQpJIHRo
aW5rIHlvdSBtZWFudCBPSUYgYmVsb3csIGFzIElUVSBhbmQgSUVURiB3b3JrIG9uIEFTT04gaGFz
IGJlZW4gdGlnaHRseSANCmNvb3JkaW5hdGVkIGUuZy4gYSBxdWljayBiYWNrIHNlYXJjaDoNCmh0
dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvcHVibGljL2xpYWlzb25fZGV0YWlsLmNnaT9kZXRh
aWxfaWQ9MTUwDQogDQpUaGlzIG1pcy1tYXRjaCBpcyBhbHdheXMgdGhlIGNvbmNlcm4gd2hlbiB3
b3JrIGlzIGR1cGxpY2F0ZWQgaW4gb3RoZXIgDQpncm91cHMuIEZvciBPSUYgdG8gYmUgcHJvZ3Jl
c3NpbmcgYSBkb2N1bWVudCBpZGVudGlmeWluZyBpc3N1ZXMgd2l0aCBHTVBMUyANCmZvciBzdXBw
b3J0aW5nIEFTT04gd2hlbiBhbHJlYWR5IENDQU1QIGhhcyBmaW5pc2hlZCB0aGVpciBkb2N1bWVu
dCBpcyBub3QgDQpvbmx5IGEgbWlzdXNlIG9mIHBlb3BsZSdzIHRpbWUgKGJvdGggaW4gT0lGIGFu
ZCBJRVRGKSwgaXQgYWxzbyBjYXVzZXMgDQpjb25mdXNpb24gaW4gdGhlIGluZHVzdHJ5ICh3ZSBu
b3cgaGF2ZSBJVFUtc3BlYWssIENDQU1QLXNwZWFrLCBhbmQgDQpPSUYtc3BlYWspLg0KIA0KQXMg
dGhlIGhvcGUgb2YgdGhlIENDQU1QJ3MgQVNPTiBEZXNpZ24gVGVhbXMgd2FzIHRvIGhhdmUgYSBy
ZXByZXNlbnRhdGlvbiANCm9mIElUVSwgT0lGLCBhbmQgQ0NBTVAgKGVzcGVjaWFsbHkgY29uc2lk
ZXJpbmcgTHluZG9uIGlzIE9JRidzIExpYWlzb24gdG8gDQpDQ0FNUCAoYW5kIGVkaXRvciBvZiB0
aGUgT0lGIGRvY3VtZW50KSBhbmQgeW91IGFzIGNoYWlyKSwgaWYgYm90aCBvZiB5b3UgDQpoYXZl
IGRpZmZpY3VsdHkganVkZ2luZyB0aGUgYWxpZ25tZW50IG9mIHRoaXMgZG9jdW1lbnQgdnMuIEFT
T04gDQpyZXF1aXJlbWVudHMgYW5kIENDQU1QJ3Mgd29yaywgdGhlbiB0aGUgZG9jdW1lbnQgaXMg
bm90IGhlbHBpbmcgZWl0aGVyIA0KT0lGJ3MgaW50ZW50aW9uIHRvIGRldmVsb3Agc3RhbmRhcmRz
IGluIGFsaWdubWVudCB3aXRoIElUVSBhbmQgSUVURiBvciANCkNDQU1QJ3MgYWJpbGl0eSB0byBk
ZXZlbG9wIGFuIEFTT04gc29sdXRpb24uDQogDQpXZSBzaG91bGQgcmUtc3BpbiB0aGUgTGlhaXNv
biB0byBpbmZvcm0gT0lGIHRoYXQgdGhpcyB3b3JrIGhhcyBiZWVuIA0KY29tcGxldGVkIGluIEND
QU1QIGFuZCB0byByZXF1ZXN0IHRoYXQgT0lGJ3MgZXZhbHVhdGlvbiBzZWN0aW9ucyBiZSANCnJl
bW92ZWQgYW5kIHJlcGxhY2VkIHdpdGggcmVmZXJlbmNlcyB0byB0aGUgRXZhbHVhdGlvbiBkb2N1
bWVudCAodnMuIA0KdHJ5aW5nIHRvIGRvIG11bHRpcGxlLXNwZWFrIHdoaWNoIGhhcyB1cyBhbGwg
Y29uZnVzZWQpIGFuZCBleHBhbmQgb24gdGhlIA0KY29tbWVudHMgKERpbWl0cmkncyBtYWlsIHdo
aWNoIEx5bmRvbiBoYXMgYWdyZWVkIGlzIHZlcnkgdXNlZnVsKS4gSSdsbCANCndvcmsgb24gaXQg
dG9kYXksIGFuZCBzZW5kIGxhdGVyLg0KIA0KIlNpZ25pZmljYW50IiBUaGFua3Mgb24gdGhlIGNv
bmZ1c2lvbjstKQ0KRGVib3JhaA0KDQpGcm9tOiBTYWRsZXIsIEpvbmF0aGFuIEIuIFttYWlsdG86
Sm9uYXRoYW4uU2FkbGVyQHRlbGxhYnMuY29tXSANClNlbnQ6IE1vbmRheSwgSnVseSAyNCwgMjAw
NiA1OjM4IFBNDQpUbzogQnJ1bmdhcmQsIERlYm9yYWggQSwgQUxBQlM7IE9uZywgTHluZG9uOyBj
Y2FtcEBvcHMuaWV0Zi5vcmcNCkNjOiBBZHJpYW4gRmFycmVsDQpTdWJqZWN0OiBSRTogUHJvcG9z
ZWQgcmVzcG9uc2UgdG8gT0lGIG9uIE9TUEYgRU5OSQ0KDQpIaSBEZWJvcmFoLA0KIA0KV2hpbGUg
SSBkbyBub3Qgc3BlYWsgZm9yIHRoZSBPSUYsIEkgY2FuIHNheSB0aGF0IHRoZSBtZW1iZXJzIG9m
IHRoZSBPSUYgDQphcmUgb24gcmVjb3JkIChieSBtb3Rpb24pIHRvIGZvbGxvdyB0aGUgUmVxdWly
ZW1lbnRzIGFuZCBBcmNoaXRlY3R1cmUgDQpzcGVjaWZpZWQgaW4gRy44MDgwLCBHLjc3MTUgYW5k
IEcuNzcxNS4xLiAgU2luY2UgdGhlIGZpbmFsIElFVEYgDQpyZXF1aXJlbWVudHMgYW5kIElFVEYg
ZXZhbHVhdGlvbnMgZG9jdW1lbnRzIHdlcmUgbmV2ZXIgbGlhaXNlZCB0byB0aGUgSVRVIA0KZm9y
IGNvbW1lbnQvYWdyZWVtZW50IGJlZm9yZSB0aGV5IHdlcmUgc2VudCBmb3IgcHVibGljYXRpb24s
IEkgY2Fubm90IHNheSANCnRoYXQgdGhleSBhcmUgYWxpZ25lZCB3aXRoIHRoZSByZXF1aXJlbWVu
dHMgb2YgdGhlIE9JRi4NCiANClJlZ2FyZHMsDQogDQpKb25hdGhhbiBTYWRsZXINCiANCg0KRnJv
bTogQnJ1bmdhcmQsIERlYm9yYWggQSwgQUxBQlMgW21haWx0bzpkYnJ1bmdhcmRAYXR0LmNvbV0g
DQpTZW50OiBNb25kYXksIEp1bHkgMjQsIDIwMDYgNDozMSBQTQ0KVG86IFNhZGxlciwgSm9uYXRo
YW4gQi47IE9uZywgTHluZG9uOyBjY2FtcEBvcHMuaWV0Zi5vcmcNCkNjOiBBZHJpYW4gRmFycmVs
DQpTdWJqZWN0OiBSRTogUHJvcG9zZWQgcmVzcG9uc2UgdG8gT0lGIG9uIE9TUEYgRU5OSQ0KIA0K
SGkgSm9uYXRoYW4sDQogDQpJIGp1c3Qgc2VudCBtYWlsIHRvIEx5bmRvbiB0byBhc2sgaWYgaGUg
ZmVsdCBDQ0FNUCdzIHdvcmsgd2FzIGFsaWduZWQuIA0KRnJvbSB5b3VyIG1haWwgYmVsb3csIHlv
dSBkbyBiZWxpZXZlIHRoYXQgQ0NBTVAncyBBU09OIHJlcXVpcmVtZW50cyANCmRvY3VtZW50IGFu
ZCBldmFsdWF0aW9uIGRvY3VtZW50IG1lZXQgdGhlIG5lZWRzIG9mIE9JRj8gQXMgdGhlIE9JRiBM
aWFpc29uIA0Kc3RhdGVkIGl0IHNwZWNpZmllZCByZXF1aXJlbWVudHMsIHdlIGRvIHdhbnQgdG8g
ZW5zdXJlIHRoYXQgdGhlIHdvcmsgaXMgDQphbGlnbmVkLg0KIA0KVGhhbmtzLA0KRGVib3JhaA0K
IA0KDQpGcm9tOiBTYWRsZXIsIEpvbmF0aGFuIEIuIFttYWlsdG86Sm9uYXRoYW4uU2FkbGVyQHRl
bGxhYnMuY29tXSANClNlbnQ6IE1vbmRheSwgSnVseSAyNCwgMjAwNiA0OjMyIFBNDQpUbzogQnJ1
bmdhcmQsIERlYm9yYWggQSwgQUxBQlM7IE9uZywgTHluZG9uOyBjY2FtcEBvcHMuaWV0Zi5vcmcN
CkNjOiBBZHJpYW4gRmFycmVsDQpTdWJqZWN0OiBSRTogUHJvcG9zZWQgcmVzcG9uc2UgdG8gT0lG
IG9uIE9TUEYgRU5OSQ0KSGkgRGVib3JhaCwgTHluZG9uLCBldCBhbCwNCiANClNvbWUgYWRkaXRp
b25hbCBjb21tZW50czoNCiAtIFRoZSBoaWVyYXJjaGljYWwgbW9kZWwgZGlzY3Vzc2VkIGluIHRo
ZSBkcmFmdCBJQSBsaWFpc2VkIG1heSBiZSANCnN1cHBvcnRlZCB3aXRob3V0IGFueSBtb2RpZmlj
YXRpb25zIHRvIE9TUEYuICBBcyBkaXNjdXNzZWQgaW4gZWFybGllciANCmVtYWlscywgaXQgY2Fu
IGJlIGltcGxlbWVudGVkIHNvbGVseSB0aHJvdWdoIHRoZSBpbXBvcnQvZXhwb3J0IG9mIA0KaW5m
b3JtYXRpb24gZGVzY3JpYmVkIGluIEFwcGVuZGl4IEkgb2YgRy43NzE1Lg0KIC0gVGhlIGRyYWZ0
IElBIGFsc28gcmVjb2duaXplcyBuYW1lc3BhY2UgaXNzdWVzIGV4aXN0IGJldHdlZW4gUm91dGVy
IElEIA0KYW5kIHRoZSBJUCBBZGRyZXNzIHRoYXQgbWVzc2FnZXMgYXJlIHNlbnQgdG8gKElUVSBj
YWxscyB0aGlzIHRoZSBSQyBQQyBTQ04gDQphZGRyZXNzKS4gIFRoaXMgaXNzdWUgaXMgYWxzbyBk
aXNjdXNzZWQgaW4gDQpkcmFmdC1pZXRmLWNjYW1wLWdtcGxzLWFkZHJlc3NpbmcuDQogDQpHaXZl
biB0aGF0Og0KLSAgICAgICAgICBDQ0FNUCBoYXMgYSBtaWxlc3RvbmUgdG8gcHVibGlzaCBhbiBB
U09OIHJvdXRpbmcgc29sdXRpb24gYnkgDQpOb3YgMjAwNiwgDQotICAgICAgICAgIENDQU1QIGRp
ZG7igJl0IGhhdmUgYXQgdGhlIHRpbWUgdGhpcyB3YXMgbGlhaXNlZCAoZG9lc27igJl0IGhhdmUg
DQp0b2RheT8pIGEgd29ya2luZyBncm91cCBkb2N1bWVudCwgYW5kDQotICAgICAgICAgIHRoZSBk
cmFmdCBJQSBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgaW1wbGVtZW50ZWQgYnkgbW9yZSB0aGFuIGEg
DQpkb3plbiB2ZW5kb3JzIGFuZCBpbnRlcm9wLXRlc3RlZCBtYW55IHRpbWVzLA0KSSB3b3VsZCBl
eHBlY3QgdGhhdCB3ZSBzaG91bGQgYmUgbG9va2luZyBhdCB0aGlzIGFzIGV4cGVyaWVuY2UvdGV4
dCB0aGF0IA0KY291bGQgYmUgbGV2ZXJhZ2VkLi4uICDigJxSdW5uaW5nIGNvZGXigKbigJ0gYW5k
IGFsbCB0aGF04oCmDQogDQpSZWdhcmRzLA0KIA0KSm9uYXRoYW4gU2FkbGVyDQogDQoNCkZyb206
IE9uZywgTHluZG9uIFttYWlsdG86THlvbmdAQ2llbmEuY29tXSANClNlbnQ6IE1vbmRheSwgSnVs
eSAyNCwgMjAwNiAyOjMzIFBNDQpUbzogQnJ1bmdhcmQsIERlYm9yYWggQSwgQUxBQlM7IFNhZGxl
ciwgSm9uYXRoYW4gQi47IGNjYW1wQG9wcy5pZXRmLm9yZw0KQ2M6IEFkcmlhbiBGYXJyZWwNClN1
YmplY3Q6IFJFOiBQcm9wb3NlZCByZXNwb25zZSB0byBPSUYgb24gT1NQRiBFTk5JDQogDQpIaSBE
ZWJvcmFoLA0KIA0KSGVyZSdzIHdoYXQgSSB3b3VsZCBzYXkgaXMgaW4gYW5kIG5vdCBpbiB0aGUg
T0lGIGRvY3VtZW50Og0KIA0KLS0gRy43NzE1LCBHLjc3MTUuMSBhbmQgdGhlIElFVEYgZXZhbCBh
bmQgc29sdXRpb25zIGRyYWZ0IGFsbCBpZGVudGlmeSBhIA0KbmVlZCB0byBzdXBwb3J0IGhpZXJh
cmNoaWNhbA0Kcm91dGluZyBhcmVhcyBmb3IgQVNPTiwgSSBhbSBwZXJwbGV4ZWQgYXMgdG8gd2h5
IHRoaXMgc2VlbXMgdG8gYmUgdmlld2VkIA0KYXMgYSBuZXcgZmVhdHVyZS4NCiANCi0tIHRoZSBk
b2N1bWVudCBkb2VzIG5vdCBzcGVjaWZ5IHRoZSBkb21haW4gb2YgdXNhZ2UgYW5kIGxlYXZlcyB0
aGlzIHRvIA0KdGhlIGNhcnJpZXIuICBUaGlzIGlzIG5vIGRpZmZlcmVudA0KZnJvbSBHLjc3MTUu
MSBhbmQgSUVURiBkcmFmdHMgdGhhdCBkbyBub3QgZXhwbGljaXRseSBzdGF0ZSB3aGV0aGVyIHRo
ZXkgDQphcmUgdXNlZCBmb3IgaW50cmEtIG9yIGludGVyLWRvbWFpbg0KaW50ZXJmYWNlcy4NCiAN
Ci0tIEdNUExTIE9TUEYgZG9lcyBub3Qgc3VwcG9ydCBhIDE6TiBvciBOOjEgcmVsYXRpb25zaGlw
IGJldHdlZW4gcm91dGluZyANCmNvbnRyb2xsZXIgYW5kIHRyYW5zcG9ydA0Kbm9kZSwgaGVuY2Ug
ZXh0ZW5zaW9ucyBhcmUgZmVsdCB0byBiZSByZXF1aXJlZCAtIGFuZCBhcmUgcHJvcG9zZWQgaW4g
dGhlIA0KZXZhbCBzb2x1dGlvbnMgZHJhZnQuIFRoZSANCmNvbmNsdXNpb25zIGFyZSBubyBkaWZm
ZXJlbnQuDQogDQotLSB0aGUgZG9jdW1lbnQgZG9lcyBub3QgaW4gZmFjdCBkZWZpbmUgYW55IHN0
YW5kYXJkIGV4dGVuc2lvbnMgdG8gdGhlIA0KcHJvdG9jb2xzLCBhbmQgcG9pbnRzIHRvIGZ1dHVy
ZSB3b3JrDQppbiBJRVRGIGFuZCBJVFUgdG8gcHJvdmlkZSB0aGVzZS4gIFRoZXJlZm9yZSBJIGNh
bm5vdCB1bmRlcnN0YW5kIHdoZXJlIHlvdSANCnNheSAibmV3IGV4dGVuc2lvbnMgdG8NCk9TUEYg
YXJlIHNwZWNpZmllZCIgYW5kICJub25lLi4uYWxpZ24gd2l0aCB0aGUgQ0NBTVAncyBHTVBMUy1B
U09OIHdvcmsiLiANCiANCkkgdGhpbmsgd2UncmUgZXhwZXJpZW5jaW5nIGEgc2lnbmlmaWNhbnQg
bWlzY29tbXVuaWNhdGlvbi4uLg0KIA0KQ2hlZXJzLA0KIA0KTHluZG9uDQogDQoNCkZyb206IG93
bmVyLWNjYW1wQG9wcy5pZXRmLm9yZyBbbWFpbHRvOm93bmVyLWNjYW1wQG9wcy5pZXRmLm9yZ10g
T24gQmVoYWxmIA0KT2YgQnJ1bmdhcmQsIERlYm9yYWggQSwgQUxBQlMNClNlbnQ6IE1vbmRheSwg
SnVseSAyNCwgMjAwNiAxMjoxNSBQTQ0KVG86IFNhZGxlciwgSm9uYXRoYW4gQi47IGNjYW1wQG9w
cy5pZXRmLm9yZw0KQ2M6IEFkcmlhbiBGYXJyZWwNClN1YmplY3Q6IFJFOiBQcm9wb3NlZCByZXNw
b25zZSB0byBPSUYgb24gT1NQRiBFTk5JDQpIaSBKb25hdGhhbiwgKGFuZCBMeW5kb24pLA0KIA0K
VGhhbmtzIHRvIGJvdGggb2YgeW91IGZvciByZXNwb25kaW5nLg0KIA0KIlNpZ25pZmljYW50IiB3
YXMgcmVmZXJlbmNpbmc6DQogDQotIHN1cHBvcnRzIGEgKG5ldykgaGllcmFyY2hpY2FsIE9TUEYg
bW9kZWwNCi0gc3VwcG9ydHMgaW50ZXItZG9tYWluIChpbnRlci1jYXJyaWVyKSBPU1BGIChub3Qg
c3VwcG9ydGVkIGJ5IHRvZGF5J3MgDQpPU1BGKQ0KLSBpZGVudGlmaWVzIG5hbWVzcGFjZSBpc3N1
ZXMgd2l0aCBHTVBMUyBPU1BGIHdoaWNoIGRvIG5vdCBleGlzdCwgYW5kIA0KcHJvcG9zZXMgZXh0
ZW5zaW9ucyB0byAiZml4Ig0KLSBuZXcgZXh0ZW5zaW9ucyB0byBPU1BGIGFyZSBzcGVjaWZpZWQN
Ci0gbm9uZSBvZiB0aGUgcHJvcG9zZWQgZXh0ZW5zaW9ucyBhbGlnbiB3aXRoIENDQU1QJ3MgR01Q
TFMtQVNPTiB3b3JrDQogDQpEaWQgeW91IGhhdmUgYW5vdGhlciBhZGplY3RpdmUgdG8gc3VnZ2Vz
dD8gV2Ugd2VyZSB0aGlua2luZyAic2lnbmlmaWNhbnQiIA0Kd2FzIHJhdGhlciBzb2Z0IGNvbnNp
ZGVyaW5nIHRoZSBhYm92ZS4gVGhvdWdoIGlmIGl0J3MganVzdCBJVFUtc3BlYWsgDQpkaWZmZXJl
bmNlcywgd2h5IGRvZXMgdGhlIE9JRiBsaWFpc29uIHN0YXRlIGl0IHJlZmxlY3RzIHNldmVyYWwg
eWVhcnMgb2YgDQp3b3JrIGluY2x1ZGluZyB0ZXN0aW5nPyBBbnkgaW5zaWdodCAoYWxpZ25tZW50
IG1hcHBpbmcgdG8gQ0NBTVAncyB3b3JrKSANCndoaWNoIHlvdSBvciBMeW5kb24gY2FuIHByb3Zp
ZGUgd291bGQgYmUgaGVscGZ1bC4gVGhlIGRpdmVyZ2VuY2UgaXMgDQpiYWZmbGluZyB0byB1cy4N
CiANCkRlYm9yYWgNCiANCiANCg0KRnJvbTogU2FkbGVyLCBKb25hdGhhbiBCLiBbbWFpbHRvOkpv
bmF0aGFuLlNhZGxlckB0ZWxsYWJzLmNvbV0gDQpTZW50OiBGcmlkYXksIEp1bHkgMjEsIDIwMDYg
MTE6MzQgQU0NClRvOiBCcnVuZ2FyZCwgRGVib3JhaCBBLCBBTEFCUzsgY2NhbXBAb3BzLmlldGYu
b3JnDQpDYzogQWRyaWFuIEZhcnJlbA0KU3ViamVjdDogUkU6IFByb3Bvc2VkIHJlc3BvbnNlIHRv
IE9JRiBvbiBPU1BGIEVOTkkNCkhpIERlYm9yYWggYW5kIEFkcmlhbiwNCiANCkkgaGF2ZW7igJl0
IHNlZW4gbXVjaCBkaXNjdXNzaW9uIG9mIHRoZSBPSUYgRS1OTkkgUm91dGluZyBkb2N1bWVudCBv
biB0aGUgDQpDQ0FNUCBsaXN0LiAgQ2FuIHlvdSB0ZWxsIG1lIHdoYXQgcGFydHMgb2YgdGhlIGRv
Y3VtZW50IGFyZSDigJxzaWduaWZpY2FudCANCm1vZGlmaWNhdGlvbnMgdG8gdGhlIG9wZXJhdGlv
biBvZiBPU1BG4oCdPw0KIA0KVGhhbmtzLA0KIA0KSm9uYXRoYW4gU2FkbGVyDQogDQoNCkZyb206
IG93bmVyLWNjYW1wQG9wcy5pZXRmLm9yZyBbbWFpbHRvOm93bmVyLWNjYW1wQG9wcy5pZXRmLm9y
Z10gT24gQmVoYWxmIA0KT2YgQnJ1bmdhcmQsIERlYm9yYWggQSwgQUxBQlMNClNlbnQ6IEZyaWRh
eSwgSnVseSAyMSwgMjAwNiA5OjM4IEFNDQpUbzogY2NhbXBAb3BzLmlldGYub3JnDQpDYzogQWRy
aWFuIEZhcnJlbA0KU3ViamVjdDogUHJvcG9zZWQgcmVzcG9uc2UgdG8gT0lGIG9uIE9TUEYgRU5O
SQ0KIA0KSGksDQogDQpXZSBoYWQgYSBjb21tdW5pY2F0aW9uIGZyb20gT0lGIG9uIHRoZWlyIE9T
UEYgRU5OSSBzcGVjaWZpY2F0aW9uLiBZb3UgY2FuIA0Kc2VlIHRoZSBvcmlnaW5hbCBmaWxlcyBv
biBodHRwOi8vd3d3Lm9sZGRvZy5jby51ay9jY2FtcC5odG0uIEhhdmluZyANCmFzc2VtYmxlZCBj
b21tZW50cyBmcm9tIHNldmVyYWwgcGVvcGxlIGFuZCBvdXIgZGlzY3Vzc2lvbnMgaW4gTW9udHJl
YWwsIHdlIA0KaGF2ZSBwdXQgdG9nZXRoZXIgdGhlIGZvbGxvd2luZyByZXNwb25zZS4NCiANClBs
ZWFzZSBjb21tZW50IG9uIHRoZSBsaXN0IGluIHRoZSBuZXh0IHdlZWsuDQogDQpUaGFua3MsDQpB
ZHJpYW4gYW5kIERlYm9yYWgNCiANCj0gPSA9ID0gPSA9ID0gPSA9ID0NCkRlYXIgSmltLA0KIA0K
V2UgdGhhbmsgeW91IGZvciBzZW5kaW5nIHVzIHRoZSBPSUYgRU5OSSBkb2N1bWVudCBpbiByZXNw
b25zZSB0byBvdXIgDQpyZXF1ZXN0LiBXaGlsZSB3ZSBhcHByZWNpYXRlIHRoZSBkb2N1bWVudCBi
ZWluZyBwcm92aWRlZCBmb3IgaW5mb3JtYXRpb24sIA0KaXQgaXMgY29uY2VybmluZyB0aGF0IHRo
aXMgZG9jdW1lbnQgaGFzIG5vdCBiZWVuIHByZXZpb3VzbHkgc2hhcmVkIHdpdGggDQpDQ0FNUCBv
ciB0aGUgT1NQRiBXRyBjb25zaWRlcmluZyB0aGUgZG9jdW1lbnQgY29udGFpbnMgc2lnbmlmaWNh
bnQgDQptb2RpZmljYXRpb25zIHRvIHRoZSBvcGVyYXRpb24gb2YgT1NQRiBhbmQgcmVmbGVjdHMg
T0lGIHdvcmsgb3ZlciB0aGUgbGFzdCANCnNldmVyYWwgeWVhcnMuIENDQU1QIGhhcyBiZWVuIHdv
cmtpbmcgb24gR01QTFMgQVNPTiBmb3Igc2V2ZXJhbCB5ZWFycyBhbmQgDQpvdXIgRGVzaWduIFRl
YW1zIGluY2x1ZGUgT0lGIHBhcnRpY2lwYW50cy4gRXZlbiB0aG91Z2ggYSByZXBseSB3YXMgbm90
IA0KcmVxdWVzdGVkLCB3ZSBhcmUgcmVwbHlpbmcsIGFzIHdlIHN0cm9uZ2x5IHJlY29tbWVuZCB0
aGF0IHRoZSBkb2N1bWVudCBub3QgDQpiZSBwdWJsaXNoZWQgZm9yIHB1YmxpYyBpbmZvcm1hdGlv
biBpbiBpdHMgY3VycmVudCBmb3JtLg0KIA0KT2YgbW9zdCBjb25jZXJuIHRvIENDQU1QIGlzIHRo
YXQgaXQgaXMgbm90IGFsaWduZWQgd2l0aCBSRkMgNDI1OCANCihSZXF1aXJlbWVudHMgZm9yIEdl
bmVyYWxpemVkIE11bHRpLVByb3RvY29sIExhYmVsIFN3aXRjaGluZyAoR01QTFMpIA0KUm91dGlu
ZyBmb3IgdGhlIEF1dG9tYXRpY2FsbHkgU3dpdGNoZWQgT3B0aWNhbCBOZXR3b3JrIChBU09OKSkg
b3IgdGhlIA0KdG8tYmUtcHVibGlzaGVkOiANCmZ0cDovL2Z0cC5pc2kuZWR1L2ludGVybmV0LWRy
YWZ0cy9kcmFmdC1pZXRmLWNjYW1wLWdtcGxzLWFzb24tcm91dGluZy1ldmFsLTAzLnR4dA0KLiBD
b25zaWRlcmluZyBub3RhYmxlIE9JRiBwYXJ0aWNpcGFudHMgYXJlIGF1dGhvcnMgb2YgYm90aCB0
aGVzZSBJRVRGIA0KZG9jdW1lbnRzIChhbmQgdGhlIHNhbWUgcGFydGljaXBhbnRzIGFyZSBjb250
cmlidXRvcnMgYW5kIHRoZSBFZGl0b3IgZm9yIA0KdGhlIE9JRiBkb2N1bWVudCksIHRoZSBub24t
YWxpZ25tZW50IGlzIHBlcnBsZXhpbmcuIENvbnNpZGVyaW5nIHRoZSBJRVRGIA0KZG9jdW1lbnQg
aXMgcmVhZHkgZm9yIHB1YmxpY2F0aW9uLCB3ZSBzdWdnZXN0IGluIHRoZSBpbnRlcmVzdHMgb2Yg
dGltZSwgDQp0aGF0IHlvdSBhbGlnbiB5b3VyIGRvY3VtZW50IHdpdGggdGhlIElFVEYgZG9jdW1l
bnQuIElmIGFueSBxdWVzdGlvbnMgb24gDQp0aGUgaW50ZXJwcmV0YXRpb24gb2YgdGhlIElFVEbi
gJlzIHdvcmssIHdlIHJlY29tbWVuZCB0aGF0IHlvdSBlaXRoZXIgDQp1dGlsaXplIHRoZSBDQ0FN
UCBtYWlsIGV4cGxvZGVyIG9yIHNlbmQgYSBjb21tdW5pY2F0aW9uLg0KIA0KU3BlY2lmaWMgY29t
bWVudHMgaW5jbHVkZToNCjEuICAgICAgV2hhdCBpcyB0aGUgaW50ZW50IG9mIHRoaXMgZG9jdW1l
bnQ/IFdpbGwgaXQgYmUgcHVibGlzaGVkIGFzIGFuIA0KSW1wbGVtZW50YXRpb24gQWdyZWVtZW50
IChJQSk/DQpUaGUgdGl0bGUgaW5kaWNhdGVzIGl0IHdpbGwgYmUgYW4gSW1wbGVtZW50YXRpb24g
QWdyZWVtZW50IG9uIEdNUExTIE9TUEYgDQpleHRlbnNpb25zLCBidXQgdGhlIG1haW4gYm9keSBv
ZiB0aGUgZG9jdW1lbnQgaXMgYSBsaXN0IG9mIGlzc3VlcyB3aXRoIA0KR01QTFMgT1NQRi4gRnVy
dGhlciwgeW91ciBjb21tdW5pY2F0aW9uIHRvIHVzIHN0YXRlZCB0aGUgZG9jdW1lbnQgd2FzIA0K
cmVxdWlyZW1lbnRzIG9uIGFuZCB1c2Ugb2YgT1NQRi1URSBhdCB0aGUgRU5OSS4gVGhlc2UgdGhy
ZWUgdmlld3Mgc2VlbSB0byANCmJlIGluY29uc2lzdGVudC4NCjIuICAgICAgVGhlIGxpc3Qgb2Yg
Y2hhbmdlcyBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIChsaXN0ZWQgdW5kZXIgdGhlIA0KVGFi
bGUgb2YgQ29udGVudHMpIGluY2x1ZGVzIOKAnHJlbW92ZWQg4oCcaW50cmEtY2FycmllcuKAnSBs
aW1pdGF0aW9u4oCdIGFuZCB0aGUgDQppbmNsdXNpb24gb2YgRmlndXJlIDEgc2hvd2luZyB0aGUg
T1NQRiBFTk5JIGZvciB1c2UgYmV0d2VlbiB2ZW5kb3IgZG9tYWlucyANCmFuZCBiZXR3ZWVuIGNh
cnJpZXIgZG9tYWlucy4gR01QTFMgT1NQRi1URSBhbHJlYWR5IHN1cHBvcnRzIGludGVyLXZlbmRv
ciANCm9wZXJhdGlvbnMuIA0KVGhlIElFVEbigJlzIEdNUExTIEFTT04gcm91dGluZyBmb2N1cyBo
YXMgYmVlbiBvbiB0aGUgdXNlIG9mIGEgbGluay1zdGF0ZSANCmJhc2VkIHByb3RvY29sIHRvIHN1
cHBvcnQgYSBoaWVyYXJjaGljYWwgcm91dGluZyBhcmNoaXRlY3R1cmUgKEcuNzcxNS4xKSANCndp
dGhpbiBhIGNhcnJpZXLigJlzIGRvbWFpbi4gUmVxdWlyZW1lbnRzIGZvciB1c2luZyBhIGxpbmsg
c3RhdGUgcHJvdG9jb2wgYXMgDQphbiBpbnRlci1kb21haW4gcHJvdG9jb2wgYmV0d2VlbiBjYXJy
aWVycyBhcmUgc2lnbmlmaWNhbnRseSBkaWZmZXJlbnQuIFdlIA0Kc3Ryb25nbHkgZGlzYWdyZWUg
aWYgeW91IGludGVuZCB0byBwdWJsaXNoIHRoaXMgZG9jdW1lbnQgYXMgYW4gDQppbnRlci1jYXJy
aWVyIE9TUEYgRU5OSSBJbXBsZW1lbnRhdGlvbiBBZ3JlZW1lbnQgY2xhaW1pbmcgYWxpZ25tZW50
IHdpdGggDQpJRVRGIFJGQ3Mgd2l0aG91dCByZXZpZXcgKG9yIGFncmVlbWVudCkgYnkgYW55IG9m
IHRoZSBJRVRGIFdvcmtpbmcgR3JvdXBzLg0KMy4gICAgICBTZWN0aW9uIDQuMS9UYWJsZSAxIGFu
ZCB0aGUgc3RhdGVtZW50IHVuZGVyIHRoZSB0YWJsZSBpZGVudGlmeWluZyANCmlzc3VlcyB3aXRo
IEdNUExTIGlkZW50aWZpZXIgbmFtZXNwYWNlcyBhcmUgbm90IGNvcnJlY3QuIEdNUExTIGlkZW50
aWZpZXIgDQpuYW1lc3BhY2VzIGRvIG1lZXQgQVNPTiByZXF1aXJlbWVudHMgZm9yIG5hbWVzcGFj
ZSBzZXBhcmF0aW9uIG9mIHRoZSANCnRyYW5zcG9ydCBwbGFuZSBhbmQgY29udHJvbCBwbGFuZSAo
U2VjdGlvbiA1LjIgYW5kIDUuMy9FdmFsdWF0aW9uKS4gDQpQZXJoYXBzIHlvdSBhcmUgY29uZnVz
aW5nIE9TUEYgYW5kIEdNUExTIE9TUEY/IEFzIHlvdSBhbHNvIGlkZW50aWZpZWQgaW4gDQp5b3Vy
IGxpYWlzb24gdGhhdCB0aGUga2V5IGFyZWEgbmVlZGluZyByZXZpZXcgd2FzIHRoZSBzdXBwb3J0
IG9mIA0KaW5kZXBlbmRlbmNlIG9mIGZ1bmN0aW9uYWwgY29tcG9uZW50IHRvIHBoeXNpY2FsIGxv
Y2F0aW9uLCB0aGlzIGFwcGVhcnMgdG8gDQpiZSBhIGtleSBhcmVhIG9mIG1pc3VuZGVyc3RhbmRp
bmcgb24gR01QTFMuIFdlIHJlY29tbWVuZCByZXZpZXdpbmcgUkZDMzk0NSANCihHTVBMUyBBcmNo
aXRlY3R1cmUpIHRvIHVuZGVyc3RhbmQgdGhhdCB0aGUga2V5IGFyY2hpdGVjdHVyZSBkaWZmZXJl
bmNlIA0KYmV0d2VlbiBHTVBMUyBhbmQgTVBMUyBpcyB0aGUgZGVjb3VwbGluZyBvZiB0aGUgdHJh
bnNwb3J0IHBsYW5lIGFuZCANCmNvbnRyb2wgcGxhbmUuIEFkZGl0aW9uYWxseSwgUkZDNDM5NCwg
UkZDNDM5NywgYW5kIFJGQzQyNTgsIHByb3ZpZGUgYSANCm1hcHBpbmcgdG8gSVRVIHRlcm1pbm9s
b2d5IHdoaWNoIG1heSBiZSBoZWxwZnVsIHJlYWRpbmcuDQogDQpXZSByZXF1ZXN0IGFuIGFkZGl0
aW9uYWwgcm91bmQgb2YgY29tbXVuaWNhdGlvbiBvZiB0aGlzIGRvY3VtZW50IHRvIHRoZSANCklF
VEYgYmVmb3JlIGFwcHJvdmFsIHRvIGFsbG93IHVzIHRvIHdvcmsgd2l0aCB5b3UgdG8gcHJvZHVj
ZSBjb252ZXJnZW5jZSANCmJldHdlZW4gT0lGIGFuZCBJRVRGIHdvcmsgd2hpY2gsIHdlIGJlbGll
dmUsIHdpbGwgYmUgaW4gdGhlIGJlc3QgaW50ZXJlc3RzIA0Kb2YgdGhlIGluZHVzdHJ5Lg0KIA0K
QmVzdCByZWdhcmRzLA0KQWRyaWFuIEZhcnJlbCBhbmQgRGVib3JhaCBCcnVuZ2FyZCwNCkNDQU1Q
IGNvLWNoYWlycw0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09DQpUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWVzc2Fn
ZSBtYXkgYmUgcHJpdmlsZWdlZA0KYW5kIGNvbmZpZGVudGlhbCBhbmQgcHJvdGVjdGVkIGZyb20g
ZGlzY2xvc3VyZS4gSWYgdGhlIHJlYWRlcg0Kb2YgdGhpcyBtZXNzYWdlIGlzIG5vdCB0aGUgaW50
ZW5kZWQgcmVjaXBpZW50LCBvciBhbiBlbXBsb3llZQ0Kb3IgYWdlbnQgcmVzcG9uc2libGUgZm9y
IGRlbGl2ZXJpbmcgdGhpcyBtZXNzYWdlIHRvIHRoZQ0KaW50ZW5kZWQgcmVjaXBpZW50LCB5b3Ug
YXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSByZXByb2R1Y3Rpb24sDQpkaXNzZW1pbmF0aW9u
IG9yIGRpc3RyaWJ1dGlvbiBvZiB0aGlzIGNvbW11bmljYXRpb24gaXMgc3RyaWN0bHkNCnByb2hp
Yml0ZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciwN
CnBsZWFzZSBub3RpZnkgdXMgaW1tZWRpYXRlbHkgYnkgcmVwbHlpbmcgdG8gdGhlIG1lc3NhZ2Ug
YW5kDQpkZWxldGluZyBpdCBmcm9tIHlvdXIgY29tcHV0ZXIuIFRoYW5rIHlvdS4gVGVsbGFicw0K
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09DQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT0NClRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtZXNzYWdlIG1heSBi
ZSBwcml2aWxlZ2VkDQphbmQgY29uZmlkZW50aWFsIGFuZCBwcm90ZWN0ZWQgZnJvbSBkaXNjbG9z
dXJlLiBJZiB0aGUgcmVhZGVyDQpvZiB0aGlzIG1lc3NhZ2UgaXMgbm90IHRoZSBpbnRlbmRlZCBy
ZWNpcGllbnQsIG9yIGFuIGVtcGxveWVlDQpvciBhZ2VudCByZXNwb25zaWJsZSBmb3IgZGVsaXZl
cmluZyB0aGlzIG1lc3NhZ2UgdG8gdGhlDQppbnRlbmRlZCByZWNpcGllbnQsIHlvdSBhcmUgaGVy
ZWJ5IG5vdGlmaWVkIHRoYXQgYW55IHJlcHJvZHVjdGlvbiwNCmRpc3NlbWluYXRpb24gb3IgZGlz
dHJpYnV0aW9uIG9mIHRoaXMgY29tbXVuaWNhdGlvbiBpcyBzdHJpY3RseQ0KcHJvaGliaXRlZC4g
SWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9yLA0KcGxlYXNl
IG5vdGlmeSB1cyBpbW1lZGlhdGVseSBieSByZXBseWluZyB0byB0aGUgbWVzc2FnZSBhbmQNCmRl
bGV0aW5nIGl0IGZyb20geW91ciBjb21wdXRlci4gVGhhbmsgeW91LiBUZWxsYWJzDQo9PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCj09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PQ0KVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1lc3NhZ2UgbWF5IGJlIHByaXZp
bGVnZWQNCmFuZCBjb25maWRlbnRpYWwgYW5kIHByb3RlY3RlZCBmcm9tIGRpc2Nsb3N1cmUuIElm
IHRoZSByZWFkZXINCm9mIHRoaXMgbWVzc2FnZSBpcyBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVu
dCwgb3IgYW4gZW1wbG95ZWUNCm9yIGFnZW50IHJlc3BvbnNpYmxlIGZvciBkZWxpdmVyaW5nIHRo
aXMgbWVzc2FnZSB0byB0aGUNCmludGVuZGVkIHJlY2lwaWVudCwgeW91IGFyZSBoZXJlYnkgbm90
aWZpZWQgdGhhdCBhbnkgcmVwcm9kdWN0aW9uLA0KZGlzc2VtaW5hdGlvbiBvciBkaXN0cmlidXRp
b24gb2YgdGhpcyBjb21tdW5pY2F0aW9uIGlzIHN0cmljdGx5DQpwcm9oaWJpdGVkLiBJZiB5b3Ug
aGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3IsDQpwbGVhc2Ugbm90aWZ5
IHVzIGltbWVkaWF0ZWx5IGJ5IHJlcGx5aW5nIHRvIHRoZSBtZXNzYWdlIGFuZA0KZGVsZXRpbmcg
aXQgZnJvbSB5b3VyIGNvbXB1dGVyLiBUaGFuayB5b3UuIFRlbGxhYnMNCj09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KDQoNCg==

Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 25 Jul 2006 16:56:57 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Proposed response to OIF on OSPF ENNI
Date: Tue, 25 Jul 2006 12:55:35 -0400
Message-ID: <0901D1988E815341A0103206A834DA07F1A24F@mdmxm02.ciena.com>
Thread-Topic: Proposed response to OIF on OSPF ENNI
Thread-Index: Acav07Xd9AD2hBAfTOOJYjyz4Zjr/QAMtcqA
From: "Ong, Lyndon" <Lyong@Ciena.com>
To: <Dimitri.Papadimitriou@alcatel.be>, "Sadler, Jonathan B." <Jonathan.Sadler@tellabs.com>
Cc: "Adrian Farrel" <adrian@olddog.co.uk>, <ccamp@ops.ietf.org>, "Brungard, Deborah A, ALABS" <dbrungard@att.com>, <owner-ccamp@ops.ietf.org>

Hi Dimitri,

I completely agree with you that there is much unnecessary hubbub
going on.  The document does in fact point to IETF (and ITU) for
standard extensions to the routing protocols.

>From the discussion I have the sense that there is some unhappiness with
the
document focusing on requirements that are still in the process of being

addressed within CCAMP, but since it points to the drafts being done
here
if anything it should focus reader's attention on the work here in CCAMP
rather than anywhere else. =20

Cheers,

Lyndon

-----Original Message-----
From: Dimitri.Papadimitriou@alcatel.be
[mailto:Dimitri.Papadimitriou@alcatel.be]=20
Sent: Tuesday, July 25, 2006 3:18 AM
To: Sadler, Jonathan B.; Ong, Lyndon
Cc: Adrian Farrel; ccamp@ops.ietf.org; Brungard, Deborah A, ALABS;
owner-ccamp@ops.ietf.org
Subject: RE: Proposed response to OIF on OSPF ENNI

jonathan & lyndon

o) During Dallas CCAMP meeting, IETF 66, we have had the following
discussion (extracted from the meeting minutes)=20

"Kireeti: What would make me happy is not to have extensions defined in
IAs=20
         Work has been done in the IETF. Instead, we will have objects
in the specs and IAs=20
         Putting the extensions in an informational appendix is still
confusing, especially=20
         as vendors have implemented them for demos=20
         I would prefer that you just point to IETF so as extensions
evolve in the IETF, you=20
         stay coordinated
Jim: We [the OIF] don't think that differently=20
     One of our goals is to align and converge.=20
     We understand we are using experimental codepoints"=20

so, it is rather unclear why there is so much hubub when IETF proposes
to achieve this objective ? if i well understand your opinion is that
IETF should not target this objective ? let's assume this is the case,
it still does not allow OIF to bypass the MPLS-GMPLS change process=20

o) concerning the alignment of IETF vs G.7715 and G.7715.1, from the
IETF liaison webpage you will see that a set of exchanges between bodies
has been conducted to ensure such alignment; however, as ITU should be
defining ASON routing requirements your statement "I cannot say that
they are aligned with the requirements of the OIF" is totally unclear to
me.=20
Does OIF has its own requirements or are OIF requirements not fully
aligned with ITU G.7715/.1 ? This question should be reflected in the
liaison to OIF - as a CLEAR response from OIF will surely help sorting
the present situation=20

o) what is the real "issue" by pointing to the addressing i-d, the
latter just provides recommendation in case of 1:1 corr. between data
and control plane entities; i thought ASON was looking at larger scope -
so what's the point beside trying to mis-use any IETF production to
corroborate the GMPLS OSPF digression of Section 4.1 of the OIF IA ?

o) the tone of the OIF IA is its first sections is totally inappropriate
and misleading - so requires major revision - by reading one got the
impression by reading that a) OIF puts premises of a new protocol
recommendation while also stating it is a demo code reporting for a
single level - this must be seriously revisited b) OIF has apparently
discovered major holes and flaws, while issue is limited to unnumbered
links with overlapping ID space per TE Router ID (as detailed in section
5.7 of the eval doc) - alignment on these aspect(s) is also more than
recommended imho=20

o) at the end, the major concern is that it is totally unclear what the
purpose of the OIF IA OSPF extensions are, if the intention of OIF is to
push them outside OIF demo scope (which seems to be the case since the
document passes through OIF ballot process and thus will be openly
available after this phase), then de-facto it is an OIF dutty to ask
IETF for in-depth revision and full alignment before publication=20

ps: to achieve a standard you need running code, but not any running
code becomes a standard even informational (hopefully);

-d.

"Sadler, Jonathan B." <Jonathan.Sadler@tellabs.com> Sent by:
owner-ccamp@ops.ietf.org
24/07/2006 22:31
=20
        To:     "Brungard, Deborah A, ALABS" <dbrungard@att.com>, "Ong,=20
Lyndon" <Lyong@Ciena.com>, <ccamp@ops.ietf.org>
        cc:     "Adrian Farrel" <adrian@olddog.co.uk>
        Subject:        RE: Proposed response to OIF on OSPF ENNI

Hi Deborah, Lyndon, et al,
=20
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.
=20
Given that:
-          CCAMP has a milestone to publish an ASON routing solution by=20
Nov 2006,=20
-          CCAMP didn't have at the time this was liaised (doesn't have=20
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...
=20
Regards,
=20
Jonathan Sadler
=20

From: Ong, Lyndon [mailto:Lyong@Ciena.com]
Sent: Monday, July 24, 2006 2: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
=20
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
-- 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.
=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 conclusions are no
different.
=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".=20
=20
I think we're experiencing a significant miscommunication...
=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"=20
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]
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:=20
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.      What is the intent of this document? Will it be published as an=20
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=20
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.      Section 4.1/Table 1 and the statement under the table
identifying=20
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).=20
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

Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 25 Jul 2006 16:32:21 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6B007.C45380E0"
Subject: RE: Proposed response to OIF on OSPF ENNI
Date: Tue, 25 Jul 2006 11:28:36 -0500
Message-ID: <A1A52203CA93634BA1748887B9993AEA03034FA9@USNVEX1.tellabs-west.tellabsinc.net>
Thread-Topic: Proposed response to OIF on OSPF ENNI
Thread-Index: Acas0Ha/aYxFikOBS5m873SVRoVJxgAACLxQAAHPZJAAnZ89IAACGznwAAEH8mAAAxLNQAAAS4QQACJG/RAAAkvKMA==
From: "Sadler, Jonathan B." <Jonathan.Sadler@tellabs.com>
To: "Brungard, Deborah A, ALABS" <dbrungard@att.com>, "Ong, Lyndon" <Lyong@Ciena.com>, <ccamp@ops.ietf.org>
Cc: "Adrian Farrel" <adrian@olddog.co.uk>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6B007.C45380E0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="us-ascii"

Hi Deborah,

=20

It seems that your response centers on three topics:

1=2E       The alignment of the IETF architecture/eval documents with the
requirements/architecture of other groups,

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

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

=20

Regarding Topic 1:

=20

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"

=20

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.

=20

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=2E7715.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,=20

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.

=20

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.

=20

Regarding Topic 2:

=20

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.

=20

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?

=20

Regarding Topic 3:

=20

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.

=20

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.

=20

I look forward to reviewing the new liaison text.

=20

Jonathan Sadler

=20

________________________________

From: Brungard, Deborah A, ALABS [mailto:dbrungard@att.com]=20
Sent: Tuesday, July 25, 2006 9:58 AM
To: Sadler, Jonathan B.; Ong, Lyndon; ccamp@ops.ietf.org
Cc: Adrian Farrel
Subject: RE: Proposed response to OIF on OSPF ENNI

=20

Hi Jonathan,

=20

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

=20

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

=20

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.

=20

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.

=20

"Significant" Thanks on the confusion;-)

Deborah

=20

________________________________

From: Sadler, Jonathan B. [mailto:Jonathan.Sadler@tellabs.com]=20
Sent: Monday, July 24, 2006 5:38 PM
To: Brungard, Deborah A, ALABS; Ong, Lyndon; ccamp@ops.ietf.org
Cc: Adrian Farrel
Subject: RE: Proposed response to OIF on OSPF ENNI

Hi Deborah,

=20

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.

=20

Regards,

=20

Jonathan Sadler

=20

________________________________

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

=20

Hi Jonathan,

=20

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.

=20

Thanks,

Deborah

=20

________________________________

From: Sadler, Jonathan B. [mailto:Jonathan.Sadler@tellabs.com]=20
Sent: Monday, July 24, 2006 4:32 PM
To: Brungard, Deborah A, ALABS; Ong, Lyndon; ccamp@ops.ietf.org
Cc: Adrian Farrel
Subject: RE: Proposed response to OIF on OSPF ENNI

Hi Deborah, Lyndon, et al,

=20

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.

=20

Given that:

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

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

=20

Regards,

=20

Jonathan Sadler

=20

________________________________

From: Ong, Lyndon [mailto:Lyong@Ciena.com]=20
Sent: Monday, July 24, 2006 2: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

=20

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

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

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

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

=20

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

=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
<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
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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_01C6B007.C45380E0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset="us-ascii"

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:p=3D"urn:schemas-microsoft-com:office:powerpoint" xmlns:oa=3D"urn:sch=
emas-microsoft-com:office:activation" xmlns:st1=3D"urn:schemas-microsoft-co=
m:office:smarttags" xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]--><o:SmartTagType
 namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" name=3D"State"
 downloadurl=3D"http://www.5iamas-microsoft-com:office:smarttags"/>
<o:SmartTagType namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"City" downloadurl=3D"http://www.5iamas-microsoft-com:office:smartt=
ags"/>
<o:SmartTagType namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"place" downloadurl=3D"http://www.5iantlavalamp.com/"/>
<o:SmartTagType namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"PersonName" downloadurl=3D"http://www.microsoft.com"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:"MS Mincho";
	panose-1:2 2 6 9 4 2 5 8 3 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:"\@MS Mincho";
	panose-1:2 2 6 9 4 2 5 8 3 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:blue;
	text-decoration:underline;}
pre
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
span.EmailStyle18
	{mso-style-type:personal;
	font-family:Arial;
	color:navy;}
span.EmailStyle19
	{mso-style-type:personal;
	font-family:Arial;
	color:navy;}
span.EmailStyle20
	{mso-style-type:personal;
	font-family:Arial;
	color:navy;}
span.EmailStyle21
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 @list l0
	{mso-list-id:384647924;
	mso-list-type:hybrid;
	mso-list-template-ids:1974260290 67698703 67698691 67698693 67698689 67698=
691 67698693 67698689 67698691 67698693;}
@list l0:level1
	{mso-level-tab-stop:21.0pt;
	mso-level-number-position:left;
	margin-left:21.0pt;
	text-indent:-.25in;}
@list l1
	{mso-list-id:743601020;
	mso-list-type:hybrid;
	mso-list-template-ids:1080331530 -1372295434 67698691 67698693 67698689 67=
698691 67698693 67698689 67698691 67698693;}
@list l1:level1
	{mso-level-start-at:12;
	mso-level-number-format:bullet;
	mso-level-text:-;
	mso-level-tab-stop:21.0pt;
	mso-level-number-position:left;
	margin-left:21.0pt;
	text-indent:-.25in;
	font-family:Arial;
	mso-fareast-font-family:"MS Mincho";}
@list l2
	{mso-list-id:1543203313;
	mso-list-type:hybrid;
	mso-list-template-ids:1540399180 -119524184 67698691 67698693 67698689 676=
98691 67698693 67698689 67698691 67698693;}
@list l2:level1
	{mso-level-start-at:12;
	mso-level-number-format:bullet;
	mso-level-text:-;
	mso-level-tab-stop:21.0pt;
	mso-level-number-position:left;
	margin-left:21.0pt;
	text-indent:-.25in;
	font-family:Arial;
	mso-fareast-font-family:"MS Mincho";}
ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dblue>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Hi Deborah,<o:p></o:p></span></font></=
p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>It seems that your response centers on
three topics:<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:21.0pt;text-indent:-.25in;mso-lis=
t:l0 level1 lfo3'><![if !supportLists]><font
size=3D2 color=3Dnavy face=3DArial><span style=3D'font-size:10.0pt;font-fam=
ily:Arial;
color:navy'><span style=3D'mso-list:Ignore'>1.<font size=3D1 face=3D"Times =
New Roman"><span
style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 </span></font></span></span></font><![endif]><font
size=3D2 color=3Dnavy face=3DArial><span style=3D'font-size:10.0pt;font-fam=
ily:Arial;
color:navy'>The alignment of the IETF architecture/eval documents with the =
requirements/architecture
of other groups,<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:21.0pt;text-indent:-.25in;mso-lis=
t:l0 level1 lfo3'><![if !supportLists]><font
size=3D2 color=3Dnavy face=3DArial><span style=3D'font-size:10.0pt;font-fam=
ily:Arial;
color:navy'><span style=3D'mso-list:Ignore'>2.<font size=3D1 face=3D"Times =
New Roman"><span
style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 </span></font></span></span></font><![endif]><font
size=3D2 color=3Dnavy face=3DArial><span style=3D'font-size:10.0pt;font-fam=
ily:Arial;
color:navy'>The OIF <st1:place w:st=3D"on"><st1:City w:st=3D"on">Draft</st1=
:City> <st1:State
 w:st=3D"on">IA</st1:State></st1:place> making statements regarding the
identifiers used by GMPLS routing when carried by OSPF, and<o:p></o:p></spa=
n></font></p>

<p class=3DMsoNormal style=3D'margin-left:21.0pt;text-indent:-.25in;mso-lis=
t:l0 level1 lfo3'><![if !supportLists]><font
size=3D2 color=3Dnavy face=3DArial><span style=3D'font-size:10.0pt;font-fam=
ily:Arial;
color:navy'><span style=3D'mso-list:Ignore'>3.<font size=3D1 face=3D"Times =
New Roman"><span
style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 </span></font></span></span></font><![endif]><font
size=3D2 color=3Dnavy face=3DArial><span style=3D'font-size:10.0pt;font-fam=
ily:Arial;
color:navy'>Whether the participants in the design teams did so in any offi=
cial
capacity on behalf of other groups<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Regarding Topic 1:<o:p></o:p></span></=
font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

=
It&#8217;s
too bad that your exhibit makes my point well &#8211; that the text was NOT
liaised to the ITU for review/agreement prior to sending it for publication=
. &nbsp;If
you look at the liaison you provided:<o:p></o:p>

<p class=3DMsoNormal style=3D'margin-left:27.0pt;text-indent:-9.0pt;mso-lis=
t:l1 level1 lfo1'><![if !supportLists]><font
size=3D2 color=3Dnavy face=3DArial><span style=3D'font-size:10.0pt;font-fam=
ily:Arial;
color:navy'><span style=3D'mso-list:Ignore'>-<font size=3D1 face=3D"Times N=
ew Roman"><span
style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp; </span></font></s=
pan></span></font><![endif]><font
size=3D2 color=3Dnavy face=3DArial><span style=3D'font-size:10.0pt;font-fam=
ily:Arial;
color:navy'>you will see it says &#8220;for information&#8221;, not for act=
ion
meaning there is no intent to find out if it is aligned, and<o:p></o:p></sp=
an></font></p>

<![if !supportLists]>-&nbsp;&nbsp;&nbsp; </s=
pan><![endif]>you will note the email you provided states it was notifying IT=
U of
publication. Witness the specific text:<o:p></o:p>

<p class=3DMsoNormal style=3D'mso-margin-top-alt:0in;margin-right:461.25pt;
margin-bottom:0in;margin-left:.5in;margin-bottom:.0001pt'><font size=3D2
color=3Dnavy face=3DArial><span style=3D'font-size:10.0pt;font-family:Arial;
color:navy'>&#8220;The CCAMP working group is pleased to inform you of the =
_<i><span
style=3D'font-style:italic'>publication</span></i>_ of RFC 4258&quot;<o:p><=
/o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-right:461.25pt'><font size=3D2 color=
=3Dnavy
face=3DArial><span style=3D'font-size:10.0pt;font-family:Arial;color:navy'>=
<o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:9.0pt'><font size=3D2 color=3Dnavy
face=3DArial><span style=3D'font-size:10.0pt;font-family:Arial;color:navy'>=
Again, I
state that the final IETF requirements and IETF evaluation documents were n=
ot
liaised to the ITU for review/agreement, so it is impossible to say if they=
 are
aligned with the OIF requirements.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:9.0pt'><font size=3D2 color=3Dnavy
face=3DArial><span style=3D'font-size:10.0pt;font-family:Arial;color:navy'>=
To remove
any potential receiver confusion what this statement means, let me put in
another way:<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'mso-margin-top-alt:0in;margin-right:461.25pt;
margin-bottom:0in;margin-left:1.5in;margin-bottom:.0001pt;text-indent:-1.0i=
n'><font
size=3D2 color=3Dnavy face=3DArial><span style=3D'font-size:10.0pt;font-fam=
ily:Arial;
color:navy'>WHEREAS,&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the ITU has developed a =
set
of requirements and architecture for ASON routing commonly known as G.8080,
G=2E7715 and G.7715.1, and<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'mso-margin-top-alt:0in;margin-right:461.25pt;
margin-bottom:0in;margin-left:1.5in;margin-bottom:.0001pt;text-indent:-1.0i=
n'><font
size=3D2 color=3Dnavy face=3DArial><span style=3D'font-size:10.0pt;font-fam=
ily:Arial;
color:navy'>WHEREAS,&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the members of the OIF a=
re
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 OI=
F,
and<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'mso-margin-top-alt:0in;margin-right:461.25pt;
margin-bottom:0in;margin-left:1.5in;margin-bottom:.0001pt;text-indent:-1.0i=
n'><font
size=3D2 color=3Dnavy face=3DArial><span style=3D'font-size:10.0pt;font-fam=
ily:Arial;
color:navy'>WHEREAS,&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the IETF has been workin=
g on
documents which purport to be accurate restatements of the requirements and=
 architecture
specified by ITU for ASON routing, and<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'mso-margin-top-alt:0in;margin-right:461.25pt;
margin-bottom:0in;margin-left:1.5in;margin-bottom:.0001pt;text-indent:-1.0i=
n'><font
size=3D2 color=3Dnavy face=3DArial><span style=3D'font-size:10.0pt;font-fam=
ily:Arial;
color:navy'>WHEREAS,&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the final documents of t=
he
IETF have not been liaised to the ITU for the purposes of review or agreeme=
nt prior
to publication, allowing determination that they are accurate restatements,=
 <o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'mso-margin-top-alt:0in;margin-right:461.25pt;
margin-bottom:0in;margin-left:1.5in;margin-bottom:.0001pt;text-indent:-1.0i=
n'><font
size=3D2 color=3Dnavy face=3DArial><span style=3D'font-size:10.0pt;font-fam=
ily:Arial;
color:navy'>THEREFORE,&nbsp;&nbsp; it cannot be said that the documents of =
the IETF
are aligned with the requirements or architecture specified by the ITU, and=
<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'mso-margin-top-alt:0in;margin-right:461.25pt;
margin-bottom:0in;margin-left:1.5in;margin-bottom:.0001pt;text-indent:-1.0i=
n'><font
size=3D2 color=3Dnavy face=3DArial><span style=3D'font-size:10.0pt;font-fam=
ily:Arial;
color:navy'>THEREFORE,&nbsp;&nbsp; it cannot be said that the documents of =
the
IETF are aligned with the requirements or architecture of the OIF.<o:p></o:=
p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

=
Please
be aware the reason that the OIF did NOT restate the ITU Requirements and A=
rchitecture
documents (unlike CCAMP), and instead went on record saying that the ITU
documents were the requirements and architecture documents to be followed w=
as to
REMOVE the possibility of OIF-speak, and support convergence on well-define=
d ITU-speak.
This goes a long way to removing confusion.<o:p></o:p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Regarding Topic 2:<o:p></o:p></span></=
font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

=
The IETF
requirements and evaluation documents don&#8217;t make any specific stateme=
nts
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 &#8211; statements that are based on Section 10 of G.=
8080.
CCAMP has not finished (started?) a document that makes any specific statem=
ents
about OSPF.<o:p></o:p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:9.0pt'><font size=3D2 color=3Dnavy
face=3DArial><span style=3D'font-size:10.0pt;font-family:Arial;color:navy'>=
Again I
ask, wouldn&#8217;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?<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Regarding Topic 3:<o:p></o:p></span></=
font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

=
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. &nbsp;Our participation in the design te=
ams
were not as official representatives of the ITU or OIF.&nbsp; 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 respons=
e=2E&nbsp;
Again, since this was not done, it is unclear if the documents are in
alignment.<o:p></o:p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

=
It
should also be noted that the OIF has been interested in setting up a forma=
l OIF-IETF
liaison relationship to remove this misconception, while CCAMP has prevente=
d it.
&nbsp;It seems that the confusion in the IETF would be lower if the liaison
relationship was formed.&nbsp; Certainly, this level of confusion does not
exist in the ITU where an OIF-ITU liaison relationship has existed for many
years.<o:p></o:p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>I look forward to reviewing the new li=
aison
text.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><st1:PersonName w:st=3D"on"><font size=3D2 color=3Dnavy
 face=3DArial><span style=3D'font-size:10.0pt;font-family:Arial;color:navy'=
>Jonathan
 Sadler</span></font></st1:PersonName><font size=3D2 color=3Dnavy face=3DAr=
ial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p></o:p></span><=
/font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font siz=
e=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span style=3D'font-si=
ze:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'> Brungard,
Deborah A, ALABS [mailto:dbrungard@att.com] <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Tuesday, July 25, 2006=
 9:58
AM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Sadler, Jonathan B.; Ong,
Lyndon; ccamp@ops.ietf.org<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> Adrian Farrel<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: Proposed respon=
se to
OIF on OSPF ENNI</span></font><o:p></o:p></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Hi Jonathan,</span></font><o:p></o:p><=
/p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

I think you meant OIF below, as ITU and
IETF work on ASON has been tightly coordinated e.g. a quick back search:</s=
pan><o:p></o:p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'><a
href=3D"https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=3D=
150">https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=3D150=
</a></span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 color=3Dnavy face=3D"Times New Roman"><=
span
style=3D'font-size:12.0pt;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>This mis-match is always the concern w=
hen
work is duplicated&nbsp;in other groups.For OIF to&nbsp;be progressing&nbsp=
;a
document identifying issues with GMPLS for supporting ASON when already CCA=
MP
has finished their document is not only a misuse of people's time (both in =
OIF
and IETF),</span></font><font size=3D2 color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy'> </span></font><font
size=3D2 color=3Dblue face=3DArial><span style=3D'font-size:10.0pt;font-fam=
ily:Arial;
color:blue'>it also causes confusion in the industry (we now have ITU-speak,
CCAMP-speak, and OIF-speak).</span></font><font size=3D2 color=3Dnavy face=
=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p></o:p></span><=
/font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

As the hope of the CCAMP's ASON Design
Teams was to have a representation of ITU, OIF, and CCAMP (especially consi=
dering
Lyndon is OIF's Liaison to CCAMP (and editor of the OIF document) and you as
chair),&nbsp;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&nbsp;develop standards in&nbsp;alignment =
with
ITU and IETF&nbsp;or CCAMP's ability to develop an ASON solution.</f=
ont><o=
:p></o:p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

We should re-spin the Liaison&nbsp;to
inform OIF that this work has been completed in CCAMP&nbsp;and to&nbsp;requ=
est
that&nbsp;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 agree=
d is
very useful). I'll work on it today, and send later.<o:p></o:p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>&quot;Significant&quot; Thanks on the
confusion;-)</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Deborah</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font siz=
e=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabIndex=3D-1>

</span></font></div>

From:=
=
 Sadler,
Jonathan B. [mailto:Jonathan.Sadler@tellabs.com] 
Sent: Monday, July 24, 2006 =
5:38
PM 
To: Brungard, Deborah A, ALA=
BS;
Ong, Lyndon; ccamp@ops.ietf.org 
Cc: Adrian Farrel 
Subject: RE: Proposed respon=
se to
OIF on OSPF ENNI<o:p></o:p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Hi Deborah,<o:p></o:p></span></font></=
p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

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. &nb=
sp;Since
the final IETF requirements and IETF evaluations documents were never liais=
ed
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.<o:p></o:=
p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Regards,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><st1:PersonName w:st=3D"on"><font size=3D2 color=3Dnavy
 face=3DArial><span style=3D'font-size:10.0pt;font-family:Arial;color:navy'=
>Jonathan
 Sadler</span></font></st1:PersonName><font size=3D2 color=3Dnavy face=3DAr=
ial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p></o:p></span><=
/font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font siz=
e=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabIndex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span style=3D'font-si=
ze:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'> Brungard,
Deborah A, ALABS [mailto:dbrungard@att.com] <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Monday, July 24, 2006 =
4:31
PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Sadler, Jonathan B.; Ong,
Lyndon; ccamp@ops.ietf.org<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> Adrian Farrel<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: Proposed respon=
se to
OIF on OSPF ENNI</span></font><o:p></o:p></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Hi Jonathan,</span></font><o:p></o:p><=
/p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

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&nbsp;want to
ensure that the work is aligned.<o:p></o:p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Thanks,</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Deborah</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font siz=
e=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabIndex=3D-1>

</span></font></div>

From:=
=
 Sadler,
Jonathan B. [mailto:Jonathan.Sadler@tellabs.com] 
Sent: Monday, July 24, 2006 =
4:32
PM 
To: Brungard, Deborah A, ALA=
BS;
Ong, Lyndon; ccamp@ops.ietf.org 
Cc: Adrian Farrel 
Subject: RE: Proposed respon=
se to
OIF on OSPF ENNI<o:p></o:p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Hi Deborah, Lyndon, et al,<o:p></o:p><=
/span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Some additional comments:<o:p></o:p></=
span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;- The hierarchical model discuss=
ed
in the draft IA liaised may be supported without any modifications to
OSPF.&nbsp; As discussed in earlier emails, it can be implemented solely
through the import/export of information described in Appendix I of G.7715.=
<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;- The draft IA also recognizes
namespace issues exist between Router ID and the IP Address that messages a=
re
sent to (ITU calls this the RC PC SCN address).&nbsp; This issue is also
discussed in draft-ietf-ccamp-gmpls-addressing.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Given that:<o:p></o:p></span></font></=
p>

<p class=3DMsoNormal style=3D'margin-left:21.0pt;text-indent:-.25in'><font =
size=3D2
color=3Dnavy face=3DArial><span style=3D'font-size:10.0pt;font-family:Arial;
color:navy'>-</span></font><font size=3D1 color=3Dnavy><span style=3D'font-=
size:7.0pt;
color:navy'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span><=
/font><font
size=3D2 color=3Dnavy face=3DArial><span style=3D'font-size:10.0pt;font-fam=
ily:Arial;
color:navy'>CCAMP has a milestone to publish an ASON routing solution by Nov
2006, <o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:21.0pt;text-indent:-.25in'><font =
size=3D2
color=3Dnavy face=3DArial><span style=3D'font-size:10.0pt;font-family:Arial;
color:navy'>-</span></font><font size=3D1 color=3Dnavy><span style=3D'font-=
size:7.0pt;
color:navy'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span><=
/font><font
size=3D2 color=3Dnavy face=3DArial><span style=3D'font-size:10.0pt;font-fam=
ily:Arial;
color:navy'>CCAMP didn&#8217;t have at the time this was liaised (doesn&#82=
17;t
have today?) a working group document, and<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:21.0pt;text-indent:-.25in'><font =
size=3D2
color=3Dnavy face=3DArial><span style=3D'font-size:10.0pt;font-family:Arial;
color:navy'>-</span></font><font size=3D1 color=3Dnavy><span style=3D'font-=
size:7.0pt;
color:navy'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span><=
/font><font
size=3D2 color=3Dnavy face=3DArial><span style=3D'font-size:10.0pt;font-fam=
ily:Arial;
color:navy'>the draft IA has been successfully implemented by more than a d=
ozen
vendors and interop-tested many times,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>I would expect that we should be looki=
ng
at this as experience/text that could be leveraged...&nbsp; &#8220;Running
code&#8230;&#8221; and all that&#8230;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Regards,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><st1:PersonName w:st=3D"on"><font size=3D2 color=3Dnavy
 face=3DArial><span style=3D'font-size:10.0pt;font-family:Arial;color:navy'=
>Jonathan
 Sadler</span></font></st1:PersonName><font size=3D2 color=3Dnavy face=3DAr=
ial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p></o:p></span><=
/font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font siz=
e=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabIndex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span style=3D'font-si=
ze:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'> Ong, Lyn=
don
[mailto:Lyong@Ciena.com] <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Monday, July 24, 2006 =
2:33
PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Brungard, Deborah A, ALA=
BS;
Sadler, Jonathan B.; ccamp@ops.ietf.org<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> Adrian Farrel<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: Proposed respon=
se to
OIF on OSPF ENNI</span></font><o:p></o:p></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Hi Deborah,</span></font><o:p></o:p></=
p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Here's what I would say&nbsp;is in and=
 not
in the OIF document:</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>-- G.7715, G.7715.1 and the IETF eval =
and
solutions draft all identify a need to support hierarchical</span></font><o=
:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>routing areas for ASON, I am perplexed=
 as
to why this seems to be viewed as a new feature.</span></font><o:p></o:p></=
p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>-- the document does not specify the
domain of usage and leaves this to the carrier.&nbsp; This is no different<=
/span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>from G.7715.1 and IETF drafts that do =
not
explicitly state whether they are used for intra- or inter-domain</span></f=
ont><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>interfaces.</span></font><o:p></o:p></=
p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>-- GMPLS OSPF does not support a 1:N or
N:1 relationship between routing controller and transport</span></font><o:p=
></o:p></p>

node, hence extensions are felt to be
required - and are proposed in the eval solutions draft. The =
<o:p></o:p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>conclusions are no different.</span></=
font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>-- the document does not in fact define
any standard extensions to the protocols, and points to future work</span><=
/font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>in IETF and ITU to provide these.&nbsp;
Therefore I cannot understand where you say &quot;new extensions to</span><=
/font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>OSPF are specified&quot; and &quot;non=
e=2E..align
with the CCAMP's GMPLS-ASON work&quot;.&nbsp; </span></font><o:p></o:p></p>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>I think we're experiencing a significa=
nt
miscommunication...</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Cheers,</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Lyndon</span></font><o:p></o:p></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font siz=
e=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabIndex=3D-1>

</span></font></div>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><b><font size=3D2 face=
=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma;font-weight:bold'>From:</span>=
</font></b><font
size=3D2 face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'>
owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] <b><span
style=3D'font-weight:bold'>On Behalf Of </span></b>Brungard, Deborah A, ALA=
BS<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Monday, July 24, 2006 =
12:15
PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Sadler, Jonathan B.;
ccamp@ops.ietf.org<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> Adrian Farrel<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: Proposed respon=
se to
OIF on OSPF ENNI</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Hi Jonathan, (and Lyndon),</span></fon=
t><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Thanks to both of you for responding.<=
/span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>&quot;Significant&quot; was referencin=
g:</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>- supports&nbsp;a&nbsp;(new) hierarchi=
cal
OSPF model</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>-&nbsp;supports&nbsp;inter-domain
(inter-carrier) OSPF (not supported by today's OSPF)</span></font><o:p></o:=
p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>- identifies namespace issues with GMP=
LS
OSPF which do not exist, and proposes extensions to &quot;fix&quot;</span><=
/font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>- new extensions to OSPF are specified=
</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>- none of the proposed extensions align
with CCAMP's GMPLS-ASON work</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

Did you have another adjective to sugg=
est?
We&nbsp;were thinking&nbsp;&quot;significant&quot; 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.&nbsp;The divergence is&nbsp;baffling to us.<o:p></o:=
p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Deborah</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font siz=
e=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabIndex=3D-1>

</span></font></div>

From:=
=
 Sadler,
Jonathan B. [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<o:p></o:p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Hi Deborah and Adrian,<o:p></o:p></spa=
n></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

I haven&#8217;t seen much discussion of
the OIF E-NNI Routing document on the CCAMP list. &nbsp;Can you tell me what
parts of the document are &#8220;significant modifications to the operation=
 of
OSPF&#8221;?<o:p></o:p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Thanks,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><st1:PersonName w:st=3D"on"><font size=3D2 color=3Dnavy
 face=3DArial><span style=3D'font-size:10.0pt;font-family:Arial;color:navy'=
>Jonathan
 Sadler</span></font></st1:PersonName><font size=3D2 color=3Dnavy face=3DAr=
ial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p></o:p></span><=
/font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font siz=
e=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabIndex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span style=3D'font-si=
ze:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'>
owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] <b><span
style=3D'font-weight:bold'>On Behalf Of </span></b>Brungard, Deborah A, ALA=
BS<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Friday, July 21, 2006 =
9:38
AM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> ccamp@ops.ietf.org<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> Adrian Farrel<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> Proposed response t=
o OIF
on OSPF ENNI</span></font><o:p></o:p></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Hi,</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

We had a communication from OIF on the=
ir
OSPF ENNI specification. You can see the original files on <a
href=3D"http://www.olddog.co.uk/ccamp.htm">http://www.olddog.co.uk/ccamp.=
htm</a>. Having assembled comments from several people and our discuss=
ions
in <st1:place w:st=3D"on"><st1:City w:st=3D"on">Montreal</st1:City></st1:pl=
ace>, we
have put together the following response.<o:p></o:p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Please comment on the list in the next
week.</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Thanks,</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Adrian and Deborah</span></font><o:p><=
/o:p></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>=3D =3D =3D =3D =3D =3D =3D =3D =3D =3D<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>Dear Jim,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

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.<o:p></o:p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

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: <a
href=3D"ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpls-ason-routi=
ng-eval-03.txt">ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpls-as=
on-routing-eval-03.txt</a>.
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&#8217;s work, we recommend that you either utilize the CCAMP mail expl=
oder
or send a communication.<o:p></o:p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>Specific comments include:<o:p></o:p></span></font></p>

1.<=
font
size=3D1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </s=
pan>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></o:p>

<p class=3DMsoNormal style=3D'margin-left:.25in;text-indent:-.25in'><i><font
size=3D3 face=3D"Times New Roman"><span style=3D'font-size:12.0pt;font-styl=
e:italic'>2.</span></font></i><i><font
size=3D1><span style=3D'font-size:7.0pt;font-style:italic'>&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;
</span></font></i>The list of changes from the previous version (listed und=
er
the Table of Contents) includes &#8220;<i><span style=3D'font-style:italic'=
>removed
&#8220;intra-carrier&#8221; limitation</span></i>&#8221; 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. <b=
r>
The IETF&#8217;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&#8217;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.<i><span style=3D'font-style:i=
talic'><o:p></o:p></span></i></p>

3.<=
font
size=3D1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </s=
pan>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.<o:p></o:p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>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.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>Best regards,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><st1:PersonName w:st=3D"on"><font size=3D3 face=3D"Tim=
es New Roman"><span
 style=3D'font-size:12.0pt'>Adrian Farrel</span></font></st1:PersonName> and
Deborah Brungard,<o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>CCAMP co-chairs<o:p></o:p></span></font></p>

</div>

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

<pre>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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
</pre></body>

</html>

------_=_NextPart_001_01C6B007.C45380E0--

Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 25 Jul 2006 16:31:40 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6B007.958BFE22"
Subject: RE: Proposed response to OIF on OSPF ENNI
Date: Tue, 25 Jul 2006 12:30:02 -0400
Message-ID: <0901D1988E815341A0103206A834DA07F1A245@mdmxm02.ciena.com>
Thread-Topic: Proposed response to OIF on OSPF ENNI
Thread-Index: Acas0Ha/aYxFikOBS5m873SVRoVJxgAACLxQAAHPZJAAnZ89IAACGznwAAEH8mAAAxLNQAAAS4QQACJG/RAABILt4A==
From: "Ong, Lyndon" <Lyong@Ciena.com>
To: "Brungard, Deborah A, ALABS" <dbrungard@att.com>, "Sadler, Jonathan B." <Jonathan.Sadler@tellabs.com>, <ccamp@ops.ietf.org>
Cc: "Adrian Farrel" <adrian@olddog.co.uk>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6B007.958BFE22
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Deborah,
=20
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.
=20
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=20
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(
=20
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)=20
and not worry about OIF's "intentions" or "alignment", since=20
a) this is not an IETF document
b) the document specifically points to IETF/ITU for the protocol
standards.=20
=20
Cheers,
=20
Lyndon

________________________________

From: Brungard, Deborah A, ALABS [mailto:dbrungard@att.com]=20
Sent: Tuesday, July 25, 2006 7:58 AM
To: Sadler, Jonathan B.; Ong, Lyndon; ccamp@ops.ietf.org
Cc: Adrian Farrel
Subject: RE: Proposed response to OIF on OSPF ENNI

Hi Jonathan,
=20
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=3D150
=20
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).
=20
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.
=20
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.
=20
"Significant" Thanks on the confusion;-)
Deborah

________________________________

From: Sadler, Jonathan B. [mailto:Jonathan.Sadler@tellabs.com]=20
Sent: Monday, July 24, 2006 5:38 PM
To: Brungard, Deborah A, ALABS; Ong, Lyndon; ccamp@ops.ietf.org
Cc: Adrian Farrel
Subject: RE: Proposed response to OIF on OSPF ENNI

Hi Deborah,

=20

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.

=20

Regards,

=20

Jonathan Sadler

=20

________________________________

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

=20

Hi Jonathan,

=20

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.

=20

Thanks,

Deborah

=20

________________________________

From: Sadler, Jonathan B. [mailto:Jonathan.Sadler@tellabs.com]=20
Sent: Monday, July 24, 2006 4:32 PM
To: Brungard, Deborah A, ALABS; Ong, Lyndon; ccamp@ops.ietf.org
Cc: Adrian Farrel
Subject: RE: Proposed response to OIF on OSPF ENNI

Hi Deborah, Lyndon, et al,

=20

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.

=20

Given that:

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

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

=20

Regards,

=20

Jonathan Sadler

=20

________________________________

From: Ong, Lyndon [mailto:Lyong@Ciena.com]=20
Sent: Monday, July 24, 2006 2: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

=20

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

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

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

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

=20

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

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

=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
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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_01C6B007.958BFE22
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:v =3D=20
"urn:schemas-microsoft-com:vml" xmlns:o =3D=20
"urn:schemas-microsoft-com:office:office" xmlns:w =3D=20
"urn:schemas-microsoft-com:office:word" xmlns:p =3D=20
"urn:schemas-microsoft-com:office:powerpoint" xmlns:oa =3D=20
"urn:schemas-microsoft-com:office:activation" xmlns:st1 =3D=20
"urn:schemas-microsoft-com:office:smarttags"><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.2912" name=3DGENERATOR><!--[if !mso]>
<STYLE>v\:* {
	BEHAVIOR: url(#default#VML)
}
o\:* {
	BEHAVIOR: url(#default#VML)
}
w\:* {
	BEHAVIOR: url(#default#VML)
}
.shape {
	BEHAVIOR: url(#default#VML)
}
</STYLE>
<![endif]--><o:SmartTagType=20
downloadurl=3D"http://www.5iamas-microsoft-com:office:smarttags" =
name=3D"City"=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTagT=
ype><o:SmartTagType=20
downloadurl=3D"http://www.5iantlavalamp.com/" name=3D"place"=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTagT=
ype><o:SmartTagType=20
downloadurl=3D"http://www.microsoft.com" name=3D"PersonName"=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTagT=
ype><!--[if !mso]>
<STYLE>st1\:* {
	BEHAVIOR: url(#default#ieooui)
}
</STYLE>
<![endif]-->
<STYLE>@font-face {
	font-family: MS Mincho;
}
@font-face {
	font-family: Tahoma;
}
@font-face {
	font-family: @MS Mincho;
}
@page Section1 {size: 8.5in 11.0in; margin: 1.0in 1.25in 1.0in 1.25in; }
P.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
LI.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
DIV.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline
}
A:visited {
	COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlinkFollowed {
	COLOR: blue; TEXT-DECORATION: underline
}
PRE {
	FONT-SIZE: 10pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Courier New"
}
SPAN.EmailStyle18 {
	COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal
}
SPAN.EmailStyle19 {
	COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal
}
SPAN.EmailStyle20 {
	COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal-reply
}
DIV.Section1 {
	page: Section1
}
</STYLE>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]--></HEAD>
<BODY lang=3DEN-US vLink=3Dblue link=3Dblue>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D578530016-25072006>Hi Deborah,</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D578530016-25072006></SPAN></FONT>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D578530016-25072006>Just to be clear, as editor of the OIF =
document and=20
co-author of the eval draft, I still believe</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D578530016-25072006>both to be very much in alignment.&nbsp; And, =
of=20
course, the OIF document points directly to</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D578530016-25072006>G.7715.1 as well.&nbsp; There seems to be a =
perception=20
being encouraged that there is some</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D578530016-25072006>sort of misalignment, but this is not true at =

all.</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN=20
class=3D578530016-25072006>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN=20
class=3D578530016-25072006>As to the relative relationships of the =
groups:&nbsp;=20
the eval draft and the</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN=20
class=3D578530016-25072006>solutions draft are both IETF =
documents.&nbsp; They are=20
not OIF or ITU documents, and</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN=20
class=3D578530016-25072006>decisions made in the drafts are IETF =
decisions.&nbsp;=20
Related drafts such as the</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN=20
class=3D578530016-25072006>call signaling draft are not even going to be =
passed=20
through ITU or OIF for either group </DIV>
<DIV dir=3Dltr align=3Dleft><SPAN=20
class=3D578530016-25072006>to review.&nbsp; I can and =
<FONT=20
face=3DArial color=3D#0000ff size=3D2>do disagree with=20
that decision, but my views are treated as those</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN=20
class=3D578530016-25072006>of a single IETF participant =
<FONT=20
face=3DArial color=3D#0000ff size=3D2>with no greater=20
weight than any others' (maybe less :o(</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN=20
class=3D578530016-25072006>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN=20
class=3D578530016-25072006>So please, let's confine ourselves to =
commenting on=20
areas&nbsp;describing GMPLS (esp. the table</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN=20
class=3D578530016-25072006>in 4.1) and identification of&nbsp;technical =
concerns=20
(such as the inter/intra-carrier scope)&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN=20
class=3D578530016-25072006>and not worry about OIF's "intentions" or=20
"alignment"<SPAN=20
class=3D578530016-25072006>, since&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN=20
class=3D578530016-25072006>a) this is not an IETF =
document</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN=20
class=3D578530016-25072006>b) the document specifically points to =
IETF/ITU=20
<SPAN=20
class=3D578530016-25072006>for the protocol =
standards.<FONT=20
face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D578530016-25072006>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN=20
class=3D578530016-25072006>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN=20
class=3D578530016-25072006>Cheers,</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN=20
class=3D578530016-25072006>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN=20
class=3D578530016-25072006>Lyndon</DIV> 
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
<HR tabIndex=3D-1>
From: Brungard, Deborah A, ALABS=20
[mailto:dbrungard@att.com] Sent: Tuesday, July 25, 2006 7:58=20
AM To: Sadler, Jonathan B.; Ong, Lyndon;=20
ccamp@ops.ietf.org Cc: Adrian Farrel Subject: RE: =
Proposed=20
response to OIF on OSPF ENNI </DIV>
<DIV></DIV>
<DIV dir=3Dltr align=3Dleft>Hi Jonathan,</DIV>
<DIV dir=3Dltr align=3Dleft>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft>I think you meant OIF below, as ITU and IETF =
work on ASON=20
has been tightly coordinated e.g. a quick back =
search:</DIV>
<DIV dir=3Dltr align=3Dleft><A=20
href=3D"https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=3D=
150">https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=3D1=
50</A></DIV>
<DIV dir=3Dltr align=3Dleft>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft>This mis-match is always the concern when work =
is=20
duplicated&nbsp;in other groups. For OIF to&nbsp;be progressing&nbsp;a =
document=20
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=20
IETF), it also causes confusion in the industry (we now have ITU-speak,=20
CCAMP-speak, and OIF-speak).</DIV>
<DIV dir=3Dltr align=3Dleft>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft>
<DIV dir=3Dltr align=3Dleft>As the hope of the CCAMP's ASON Design Teams =
was to have a=20
representation of ITU, OIF, and CCAMP (especially considering Lyndon is =
OIF's=20
Liaison to CCAMP (and editor of the OIF document) and you as =
chair),&nbsp;if=20
both of you have difficulty judging the alignment of this document vs. =
ASON=20
requirements and CCAMP's work, then the document is not helping either =
OIF's=20
intention to&nbsp;develop standards in&nbsp;alignment with ITU and =
IETF&nbsp;or=20
CCAMP's ability to develop an ASON solution.</DIV>
<DIV dir=3Dltr align=3Dleft>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN=20
class=3D024435113-25072006>We should re-spin the Liaison<SPAN=20
class=3D024435113-25072006>&nbsp;to inform OIF that this work has been =
completed=20
in CCAMP&nbsp;and to&nbsp;request that&nbsp;OIF's evaluation =
sections be=20
removed and replaced with references to the Evaluation document (vs. =
trying to=20
do multiple-speak which has us all=20
confused) and expand on the comments (Dimitri's mail which Lyndon =
has=20
agreed is very useful). I'll work on it today, and send=20
later.</DIV></DIV>
<DIV dir=3Dltr align=3Dleft>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft>"Significant" Thanks on the=20
confusion;-)</DIV>
<DIV dir=3Dltr align=3Dleft>Deborah</DIV> 
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
<HR tabIndex=3D-1>
From: Sadler, Jonathan B.=20
[mailto:Jonathan.Sadler@tellabs.com] Sent: Monday, July 24, =
2006 5:38=20
PM To: Brungard, Deborah A, ALABS; Ong, Lyndon;=20
ccamp@ops.ietf.org Cc: Adrian Farrel Subject: RE: =
Proposed=20
response to OIF on OSPF ENNI </DIV>
<DIV></DIV>
<DIV class=3DSection1>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Hi=20
Deborah,<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">While I do =
not speak=20
for the OIF, I can say that the members of the OIF are on record (by =
motion) to=20
follow the Requirements and Architecture specified in G.8080, G.7715 and =

G.7715.1. &nbsp;Since the final IETF requirements and IETF evaluations =
documents=20
were never liaised to the ITU for comment/agreement before they were =
sent for=20
publication, I cannot say that they are aligned with the requirements of =
the=20
OIF.<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">Regards,<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p>
<st1:PersonName w:st=3D"on">Jonathan=20
Sadler</st1:PersonName><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p>
<DIV>
<DIV class=3DMsoNormal style=3D"TEXT-ALIGN: center" align=3Dcenter><FONT =

face=3D"Times New Roman" size=3D3>
<HR tabIndex=3D-1 align=3Dcenter width=3D"100%" SIZE=3D2>
</DIV>
<SPAN=20
style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma">From:<FONT=20
face=3DTahoma size=3D2> Brungard,=20
Deborah A, ALABS [mailto:dbrungard@att.com] <SPAN=20
style=3D"FONT-WEIGHT: bold">Sent: Monday, July 24, 2006 4:31=20
PM To: Sadler, =
Jonathan B.;=20
Ong, Lyndon; ccamp@ops.ietf.org <SPAN=20
style=3D"FONT-WEIGHT: bold">Cc: Adrian Farrel <SPAN=20
style=3D"FONT-WEIGHT: bold">Subject: RE: Proposed response to =
OIF on=20
OSPF ENNI<o:p></o:p></DIV>
<SPAN=20
style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Hi=20
Jonathan,<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">I just sent =
mail to=20
Lyndon to ask if he felt CCAMP's work was aligned. From your mail below, =
you do=20
believe that CCAMP's ASON requirements document and evaluation document =
meet the=20
needs of OIF? As the OIF Liaison stated it specified requirements, we=20
do&nbsp;want to ensure that the work is =
aligned.<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
Arial">Thanks,<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
Arial">Deborah<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p>
<DIV class=3DMsoNormal style=3D"TEXT-ALIGN: center" align=3Dcenter><FONT =

face=3D"Times New Roman" size=3D3>
<HR tabIndex=3D-1 align=3Dcenter width=3D"100%" SIZE=3D2>
</DIV>
<SPAN=20
style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma">From:<FONT=20
face=3DTahoma size=3D2> Sadler,=20
Jonathan B. [mailto:Jonathan.Sadler@tellabs.com] <SPAN=20
style=3D"FONT-WEIGHT: bold">Sent: Monday, July 24, 2006 4:32=20
PM To: Brungard, =
Deborah A,=20
ALABS; Ong, Lyndon; ccamp@ops.ietf.org <SPAN=20
style=3D"FONT-WEIGHT: bold">Cc: Adrian Farrel <SPAN=20
style=3D"FONT-WEIGHT: bold">Subject: RE: Proposed response to =
OIF on=20
OSPF ENNI<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Hi Deborah, =
Lyndon, et=20
al,<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Some =
additional=20
comments:<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">&nbsp;- The=20
hierarchical model discussed in the draft IA liaised may be supported =
without=20
any modifications to OSPF.&nbsp; As discussed in earlier emails, it can =
be=20
implemented solely through the import/export of information described in =

Appendix I of G.7715.<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">&nbsp;- The =
draft IA=20
also recognizes namespace issues exist between Router ID and the IP =
Address that=20
messages are sent to (ITU calls this the RC PC SCN address).&nbsp; This =
issue is=20
also discussed in=20
draft-ietf-ccamp-gmpls-addressing.<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Given=20
that:<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal style=3D"MARGIN-LEFT: 21pt; TEXT-INDENT: =
-0.25in"><FONT=20
face=3DArial color=3Dnavy size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">-</SPAN></FONT><FONT=20
color=3Dnavy size=3D1><SPAN=20
style=3D"FONT-SIZE: 7pt; COLOR: =
navy">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></FONT><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">CCAMP has a =
milestone=20
to publish an ASON routing solution by Nov 2006, =
<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal style=3D"MARGIN-LEFT: 21pt; TEXT-INDENT: =
-0.25in"><FONT=20
face=3DArial color=3Dnavy size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">-</SPAN></FONT><FONT=20
color=3Dnavy size=3D1><SPAN=20
style=3D"FONT-SIZE: 7pt; COLOR: =
navy">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></FONT><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">CCAMP =
didn&#8217;t have at=20
the time this was liaised (doesn&#8217;t have today?) a working group =
document,=20
and<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal style=3D"MARGIN-LEFT: 21pt; TEXT-INDENT: =
-0.25in"><FONT=20
face=3DArial color=3Dnavy size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">-</SPAN></FONT><FONT=20
color=3Dnavy size=3D1><SPAN=20
style=3D"FONT-SIZE: 7pt; COLOR: =
navy">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></FONT><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">the draft IA =
has been=20
successfully implemented by more than a dozen vendors and interop-tested =
many=20
times,<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">I would =
expect that we=20
should be looking at this as experience/text that could be =
leveraged...&nbsp;=20
&#8220;Running code&#8230;&#8221; and all =
that&#8230;<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">Regards,<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=3DMsoNormal><st1:PersonName w:st=3D"on"><FONT face=3DArial =
color=3Dnavy=20
size=3D2><SPAN style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">Jonathan=20
Sadler</SPAN></FONT></st1:PersonName><FONT face=3DArial color=3Dnavy =
size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<DIV>
<DIV class=3DMsoNormal style=3D"TEXT-ALIGN: center" align=3Dcenter><FONT =

face=3D"Times New Roman" size=3D3>
<HR tabIndex=3D-1 align=3Dcenter width=3D"100%" SIZE=3D2>
</DIV>
<SPAN=20
style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma">From:<FONT=20
face=3DTahoma size=3D2> Ong,=20
Lyndon [mailto:Lyong@Ciena.com] <SPAN=20
style=3D"FONT-WEIGHT: bold">Sent: Monday, July 24, 2006 2:33=20
PM To: Brungard, =
Deborah A,=20
ALABS; Sadler, Jonathan B.; ccamp@ops.ietf.org <SPAN=20
style=3D"FONT-WEIGHT: bold">Cc: Adrian Farrel <SPAN=20
style=3D"FONT-WEIGHT: bold">Subject: RE: Proposed response to =
OIF on=20
OSPF ENNI<o:p></o:p></DIV>
<SPAN=20
style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Hi=20
Deborah,<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Here's what I =
would=20
say&nbsp;is in and not in the OIF document:<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">-- G.7715, =
G.7715.1 and=20
the IETF eval and solutions draft all identify a need to support=20
hierarchical<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">routing areas =
for ASON,=20
I am perplexed as to why this seems to be viewed as a new=20
feature.<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">-- the =
document does=20
not specify the domain of usage and leaves this to the carrier.&nbsp; =
This is no=20
different<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">from G.7715.1 =
and IETF=20
drafts that do not explicitly state whether they are used for intra- or=20
inter-domain<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
Arial">interfaces.<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">-- GMPLS OSPF =
does not=20
support a 1:N or N:1 relationship between routing controller and=20
transport<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">node, hence =
extensions=20
are felt to be required - and are proposed in the eval solutions draft. =
The=20
<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">conclusions =
are no=20
different.<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">-- the =
document does=20
not in fact define any standard extensions to the protocols, and points =
to=20
future work<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">in IETF and =
ITU to=20
provide these.&nbsp; Therefore I cannot understand where you say "new =
extensions=20
to<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">OSPF are =
specified" and=20
"none...align with the CCAMP's GMPLS-ASON work".&nbsp;=20
<o:p></o:p>
<DIV>
<SPAN=20
style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p></DIV>
<DIV>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">I think we're =

experiencing a significant=20
miscommunication...</SPAN></FONT><o:p></o:p></P></DIV>
<DIV>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p></SPAN></FONT></P></DIV>
<DIV>
<P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
Arial">Cheers,</SPAN></FONT><o:p></o:p></P></DIV>
<DIV>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p></SPAN></FONT></P></DIV>
<DIV>
<P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
Arial">Lyndon</SPAN></FONT><o:p></o:p></P></DIV>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<DIV class=3DMsoNormal style=3D"TEXT-ALIGN: center" align=3Dcenter><FONT =

face=3D"Times New Roman" size=3D3><SPAN style=3D"FONT-SIZE: 12pt">
<HR tabIndex=3D-1 align=3Dcenter width=3D"100%" SIZE=3D2>
</SPAN></FONT></DIV>
<P class=3DMsoNormal style=3D"MARGIN-BOTTOM: 12pt"><B><FONT =
face=3DTahoma size=3D2><SPAN=20
style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma">From:</SPAN></FONT></B><FONT=20
face=3DTahoma size=3D2><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma">=20
owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] <B><SPAN=20
style=3D"FONT-WEIGHT: bold">On Behalf Of </SPAN></B>Brungard, Deborah A, =

ALABS Sent: Monday, =
July 24,=20
2006 12:15 PM To: =
Sadler,=20
Jonathan B.; ccamp@ops.ietf.org <SPAN=20
style=3D"FONT-WEIGHT: bold">Cc: Adrian Farrel <SPAN=20
style=3D"FONT-WEIGHT: bold">Subject: RE: Proposed response to =
OIF on=20
OSPF ENNI<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Hi Jonathan, =
(and=20
Lyndon),<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Thanks to =
both of you=20
for responding.<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">"Significant" =
was=20
referencing:<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">-=20
supports&nbsp;a&nbsp;(new) hierarchical OSPF =
model<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
Arial">-&nbsp;supports&nbsp;inter-domain=20
(inter-carrier) OSPF (not supported by today's=20
OSPF)<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">- identifies =
namespace=20
issues with GMPLS OSPF which do not exist, and proposes extensions to=20
"fix"<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">- new =
extensions to=20
OSPF are specified<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">- none of the =
proposed=20
extensions align with CCAMP's GMPLS-ASON =
work<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Did you have =
another=20
adjective to suggest? We&nbsp;were thinking&nbsp;"significant" was =
rather soft=20
considering the above. Though if it's just ITU-speak differences, why =
does the=20
OIF liaison state it reflects several years of work including testing? =
Any=20
insight (alignment mapping to CCAMP's work) which you or Lyndon can =
provide=20
would be helpful.&nbsp;The divergence is&nbsp;baffling to=20
us.<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
Arial">Deborah<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p>
<DIV class=3DMsoNormal style=3D"TEXT-ALIGN: center" align=3Dcenter><FONT =

face=3D"Times New Roman" size=3D3><SPAN style=3D"FONT-SIZE: 12pt">
<HR tabIndex=3D-1 align=3Dcenter width=3D"100%" SIZE=3D2>
</SPAN></FONT></DIV>
<P class=3DMsoNormal style=3D"MARGIN-BOTTOM: 12pt"><B><FONT =
face=3DTahoma size=3D2><SPAN=20
style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma">From:</SPAN></FONT></B><FONT=20
face=3DTahoma size=3D2><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma"> Sadler,=20
Jonathan B. [mailto:Jonathan.Sadler@tellabs.com] <BR><B><SPAN=20
style=3D"FONT-WEIGHT: bold">Sent:</SPAN></B> Friday, July 21, 2006 11:34 =

AM To: Brungard, =
Deborah A,=20
ALABS; ccamp@ops.ietf.org Cc:=20
Adrian Farrel Subject: RE:=20
Proposed response to OIF on OSPF ENNI<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Hi Deborah =
and=20
Adrian,<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">I =
haven&#8217;t seen much=20
discussion of the OIF E-NNI Routing document on the CCAMP list. =
&nbsp;Can you=20
tell me what parts of the document are &#8220;significant modifications =
to the=20
operation of OSPF&#8221;?<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">Thanks,<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p>
<st1:PersonName w:st=3D"on">Jonathan=20
Sadler</st1:PersonName><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p>
<DIV>
<DIV class=3DMsoNormal style=3D"TEXT-ALIGN: center" align=3Dcenter><FONT =

face=3D"Times New Roman" size=3D3><SPAN style=3D"FONT-SIZE: 12pt">
<HR tabIndex=3D-1 align=3Dcenter width=3D"100%" SIZE=3D2>
</SPAN></FONT></DIV>
<P class=3DMsoNormal><B><FONT face=3DTahoma size=3D2><SPAN=20
style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma">From:</SPAN></FONT></B><FONT=20
face=3DTahoma size=3D2><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma">=20
owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] <B><SPAN=20
style=3D"FONT-WEIGHT: bold">On Behalf Of </SPAN></B>Brungard, Deborah A, =

ALABS<BR><B><SPAN style=3D"FONT-WEIGHT: bold">Sent:</SPAN></B> Friday, =
July 21,=20
2006 9:38 AM<BR><B><SPAN style=3D"FONT-WEIGHT: bold">To:</SPAN></B>=20
ccamp@ops.ietf.org<BR><B><SPAN style=3D"FONT-WEIGHT: =
bold">Cc:</SPAN></B> Adrian=20
Farrel<BR><B><SPAN style=3D"FONT-WEIGHT: bold">Subject:</SPAN></B> =
Proposed=20
response to OIF on OSPF ENNI</SPAN></FONT><o:p></o:p></P></DIV>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
Arial">Hi,</SPAN></FONT><o:p></o:p></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">We had a =
communication=20
from OIF on their OSPF ENNI specification. You can see the original =
files on=20
</SPAN></FONT><A href=3D"http://www.olddog.co.uk/ccamp.htm"><FONT =
face=3DArial=20
size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial">http://www.olddog.co.uk/ccamp.htm</SPAN></FONT></A><FONT=20
face=3DArial color=3Dblue size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">. Having =
assembled=20
comments from several people and our discussions in <st1:place=20
w:st=3D"on"><st1:City w:st=3D"on">Montreal</st1:City></st1:place>, we =
have put=20
together the following response.</SPAN></FONT><o:p></o:p></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p></SPAN></FONT></P>
<DIV>
<P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Please =
comment on the=20
list in the next week.</SPAN></FONT><o:p></o:p></P></DIV>
<DIV>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p></SPAN></FONT></P></DIV>
<DIV>
<P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
Arial">Thanks,</SPAN></FONT><o:p></o:p></P></DIV>
<DIV>
<P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Adrian and=20
Deborah</SPAN></FONT><o:p></o:p></P></DIV>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p></SPAN></FONT></P>
<DIV>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">=3D =3D =3D =3D =3D =3D =3D =3D =3D =
=3D<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">Dear Jim,<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">We thank you for sending us the OIF ENNI =
document in=20
response to our request. While we appreciate the document being provided =
for=20
information, it is concerning that this document has not been previously =
shared=20
with CCAMP or the OSPF WG considering the document contains significant=20
modifications to the operation of OSPF and reflects OIF work over the =
last=20
several years. CCAMP has been working on GMPLS ASON for several years =
and our=20
Design Teams include OIF participants. Even though a reply was not =
requested, we=20
are replying, as we strongly recommend that the document not be =
published for=20
public information in its current form.<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">Of most concern to CCAMP is that it is not =
aligned with=20
RFC 4258 (Requirements for Generalized Multi-Protocol Label Switching =
(GMPLS)=20
Routing for the Automatically Switched Optical Network (ASON)) or the=20
to-be-published: <A=20
href=3D"ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpls-ason-rou=
ting-eval-03.txt">ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpl=
s-ason-routing-eval-03.txt</A>.=20
Considering notable OIF participants are authors of both these IETF =
documents=20
(and the same participants are contributors and the Editor for the OIF=20
document), the non-alignment is perplexing. Considering the IETF =
document is=20
ready for publication, we suggest in the interests of time, that you =
align your=20
document with the IETF document. If any questions on the interpretation =
of the=20
IETF&#8217;s work, we recommend that you either utilize the CCAMP mail =
exploder or=20
send a communication.<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">Specific comments =
include:<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal style=3D"MARGIN-LEFT: 0.25in; TEXT-INDENT: =
-0.25in"><FONT=20
face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">1.</SPAN></FONT><FONT size=3D1><SPAN=20
style=3D"FONT-SIZE: 7pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</SPAN></FONT>What is the=20
intent of this document? Will it be published as an Implementation =
Agreement=20
(IA)?<BR>The title indicates it will be an Implementation Agreement on =
GMPLS=20
OSPF extensions, but the main body of the document is a list of issues =
with=20
GMPLS OSPF. Further, your communication to us stated the document was=20
requirements on and use of OSPF-TE at the ENNI. These three views seem =
to be=20
inconsistent.<o:p></o:p></P>
<P class=3DMsoNormal style=3D"MARGIN-LEFT: 0.25in; TEXT-INDENT: =
-0.25in"><I><FONT=20
face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-STYLE: =
italic">2.</SPAN></FONT></I><I><FONT=20
size=3D1><SPAN=20
style=3D"FONT-SIZE: 7pt; FONT-STYLE: =
italic">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></FONT></I>The list of changes from the previous version (listed =
under=20
the Table of Contents) includes &#8220;<I><SPAN style=3D"FONT-STYLE: =
italic">removed=20
&#8220;intra-carrier&#8221; limitation</SPAN></I>&#8221; and the =
inclusion of Figure 1 showing the=20
OSPF ENNI for use between vendor domains and between carrier domains. =
GMPLS=20
OSPF-TE already supports inter-vendor operations. <BR>The IETF&#8217;s =
GMPLS ASON=20
routing focus has been on the use of a link-state based protocol to =
support a=20
hierarchical routing architecture (G.7715.1) within a carrier&#8217;s =
domain.=20
Requirements for using a link state protocol as an inter-domain protocol =
between=20
carriers are significantly different. We strongly disagree if you intend =
to=20
publish this document as an inter-carrier OSPF ENNI Implementation =
Agreement=20
claiming alignment with IETF RFCs without review (or agreement) by any =
of the=20
IETF Working Groups.<I><SPAN=20
style=3D"FONT-STYLE: italic"><o:p></o:p></SPAN></I></P>
<P class=3DMsoNormal style=3D"MARGIN-LEFT: 0.25in; TEXT-INDENT: =
-0.25in"><FONT=20
face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">3.</SPAN></FONT><FONT size=3D1><SPAN=20
style=3D"FONT-SIZE: 7pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</SPAN></FONT>Section=20
4.1/Table 1 and the statement under the table identifying issues with =
GMPLS=20
identifier namespaces are not correct. GMPLS identifier namespaces do =
meet ASON=20
requirements for namespace separation of the transport plane and control =
plane=20
(Section 5.2 and 5.3/Evaluation). Perhaps you are confusing OSPF and =
GMPLS OSPF?=20
As you also identified in your liaison that the key area needing review =
was the=20
support of independence of functional component to physical location, =
this=20
appears to be a key area of misunderstanding on GMPLS. We recommend =
reviewing=20
RFC3945 (GMPLS Architecture) to understand that the key architecture =
difference=20
between GMPLS and MPLS is the decoupling of the transport plane and =
control=20
plane. Additionally, RFC4394, RFC4397, and RFC4258, provide a mapping to =
ITU=20
terminology which may be helpful reading.<o:p></o:p></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">We request an additional round of =
communication of this=20
document to the IETF before approval to allow us to work with you to =
produce=20
convergence between OIF and IETF work which, we believe, will be in the =
best=20
interests of the industry.<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">Best regards,<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><st1:PersonName w:st=3D"on"><FONT face=3D"Times New =
Roman"=20
size=3D3><SPAN style=3D"FONT-SIZE: 12pt">Adrian=20
Farrel</SPAN></FONT></st1:PersonName> and Deborah =
Brungard,<o:p></o:p></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">CCAMP =
co-chairs<o:p></o:p></SPAN></FONT></P></DIV><PRE><FONT face=3D"Courier =
New" size=3D2><SPAN style=3D"FONT-SIZE: =
10pt">=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<o:p></o:p></SPAN></FONT></PRE><PRE><=
FONT face=3D"Courier New" size=3D2><SPAN style=3D"FONT-SIZE: 10pt">The =
information contained in this message may be =
privileged<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
size=3D2><SPAN style=3D"FONT-SIZE: 10pt">and confidential and protected =
from disclosure. If the reader<o:p></o:p></SPAN></FONT></PRE><PRE><FONT =
face=3D"Courier New" size=3D2><SPAN style=3D"FONT-SIZE: 10pt">of this =
message is not the intended recipient, or an =
employee<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
size=3D2><SPAN style=3D"FONT-SIZE: 10pt">or agent responsible for =
delivering this message to the<o:p></o:p></SPAN></FONT></PRE><PRE><FONT =
face=3D"Courier New" size=3D2><SPAN style=3D"FONT-SIZE: 10pt">intended =
recipient, you are hereby notified that any =
reproduction,<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier =
New" size=3D2><SPAN style=3D"FONT-SIZE: 10pt">dissemination or =
distribution of this communication is =
strictly<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
size=3D2><SPAN style=3D"FONT-SIZE: 10pt">prohibited. If you have =
received this communication in =
error,<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
size=3D2><SPAN style=3D"FONT-SIZE: 10pt">please notify us immediately by =
replying to the message and<o:p></o:p></SPAN></FONT></PRE><PRE><FONT =
face=3D"Courier New" size=3D2><SPAN style=3D"FONT-SIZE: 10pt">deleting =
it from your computer. Thank you. =
Tellabs<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
size=3D2><SPAN style=3D"FONT-SIZE: =
10pt">=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<o:p></o:p></SPAN></FONT></PRE><PRE><=
FONT face=3D"Courier New" size=3D2><SPAN style=3D"FONT-SIZE: =
10pt">=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<o:p></o:p></SPAN></FONT></PRE><PRE><=
FONT face=3D"Courier New" size=3D2><SPAN style=3D"FONT-SIZE: 10pt">The =
information contained in this message may be =
privileged<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
size=3D2><SPAN style=3D"FONT-SIZE: 10pt">and confidential and protected =
from disclosure. If the reader<o:p></o:p></SPAN></FONT></PRE><PRE><FONT =
face=3D"Courier New" size=3D2><SPAN style=3D"FONT-SIZE: 10pt">of this =
message is not the intended recipient, or an =
employee<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
size=3D2><SPAN style=3D"FONT-SIZE: 10pt">or agent responsible for =
delivering this message to the<o:p></o:p></SPAN></FONT></PRE><PRE><FONT =
face=3D"Courier New" size=3D2><SPAN style=3D"FONT-SIZE: 10pt">intended =
recipient, you are hereby notified that any =
reproduction,<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier =
New" size=3D2><SPAN style=3D"FONT-SIZE: 10pt">dissemination or =
distribution of this communication is =
strictly<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
size=3D2><SPAN style=3D"FONT-SIZE: 10pt">prohibited. If you have =
received this communication in =
error,<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
size=3D2><SPAN style=3D"FONT-SIZE: 10pt">please notify us immediately by =
replying to the message and<o:p></o:p></SPAN></FONT></PRE><PRE><FONT =
face=3D"Courier New" size=3D2><SPAN style=3D"FONT-SIZE: 10pt">deleting =
it from your computer. Thank you. =
Tellabs<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
size=3D2><SPAN style=3D"FONT-SIZE: =
10pt">=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<o:p></o:p></SPAN></FONT></PRE></DIV>=
<PRE>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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
</PRE></BODY></HTML>

------_=_NextPart_001_01C6B007.958BFE22--

Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 25 Jul 2006 14:59:55 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6AFFA.C857192F"
Subject: RE: Proposed response to OIF on OSPF ENNI
Date: Tue, 25 Jul 2006 09:58:24 -0500
Message-ID: <449B2580D802A443A923DABF3EAB82AF0C72C3B8@OCCLUST04EVS1.ugd.att.com>
Thread-Topic: Proposed response to OIF on OSPF ENNI
Thread-Index: Acas0Ha/aYxFikOBS5m873SVRoVJxgAACLxQAAHPZJAAnZ89IAACGznwAAEH8mAAAxLNQAAAS4QQACJG/RA=
From: "Brungard, Deborah A, ALABS" <dbrungard@att.com>
To: "Sadler, Jonathan B." <Jonathan.Sadler@tellabs.com>, "Ong, Lyndon" <Lyong@Ciena.com>, <ccamp@ops.ietf.org>
Cc: "Adrian Farrel" <adrian@olddog.co.uk>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6AFFA.C857192F
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Jonathan,
=20
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=3D150
=20
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).
=20
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.
=20
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.
=20
"Significant" Thanks on the confusion;-)
Deborah

________________________________

From: Sadler, Jonathan B. [mailto:Jonathan.Sadler@tellabs.com]=20
Sent: Monday, July 24, 2006 5:38 PM
To: Brungard, Deborah A, ALABS; Ong, Lyndon; ccamp@ops.ietf.org
Cc: Adrian Farrel
Subject: RE: Proposed response to OIF on OSPF ENNI

Hi Deborah,

=20

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.

=20

Regards,

=20

Jonathan Sadler

=20

________________________________

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

=20

Hi Jonathan,

=20

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.

=20

Thanks,

Deborah

=20

________________________________

From: Sadler, Jonathan B. [mailto:Jonathan.Sadler@tellabs.com]=20
Sent: Monday, July 24, 2006 4:32 PM
To: Brungard, Deborah A, ALABS; Ong, Lyndon; ccamp@ops.ietf.org
Cc: Adrian Farrel
Subject: RE: Proposed response to OIF on OSPF ENNI

Hi Deborah, Lyndon, et al,

=20

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.

=20

Given that:

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

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

=20

Regards,

=20

Jonathan Sadler

=20

________________________________

From: Ong, Lyndon [mailto:Lyong@Ciena.com]=20
Sent: Monday, July 24, 2006 2: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

=20

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

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

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

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

=20

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

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

=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
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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_01C6AFFA.C857192F
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:v =3D=20
"urn:schemas-microsoft-com:vml" xmlns:o =3D=20
"urn:schemas-microsoft-com:office:office" xmlns:w =3D=20
"urn:schemas-microsoft-com:office:word" xmlns:p =3D=20
"urn:schemas-microsoft-com:office:powerpoint" xmlns:oa =3D=20
"urn:schemas-microsoft-com:office:activation" xmlns:st1 =3D=20
"urn:schemas-microsoft-com:office:smarttags"><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.2914" name=3DGENERATOR><!--[if !mso]>
<STYLE>v\:* {
	BEHAVIOR: url(#default#VML)
}
o\:* {
	BEHAVIOR: url(#default#VML)
}
w\:* {
	BEHAVIOR: url(#default#VML)
}
.shape {
	BEHAVIOR: url(#default#VML)
}
</STYLE>
<![endif]--><o:SmartTagType=20
downloadurl=3D"http://www.5iamas-microsoft-com:office:smarttags" =
name=3D"City"=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTagT=
ype><o:SmartTagType=20
downloadurl=3D"http://www.5iantlavalamp.com/" name=3D"place"=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTagT=
ype><o:SmartTagType=20
downloadurl=3D"http://www.microsoft.com" name=3D"PersonName"=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTagT=
ype><!--[if !mso]>
<STYLE>st1\:* {
	BEHAVIOR: url(#default#ieooui)
}
</STYLE>
<![endif]-->
<STYLE>@font-face {
	font-family: MS Mincho;
}
@font-face {
	font-family: Tahoma;
}
@font-face {
	font-family: @MS Mincho;
}
@page Section1 {size: 8.5in 11.0in; margin: 1.0in 1.25in 1.0in 1.25in; }
P.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
LI.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
DIV.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline
}
A:visited {
	COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlinkFollowed {
	COLOR: blue; TEXT-DECORATION: underline
}
PRE {
	FONT-SIZE: 10pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Courier New"
}
SPAN.EmailStyle18 {
	COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal
}
SPAN.EmailStyle19 {
	COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal
}
SPAN.EmailStyle20 {
	COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal-reply
}
DIV.Section1 {
	page: Section1
}
</STYLE>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]--></HEAD>
<BODY lang=3DEN-US vLink=3Dblue link=3Dblue>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D024435113-25072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Hi Jonathan,</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D024435113-25072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D024435113-25072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>I think you meant OIF below, as ITU and IETF =
work on ASON=20
has been tightly coordinated e.g. a quick back =
search:</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D024435113-25072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2><A=20
href=3D"https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=3D=
150">https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=3D1=
50</A></FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D024435113-25072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D024435113-25072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>This mis-match is always the concern when work =
is=20
duplicated&nbsp;in other groups. For OIF to&nbsp;be progressing&nbsp;a =
document=20
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=20
IETF), it also causes confusion in the industry (we now have ITU-speak,=20
CCAMP-speak, and OIF-speak).</DIV>
<DIV dir=3Dltr align=3Dleft>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft>
<DIV dir=3Dltr align=3Dleft>As the hope of the CCAMP's ASON Design Teams =
was to have a=20
representation of ITU, OIF, and CCAMP (especially considering Lyndon is =
OIF's=20
Liaison to CCAMP (and editor of the OIF document) and you as =
chair),&nbsp;if=20
both of you have difficulty judging the alignment of this document vs. =
ASON=20
requirements and CCAMP's work, then the document is not helping either =
OIF's=20
intention to&nbsp;develop standards in&nbsp;alignment with ITU and =
IETF&nbsp;or=20
CCAMP's ability to develop an ASON solution.</DIV>
<DIV dir=3Dltr align=3Dleft>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN=20
class=3D024435113-25072006>We should re-spin the Liaison<SPAN=20
class=3D024435113-25072006>&nbsp;to inform OIF that this work has been =
completed=20
in CCAMP&nbsp;and to&nbsp;request that&nbsp;OIF's evaluation =
sections be=20
removed and replaced with references to the Evaluation document (vs. =
trying to=20
do multiple-speak which has us all=20
confused) and expand on the comments (Dimitri's mail which Lyndon =
has=20
agreed is very useful). I'll work on it today, and send=20
later.</DIV></DIV>
<DIV dir=3Dltr align=3Dleft>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft>"Significant" Thanks on the=20
confusion;-)</DIV>
<DIV dir=3Dltr align=3Dleft>Deborah</DIV> 
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
<HR tabIndex=3D-1>
From: Sadler, Jonathan B.=20
[mailto:Jonathan.Sadler@tellabs.com] Sent: Monday, July 24, =
2006 5:38=20
PM To: Brungard, Deborah A, ALABS; Ong, Lyndon;=20
ccamp@ops.ietf.org Cc: Adrian Farrel Subject: RE: =
Proposed=20
response to OIF on OSPF ENNI </DIV>
<DIV></DIV>
<DIV class=3DSection1>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Hi=20
Deborah,<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">While I do =
not speak=20
for the OIF, I can say that the members of the OIF are on record (by =
motion) to=20
follow the Requirements and Architecture specified in G.8080, G.7715 and =

G.7715.1. &nbsp;Since the final IETF requirements and IETF evaluations =
documents=20
were never liaised to the ITU for comment/agreement before they were =
sent for=20
publication, I cannot say that they are aligned with the requirements of =
the=20
OIF.<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">Regards,<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p>
<st1:PersonName w:st=3D"on">Jonathan=20
Sadler</st1:PersonName><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p>
<DIV>
<DIV class=3DMsoNormal style=3D"TEXT-ALIGN: center" align=3Dcenter><FONT =

face=3D"Times New Roman" size=3D3>
<HR tabIndex=3D-1 align=3Dcenter width=3D"100%" SIZE=3D2>
</DIV>
<SPAN=20
style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma">From:<FONT=20
face=3DTahoma size=3D2> Brungard,=20
Deborah A, ALABS [mailto:dbrungard@att.com] <SPAN=20
style=3D"FONT-WEIGHT: bold">Sent: Monday, July 24, 2006 4:31=20
PM To: Sadler, =
Jonathan B.;=20
Ong, Lyndon; ccamp@ops.ietf.org <SPAN=20
style=3D"FONT-WEIGHT: bold">Cc: Adrian Farrel <SPAN=20
style=3D"FONT-WEIGHT: bold">Subject: RE: Proposed response to =
OIF on=20
OSPF ENNI<o:p></o:p></DIV>
<SPAN=20
style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Hi=20
Jonathan,<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">I just sent =
mail to=20
Lyndon to ask if he felt CCAMP's work was aligned. From your mail below, =
you do=20
believe that CCAMP's ASON requirements document and evaluation document =
meet the=20
needs of OIF? As the OIF Liaison stated it specified requirements, we=20
do&nbsp;want to ensure that the work is =
aligned.<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
Arial">Thanks,<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
Arial">Deborah<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p>
<DIV class=3DMsoNormal style=3D"TEXT-ALIGN: center" align=3Dcenter><FONT =

face=3D"Times New Roman" size=3D3>
<HR tabIndex=3D-1 align=3Dcenter width=3D"100%" SIZE=3D2>
</DIV>
<SPAN=20
style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma">From:<FONT=20
face=3DTahoma size=3D2> Sadler,=20
Jonathan B. [mailto:Jonathan.Sadler@tellabs.com] <SPAN=20
style=3D"FONT-WEIGHT: bold">Sent: Monday, July 24, 2006 4:32=20
PM To: Brungard, =
Deborah A,=20
ALABS; Ong, Lyndon; ccamp@ops.ietf.org <SPAN=20
style=3D"FONT-WEIGHT: bold">Cc: Adrian Farrel <SPAN=20
style=3D"FONT-WEIGHT: bold">Subject: RE: Proposed response to =
OIF on=20
OSPF ENNI<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Hi Deborah, =
Lyndon, et=20
al,<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Some =
additional=20
comments:<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">&nbsp;- The=20
hierarchical model discussed in the draft IA liaised may be supported =
without=20
any modifications to OSPF.&nbsp; As discussed in earlier emails, it can =
be=20
implemented solely through the import/export of information described in =

Appendix I of G.7715.<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">&nbsp;- The =
draft IA=20
also recognizes namespace issues exist between Router ID and the IP =
Address that=20
messages are sent to (ITU calls this the RC PC SCN address).&nbsp; This =
issue is=20
also discussed in=20
draft-ietf-ccamp-gmpls-addressing.<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Given=20
that:<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal style=3D"MARGIN-LEFT: 21pt; TEXT-INDENT: =
-0.25in"><FONT=20
face=3DArial color=3Dnavy size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">-</SPAN></FONT><FONT=20
color=3Dnavy size=3D1><SPAN=20
style=3D"FONT-SIZE: 7pt; COLOR: =
navy">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></FONT><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">CCAMP has a =
milestone=20
to publish an ASON routing solution by Nov 2006, =
<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal style=3D"MARGIN-LEFT: 21pt; TEXT-INDENT: =
-0.25in"><FONT=20
face=3DArial color=3Dnavy size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">-</SPAN></FONT><FONT=20
color=3Dnavy size=3D1><SPAN=20
style=3D"FONT-SIZE: 7pt; COLOR: =
navy">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></FONT><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">CCAMP =
didn&#8217;t have at=20
the time this was liaised (doesn&#8217;t have today?) a working group =
document,=20
and<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal style=3D"MARGIN-LEFT: 21pt; TEXT-INDENT: =
-0.25in"><FONT=20
face=3DArial color=3Dnavy size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">-</SPAN></FONT><FONT=20
color=3Dnavy size=3D1><SPAN=20
style=3D"FONT-SIZE: 7pt; COLOR: =
navy">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></FONT><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">the draft IA =
has been=20
successfully implemented by more than a dozen vendors and interop-tested =
many=20
times,<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">I would =
expect that we=20
should be looking at this as experience/text that could be =
leveraged...&nbsp;=20
&#8220;Running code&#8230;&#8221; and all =
that&#8230;<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">Regards,<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=3DMsoNormal><st1:PersonName w:st=3D"on"><FONT face=3DArial =
color=3Dnavy=20
size=3D2><SPAN style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">Jonathan=20
Sadler</SPAN></FONT></st1:PersonName><FONT face=3DArial color=3Dnavy =
size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<DIV>
<DIV class=3DMsoNormal style=3D"TEXT-ALIGN: center" align=3Dcenter><FONT =

face=3D"Times New Roman" size=3D3>
<HR tabIndex=3D-1 align=3Dcenter width=3D"100%" SIZE=3D2>
</DIV>
<SPAN=20
style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma">From:<FONT=20
face=3DTahoma size=3D2> Ong,=20
Lyndon [mailto:Lyong@Ciena.com] <SPAN=20
style=3D"FONT-WEIGHT: bold">Sent: Monday, July 24, 2006 2:33=20
PM To: Brungard, =
Deborah A,=20
ALABS; Sadler, Jonathan B.; ccamp@ops.ietf.org <SPAN=20
style=3D"FONT-WEIGHT: bold">Cc: Adrian Farrel <SPAN=20
style=3D"FONT-WEIGHT: bold">Subject: RE: Proposed response to =
OIF on=20
OSPF ENNI<o:p></o:p></DIV>
<SPAN=20
style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Hi=20
Deborah,<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Here's what I =
would=20
say&nbsp;is in and not in the OIF document:<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">-- G.7715, =
G.7715.1 and=20
the IETF eval and solutions draft all identify a need to support=20
hierarchical<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">routing areas =
for ASON,=20
I am perplexed as to why this seems to be viewed as a new=20
feature.<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">-- the =
document does=20
not specify the domain of usage and leaves this to the carrier.&nbsp; =
This is no=20
different<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">from G.7715.1 =
and IETF=20
drafts that do not explicitly state whether they are used for intra- or=20
inter-domain<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
Arial">interfaces.<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">-- GMPLS OSPF =
does not=20
support a 1:N or N:1 relationship between routing controller and=20
transport<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">node, hence =
extensions=20
are felt to be required - and are proposed in the eval solutions draft. =
The=20
<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">conclusions =
are no=20
different.<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">-- the =
document does=20
not in fact define any standard extensions to the protocols, and points =
to=20
future work<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">in IETF and =
ITU to=20
provide these.&nbsp; Therefore I cannot understand where you say "new =
extensions=20
to<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">OSPF are =
specified" and=20
"none...align with the CCAMP's GMPLS-ASON work".&nbsp;=20
<o:p></o:p>
<DIV>
<SPAN=20
style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p></DIV>
<DIV>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">I think we're =

experiencing a significant=20
miscommunication...</SPAN></FONT><o:p></o:p></P></DIV>
<DIV>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p></SPAN></FONT></P></DIV>
<DIV>
<P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
Arial">Cheers,</SPAN></FONT><o:p></o:p></P></DIV>
<DIV>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p></SPAN></FONT></P></DIV>
<DIV>
<P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
Arial">Lyndon</SPAN></FONT><o:p></o:p></P></DIV>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<DIV class=3DMsoNormal style=3D"TEXT-ALIGN: center" align=3Dcenter><FONT =

face=3D"Times New Roman" size=3D3><SPAN style=3D"FONT-SIZE: 12pt">
<HR tabIndex=3D-1 align=3Dcenter width=3D"100%" SIZE=3D2>
</SPAN></FONT></DIV>
<P class=3DMsoNormal style=3D"MARGIN-BOTTOM: 12pt"><B><FONT =
face=3DTahoma size=3D2><SPAN=20
style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma">From:</SPAN></FONT></B><FONT=20
face=3DTahoma size=3D2><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma">=20
owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] <B><SPAN=20
style=3D"FONT-WEIGHT: bold">On Behalf Of </SPAN></B>Brungard, Deborah A, =

ALABS Sent: Monday, =
July 24,=20
2006 12:15 PM To: =
Sadler,=20
Jonathan B.; ccamp@ops.ietf.org <SPAN=20
style=3D"FONT-WEIGHT: bold">Cc: Adrian Farrel <SPAN=20
style=3D"FONT-WEIGHT: bold">Subject: RE: Proposed response to =
OIF on=20
OSPF ENNI<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Hi Jonathan, =
(and=20
Lyndon),<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Thanks to =
both of you=20
for responding.<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">"Significant" =
was=20
referencing:<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">-=20
supports&nbsp;a&nbsp;(new) hierarchical OSPF =
model<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
Arial">-&nbsp;supports&nbsp;inter-domain=20
(inter-carrier) OSPF (not supported by today's=20
OSPF)<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">- identifies =
namespace=20
issues with GMPLS OSPF which do not exist, and proposes extensions to=20
"fix"<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">- new =
extensions to=20
OSPF are specified<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">- none of the =
proposed=20
extensions align with CCAMP's GMPLS-ASON =
work<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Did you have =
another=20
adjective to suggest? We&nbsp;were thinking&nbsp;"significant" was =
rather soft=20
considering the above. Though if it's just ITU-speak differences, why =
does the=20
OIF liaison state it reflects several years of work including testing? =
Any=20
insight (alignment mapping to CCAMP's work) which you or Lyndon can =
provide=20
would be helpful.&nbsp;The divergence is&nbsp;baffling to=20
us.<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
Arial">Deborah<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p>
<DIV class=3DMsoNormal style=3D"TEXT-ALIGN: center" align=3Dcenter><FONT =

face=3D"Times New Roman" size=3D3><SPAN style=3D"FONT-SIZE: 12pt">
<HR tabIndex=3D-1 align=3Dcenter width=3D"100%" SIZE=3D2>
</SPAN></FONT></DIV>
<P class=3DMsoNormal style=3D"MARGIN-BOTTOM: 12pt"><B><FONT =
face=3DTahoma size=3D2><SPAN=20
style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma">From:</SPAN></FONT></B><FONT=20
face=3DTahoma size=3D2><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma"> Sadler,=20
Jonathan B. [mailto:Jonathan.Sadler@tellabs.com] <BR><B><SPAN=20
style=3D"FONT-WEIGHT: bold">Sent:</SPAN></B> Friday, July 21, 2006 11:34 =

AM To: Brungard, =
Deborah A,=20
ALABS; ccamp@ops.ietf.org Cc:=20
Adrian Farrel Subject: RE:=20
Proposed response to OIF on OSPF ENNI<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Hi Deborah =
and=20
Adrian,<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">I =
haven&#8217;t seen much=20
discussion of the OIF E-NNI Routing document on the CCAMP list. =
&nbsp;Can you=20
tell me what parts of the document are &#8220;significant modifications =
to the=20
operation of OSPF&#8221;?<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">Thanks,<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p>
<st1:PersonName w:st=3D"on">Jonathan=20
Sadler</st1:PersonName><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p>
<DIV>
<DIV class=3DMsoNormal style=3D"TEXT-ALIGN: center" align=3Dcenter><FONT =

face=3D"Times New Roman" size=3D3><SPAN style=3D"FONT-SIZE: 12pt">
<HR tabIndex=3D-1 align=3Dcenter width=3D"100%" SIZE=3D2>
</SPAN></FONT></DIV>
<P class=3DMsoNormal><B><FONT face=3DTahoma size=3D2><SPAN=20
style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma">From:</SPAN></FONT></B><FONT=20
face=3DTahoma size=3D2><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma">=20
owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] <B><SPAN=20
style=3D"FONT-WEIGHT: bold">On Behalf Of </SPAN></B>Brungard, Deborah A, =

ALABS<BR><B><SPAN style=3D"FONT-WEIGHT: bold">Sent:</SPAN></B> Friday, =
July 21,=20
2006 9:38 AM<BR><B><SPAN style=3D"FONT-WEIGHT: bold">To:</SPAN></B>=20
ccamp@ops.ietf.org<BR><B><SPAN style=3D"FONT-WEIGHT: =
bold">Cc:</SPAN></B> Adrian=20
Farrel<BR><B><SPAN style=3D"FONT-WEIGHT: bold">Subject:</SPAN></B> =
Proposed=20
response to OIF on OSPF ENNI</SPAN></FONT><o:p></o:p></P></DIV>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
Arial">Hi,</SPAN></FONT><o:p></o:p></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">We had a =
communication=20
from OIF on their OSPF ENNI specification. You can see the original =
files on=20
</SPAN></FONT><A href=3D"http://www.olddog.co.uk/ccamp.htm"><FONT =
face=3DArial=20
size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial">http://www.olddog.co.uk/ccamp.htm</SPAN></FONT></A><FONT=20
face=3DArial color=3Dblue size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">. Having =
assembled=20
comments from several people and our discussions in <st1:place=20
w:st=3D"on"><st1:City w:st=3D"on">Montreal</st1:City></st1:place>, we =
have put=20
together the following response.</SPAN></FONT><o:p></o:p></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p></SPAN></FONT></P>
<DIV>
<P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Please =
comment on the=20
list in the next week.</SPAN></FONT><o:p></o:p></P></DIV>
<DIV>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p></SPAN></FONT></P></DIV>
<DIV>
<P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
Arial">Thanks,</SPAN></FONT><o:p></o:p></P></DIV>
<DIV>
<P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Adrian and=20
Deborah</SPAN></FONT><o:p></o:p></P></DIV>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p></SPAN></FONT></P>
<DIV>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">=3D =3D =3D =3D =3D =3D =3D =3D =3D =
=3D<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">Dear Jim,<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">We thank you for sending us the OIF ENNI =
document in=20
response to our request. While we appreciate the document being provided =
for=20
information, it is concerning that this document has not been previously =
shared=20
with CCAMP or the OSPF WG considering the document contains significant=20
modifications to the operation of OSPF and reflects OIF work over the =
last=20
several years. CCAMP has been working on GMPLS ASON for several years =
and our=20
Design Teams include OIF participants. Even though a reply was not =
requested, we=20
are replying, as we strongly recommend that the document not be =
published for=20
public information in its current form.<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">Of most concern to CCAMP is that it is not =
aligned with=20
RFC 4258 (Requirements for Generalized Multi-Protocol Label Switching =
(GMPLS)=20
Routing for the Automatically Switched Optical Network (ASON)) or the=20
to-be-published: <A=20
href=3D"ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpls-ason-rou=
ting-eval-03.txt">ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpl=
s-ason-routing-eval-03.txt</A>.=20
Considering notable OIF participants are authors of both these IETF =
documents=20
(and the same participants are contributors and the Editor for the OIF=20
document), the non-alignment is perplexing. Considering the IETF =
document is=20
ready for publication, we suggest in the interests of time, that you =
align your=20
document with the IETF document. If any questions on the interpretation =
of the=20
IETF&#8217;s work, we recommend that you either utilize the CCAMP mail =
exploder or=20
send a communication.<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">Specific comments =
include:<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal style=3D"MARGIN-LEFT: 0.25in; TEXT-INDENT: =
-0.25in"><FONT=20
face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">1.</SPAN></FONT><FONT size=3D1><SPAN=20
style=3D"FONT-SIZE: 7pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</SPAN></FONT>What is the=20
intent of this document? Will it be published as an Implementation =
Agreement=20
(IA)?<BR>The title indicates it will be an Implementation Agreement on =
GMPLS=20
OSPF extensions, but the main body of the document is a list of issues =
with=20
GMPLS OSPF. Further, your communication to us stated the document was=20
requirements on and use of OSPF-TE at the ENNI. These three views seem =
to be=20
inconsistent.<o:p></o:p></P>
<P class=3DMsoNormal style=3D"MARGIN-LEFT: 0.25in; TEXT-INDENT: =
-0.25in"><I><FONT=20
face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-STYLE: =
italic">2.</SPAN></FONT></I><I><FONT=20
size=3D1><SPAN=20
style=3D"FONT-SIZE: 7pt; FONT-STYLE: =
italic">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></FONT></I>The list of changes from the previous version (listed =
under=20
the Table of Contents) includes &#8220;<I><SPAN style=3D"FONT-STYLE: =
italic">removed=20
&#8220;intra-carrier&#8221; limitation</SPAN></I>&#8221; and the =
inclusion of Figure 1 showing the=20
OSPF ENNI for use between vendor domains and between carrier domains. =
GMPLS=20
OSPF-TE already supports inter-vendor operations. <BR>The IETF&#8217;s =
GMPLS ASON=20
routing focus has been on the use of a link-state based protocol to =
support a=20
hierarchical routing architecture (G.7715.1) within a carrier&#8217;s =
domain.=20
Requirements for using a link state protocol as an inter-domain protocol =
between=20
carriers are significantly different. We strongly disagree if you intend =
to=20
publish this document as an inter-carrier OSPF ENNI Implementation =
Agreement=20
claiming alignment with IETF RFCs without review (or agreement) by any =
of the=20
IETF Working Groups.<I><SPAN=20
style=3D"FONT-STYLE: italic"><o:p></o:p></SPAN></I></P>
<P class=3DMsoNormal style=3D"MARGIN-LEFT: 0.25in; TEXT-INDENT: =
-0.25in"><FONT=20
face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">3.</SPAN></FONT><FONT size=3D1><SPAN=20
style=3D"FONT-SIZE: 7pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</SPAN></FONT>Section=20
4.1/Table 1 and the statement under the table identifying issues with =
GMPLS=20
identifier namespaces are not correct. GMPLS identifier namespaces do =
meet ASON=20
requirements for namespace separation of the transport plane and control =
plane=20
(Section 5.2 and 5.3/Evaluation). Perhaps you are confusing OSPF and =
GMPLS OSPF?=20
As you also identified in your liaison that the key area needing review =
was the=20
support of independence of functional component to physical location, =
this=20
appears to be a key area of misunderstanding on GMPLS. We recommend =
reviewing=20
RFC3945 (GMPLS Architecture) to understand that the key architecture =
difference=20
between GMPLS and MPLS is the decoupling of the transport plane and =
control=20
plane. Additionally, RFC4394, RFC4397, and RFC4258, provide a mapping to =
ITU=20
terminology which may be helpful reading.<o:p></o:p></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">We request an additional round of =
communication of this=20
document to the IETF before approval to allow us to work with you to =
produce=20
convergence between OIF and IETF work which, we believe, will be in the =
best=20
interests of the industry.<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">Best regards,<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><st1:PersonName w:st=3D"on"><FONT face=3D"Times New =
Roman"=20
size=3D3><SPAN style=3D"FONT-SIZE: 12pt">Adrian=20
Farrel</SPAN></FONT></st1:PersonName> and Deborah =
Brungard,<o:p></o:p></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">CCAMP =
co-chairs<o:p></o:p></SPAN></FONT></P></DIV><PRE><FONT face=3D"Courier =
New" size=3D2><SPAN style=3D"FONT-SIZE: =
10pt">=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<o:p></o:p></SPAN></FONT></PRE><PRE><=
FONT face=3D"Courier New" size=3D2><SPAN style=3D"FONT-SIZE: 10pt">The =
information contained in this message may be =
privileged<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
size=3D2><SPAN style=3D"FONT-SIZE: 10pt">and confidential and protected =
from disclosure. If the reader<o:p></o:p></SPAN></FONT></PRE><PRE><FONT =
face=3D"Courier New" size=3D2><SPAN style=3D"FONT-SIZE: 10pt">of this =
message is not the intended recipient, or an =
employee<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
size=3D2><SPAN style=3D"FONT-SIZE: 10pt">or agent responsible for =
delivering this message to the<o:p></o:p></SPAN></FONT></PRE><PRE><FONT =
face=3D"Courier New" size=3D2><SPAN style=3D"FONT-SIZE: 10pt">intended =
recipient, you are hereby notified that any =
reproduction,<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier =
New" size=3D2><SPAN style=3D"FONT-SIZE: 10pt">dissemination or =
distribution of this communication is =
strictly<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
size=3D2><SPAN style=3D"FONT-SIZE: 10pt">prohibited. If you have =
received this communication in =
error,<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
size=3D2><SPAN style=3D"FONT-SIZE: 10pt">please notify us immediately by =
replying to the message and<o:p></o:p></SPAN></FONT></PRE><PRE><FONT =
face=3D"Courier New" size=3D2><SPAN style=3D"FONT-SIZE: 10pt">deleting =
it from your computer. Thank you. =
Tellabs<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
size=3D2><SPAN style=3D"FONT-SIZE: =
10pt">=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<o:p></o:p></SPAN></FONT></PRE><PRE><=
FONT face=3D"Courier New" size=3D2><SPAN style=3D"FONT-SIZE: =
10pt">=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<o:p></o:p></SPAN></FONT></PRE><PRE><=
FONT face=3D"Courier New" size=3D2><SPAN style=3D"FONT-SIZE: 10pt">The =
information contained in this message may be =
privileged<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
size=3D2><SPAN style=3D"FONT-SIZE: 10pt">and confidential and protected =
from disclosure. If the reader<o:p></o:p></SPAN></FONT></PRE><PRE><FONT =
face=3D"Courier New" size=3D2><SPAN style=3D"FONT-SIZE: 10pt">of this =
message is not the intended recipient, or an =
employee<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
size=3D2><SPAN style=3D"FONT-SIZE: 10pt">or agent responsible for =
delivering this message to the<o:p></o:p></SPAN></FONT></PRE><PRE><FONT =
face=3D"Courier New" size=3D2><SPAN style=3D"FONT-SIZE: 10pt">intended =
recipient, you are hereby notified that any =
reproduction,<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier =
New" size=3D2><SPAN style=3D"FONT-SIZE: 10pt">dissemination or =
distribution of this communication is =
strictly<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
size=3D2><SPAN style=3D"FONT-SIZE: 10pt">prohibited. If you have =
received this communication in =
error,<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
size=3D2><SPAN style=3D"FONT-SIZE: 10pt">please notify us immediately by =
replying to the message and<o:p></o:p></SPAN></FONT></PRE><PRE><FONT =
face=3D"Courier New" size=3D2><SPAN style=3D"FONT-SIZE: 10pt">deleting =
it from your computer. Thank you. =
Tellabs<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
size=3D2><SPAN style=3D"FONT-SIZE: =
10pt">=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<o:p></o:p></SPAN></FONT></PRE></DIV>=
<PRE>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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
</PRE></BODY></HTML>

------_=_NextPart_001_01C6AFFA.C857192F--

Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 25 Jul 2006 10:49:43 +0000
Message-ID: <080701c6afd7$e52c8f50$0a23fea9@your029b8cecfe>
Reply-To: "Adrian Farrel" <adrian@olddog.co.uk>
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: "Mack-Crane, T. Benjamin" <Ben.Mack-Crane@tellabs.com>
Cc: <ccamp@ops.ietf.org>, "Brungard, Deborah A, ALABS" <dbrungard@att.com>
Subject: Re: Working Group Last Call on draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt
Date: Tue, 25 Jul 2006 11:46:30 +0100
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Hi Ben,

>>> Do the ingress and egress nodes terminate the LSP to be setup?
>>
>> Yes, indeed. Rooted in RFC3031, section 3.15.
>
> Does the "link between the network and the egress node" connect
> directly to the egress node?

I believe that is the model we are building.
Actually, I can see ways to use the same mechanism to solve wider
connectivity pictures (e.g. C-to-C LSPs), but that would be an extended
application, and if it turned out to need additional encodings and
procedures, i think it would be fine.

>>> How is the "link between the network and the egress node"
>>> determined?
>>
>> Good question. Clearly if there is only one such link, we are done.
>> In the case of a "dual-homed" egress, the Link Capability object
>> may report on more than one link.
>
> From your answer it is still not clear HOW the link is determined.
> Is it assumed that the link (or set of links) is directly identified by
> the destination of the call?

I, in my turn, am not quite sure what you mean by "determined" :-)
There are two steps:
1. The call responder can return information on one or more "links
  between the network and the egress"
  To do this, the call responder must determine such appropriate
  links. It would certainly require knowledge of the destination of
  the call, and would need to understand how that call destination
  can be mapped to real connection end-points.
  Now, it could simply return a full list of the available links with
  information about the link capabilities, or it could filter the list
  based on the information on the call request to supply a list of
  links that it knows are suitable. Implementation choice.
2. On receiving a call response, the initiator must determine paths
  for the connections (LSPs) that it will set up. The way that it
  does this is (obviously?) out of scope since it is an algorithmic
  process. However, it can take as input the information about
  the available final links as supplied in the call response.

>> This is, perhaps not abundantly clear, but it is covered by
>> the final paragraph of section 5.3.
>>
>>    This object MAY also be used to exchange more than one bundled
>>    link capability. In this case, the following ordering MUST be
>>    followed: one identifier subobject (Type 1, 2 or 4) MUST be
>>    inserted before any capability subobject (Type 64 or 65) to
>>    which it refers.
>
> Does the term "bundled link" used here have any relation to
> the term "bundled link" defined in RFC 4201?

Yes. But we should not imply that it only applies to bundled links, so we
need to tidy this up a bit.

>>>   This information may allow the ingress node to tailor its
>>>   LSP request to fit those capabilities and to better utilize
>>>   network resources with regard to those capabilities.
>>>
>>> Generally an LSP setup request is generated by a network
>>> operator, who has a particular purpose in mind.  What leeway
>>> does the ingress LSR have to modify this request?
>>
>> I think that this is the difference between LSPs under the
>> parentage of a Call, and LSPs directly controlled by the
>> operator.
>> When an operator requests an LSP directly, you are quite
>> right that there is no scope for the LSR (i.e. the connection
>> controller) to vary the request for the LSP.
>> However, when an operator requests a service, the service
>> is converted into one or more LSP requests. A good example
>> of this might be VCAT.
>> So, when an operator requests a service and a Call is used
>> to coordinate the end points, the Call Controller has some
>> leeway about what Connections (LSPs) it instantiates to
>> satisfy the call.
>>
>>> Generally networks work best when there are uniform means
>>> of providing connectivity between clients of the network.
>>> What kinds of "tailoring" are envisioned?
>>
>> I think that the VCAT example is the best. The ingress may
>> have the ability to generate a whole pile of signals, but the
>> egress may only have the ability to terminate a limited set
>> of signals.
>> You might regard this as choosing between sub-layers, I
>> suppose.
>
> A functional model would help here.

Well, from my own personal point of view, while I think functional modeling
can be a useful tool, I do not see the need for it here.

However, if I put on the CCAMP co-chair hat (for the first time in this
discussion) I would say that if someone wants to produce a functional model
for GMPLS then the working group would be pleased to look at it.

> Are you saying that the ingress (i) can generate different LSP types
> (i.e., different layer network technologies)

Yup. The ingress can choose which adaptation functions to use.

(Note that this is NOT saying that it can mix and match different LSP types
to carry one payload signal.)

> or (ii) can generate a different number of signals (e.g., as in VCAT)

Absolutely, yes.

> or (iii) that the ingress offers different adaptations from
> a client to the LSP(s)?

Yes, again.

>>>  In particular, this may be used to achieve end-to-end spectral
>>>  routing attribute negotiation for signal quality negotiation (such
>>>  as BER) in photonic environments where network edges are
>>>  signal regeneration capable. Similarly, it may be used to
>>>  provide end-to-end spatial routing attribute negotiation in
>>>  multi-area routing environments, in particular, when TE links
>>>  have been bundled based on technology specific attributes.
>>>
>>>What is "end-to-end spectral routing attribute negotiation"?
>>
>> It is a completely ridiculous and over-florid way of saying
>> "end-to-end lambda negotiation for use in transparent optical
>> networks".
>
> OK, but what egress link information is used by the ingress
> in this case?

I guess it would need to exchange the available lambdas that it can
terminate.

And, yes, this is not specified at the moment. All the I-D is doing is
providing the tool kit, not the details of applicability.

>>>What is "end-to-end spatial routing attribute negotiation"?
>>
>> Similarly poor choice of words for "end-to-end port negotiation
>> for use in fiber switching networks".
>
> OK, again what egress link information is used by the ingress in
> this case?

I think that adaptation and switching capabilities would be important here.

But, again, the detailed information awaits someone who is implementing
this. We are just providing the object in which it can be encoded.

>> Thanks for flagging these.
>>
>>>  Call setup may provide a suitable mechanism to exchange
>>>   information for this purpose, although several other possibilities
>>>   exist.
>>>
>>> Just because a mechanism can be defined does not mean that it
>>> should be.
>>> Why is it necessary to define this mechanism, and add complexity
>>> to call control, if another mechanism is required to do the same
>>> thing in cases where call control is not used?
>>
>> Hmmm.
>> Well that is a good question.
>>
>> I guess the answer is:
>> Because the Call control mechanism a good one where this
>> type of information (i.e. access connectivity information such
>> as access addressing) is often exchanged.
>
> What is "access addressing"?  Can you give an example
> use case?

It is the address of an access point (such as an egress outside the network)
where the address is taken from a different address space. You can read more
on this in RFC4208.

>> Maybe more important are:
>> - this mechanism is one that several implementers want to /
>> have implemented.
>
> OK, but why?  There ought to be an explainable technical
> reason.

If you accept that the information needs to be exchanged, then the
discussion is about which mechanism to use. The choice can be between many
mechanisms, but this is the only one that has been put forward. Other
proposals would be welcomed, but in the presence of only one proposal and
the clear support from implementers, the request for technical reasoning for
adopting the solution seems a bit odd to me.

>> - no-one raised any concerns about this mechanism
>> during a couple of years of discussion of this process
>> and during WG last call.
>
> Was there discussion of the technical reasons for this
> feature on the mailing list?  If you can provide a pointer
> I can look at the reasons put forth there.

Why do you believe there should be a discussion of the technical reasons for
a feature on the mailing list/ What is wrong with presenting the solution in
an I-D and allowing those with concerns (for example, those who are
implementing in this area and who believe there is a better solution) to
raise the concerns?

> (BTW, I raised this concern during working group last call;-)

Did you?
Are we still talking about the same thing? That is, the necessity and value
of carrying Link Capabilities on a Call set-up or response message?
I don't see any mention of this in your email of 19th June. In that email
you questioned:
1) Why use a notification message for Call control?
2) Were other (existing) call control protocols considered?
3) The network boundaries and models in sections 4.3 and 7
4) The exclusion of Simultaneous Call and connection establishment.
5) The address model in use.

What exactly are you saying that you raised in the last call discussion? I
assume that you are saying that your concerns with the network boundaries
described in section 4.3 amount to a concern about the mechanisms used to
exchange information about the links that cross those boundaries.

>> It is possible that this is not the best way of achieving this
>> (although it is my favourite), but if other mechanisms exist
>> then (as Yakov fondly says) the market will decide which
>> is the best mechanism.
>
> If other mechanisms must exist, and these can also be used
> in the cases covered by this draft, then adding this mechanism
> doesn't really help.

"If."

If other mechanisms exist that you believe are better, and if your
implementation has shown that they are suitably functional, then I recommend
you bring them forward quickly. In fact, I would go as far as saying that
you have a responsiblity to bring them forward.

> If you could give an example showing where this mechanism
> is needed, that might be enlightening.

Yes?

Let's take a PSC example and use the language of RFC4208.
Suppose that an EN is dual-homed to the network as in the case of the EN in 
the bottom left hand corner of Figure 1 of RFC4208.
Let's suppose that the links to the network have very different delay 
characteristics.
Let's assume that a connection is required to carry delay-sensitive traffic 
across the network to this EN.
A call can be used to coordinate between the end points and to convey the 
service requirements.
The call response can be used to convey a list of suitable links, or the 
link capabilities of all links.
The connection can be routed to achieve the required service level.

Adrian

Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 25 Jul 2006 10:20:09 +0000
To: "Sadler, Jonathan B." <Jonathan.Sadler@tellabs.com>, "Ong, Lyndon" <Lyong@Ciena.com>
Cc: "Adrian Farrel" <adrian@olddog.co.uk>, ccamp@ops.ietf.org, "Brungard, Deborah A, ALABS" <dbrungard@att.com>, owner-ccamp@ops.ietf.org
Subject: RE: Proposed response to OIF on OSPF ENNI
MIME-Version: 1.0
Message-ID: <OFBCC4B723.6DA1E1F4-ONC12571B6.002E5667-C12571B6.0038A01A@netfr.alcatel.fr>
From: Dimitri.Papadimitriou@alcatel.be
Date: Tue, 25 Jul 2006 12:18:29 +0200
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: base64

am9uYXRoYW4gJiBseW5kb24NCg0KbykgRHVyaW5nIERhbGxhcyBDQ0FNUCBtZWV0aW5nLCBJRVRG
IDY2LCB3ZSBoYXZlIGhhZCB0aGUgZm9sbG93aW5nIA0KZGlzY3Vzc2lvbiAoZXh0cmFjdGVkIGZy
b20gdGhlIG1lZXRpbmcgbWludXRlcykgDQoNCiJLaXJlZXRpOiBXaGF0IHdvdWxkIG1ha2UgbWUg
aGFwcHkgaXMgbm90IHRvIGhhdmUgZXh0ZW5zaW9ucyBkZWZpbmVkIGluIA0KSUFzIA0KICAgICAg
ICAgV29yayBoYXMgYmVlbiBkb25lIGluIHRoZSBJRVRGLiBJbnN0ZWFkLCB3ZSB3aWxsIGhhdmUg
b2JqZWN0cyBpbiANCnRoZSBzcGVjcyBhbmQgSUFzIA0KICAgICAgICAgUHV0dGluZyB0aGUgZXh0
ZW5zaW9ucyBpbiBhbiBpbmZvcm1hdGlvbmFsIGFwcGVuZGl4IGlzIHN0aWxsIA0KY29uZnVzaW5n
LCBlc3BlY2lhbGx5IA0KICAgICAgICAgYXMgdmVuZG9ycyBoYXZlIGltcGxlbWVudGVkIHRoZW0g
Zm9yIGRlbW9zIA0KICAgICAgICAgSSB3b3VsZCBwcmVmZXIgdGhhdCB5b3UganVzdCBwb2ludCB0
byBJRVRGIHNvIGFzIGV4dGVuc2lvbnMgDQpldm9sdmUgaW4gdGhlIElFVEYsIHlvdSANCiAgICAg
ICAgIHN0YXkgY29vcmRpbmF0ZWQgDQpKaW06IFdlIFt0aGUgT0lGXSBkb24ndCB0aGluayB0aGF0
IGRpZmZlcmVudGx5IA0KICAgICBPbmUgb2Ygb3VyIGdvYWxzIGlzIHRvIGFsaWduIGFuZCBjb252
ZXJnZS4gDQogICAgIFdlIHVuZGVyc3RhbmQgd2UgYXJlIHVzaW5nIGV4cGVyaW1lbnRhbCBjb2Rl
cG9pbnRzIiANCg0Kc28sIGl0IGlzIHJhdGhlciB1bmNsZWFyIHdoeSB0aGVyZSBpcyBzbyBtdWNo
IGh1YnViIHdoZW4gSUVURiBwcm9wb3NlcyB0byANCmFjaGlldmUgdGhpcyBvYmplY3RpdmUgPyBp
ZiBpIHdlbGwgdW5kZXJzdGFuZCB5b3VyIG9waW5pb24gaXMgdGhhdCBJRVRGIA0Kc2hvdWxkIG5v
dCB0YXJnZXQgdGhpcyBvYmplY3RpdmUgPyBsZXQncyBhc3N1bWUgdGhpcyBpcyB0aGUgY2FzZSwg
aXQgc3RpbGwgDQpkb2VzIG5vdCBhbGxvdyBPSUYgdG8gYnlwYXNzIHRoZSBNUExTLUdNUExTIGNo
YW5nZSBwcm9jZXNzIA0KDQpvKSBjb25jZXJuaW5nIHRoZSBhbGlnbm1lbnQgb2YgSUVURiB2cyBH
Ljc3MTUgYW5kIEcuNzcxNS4xLCBmcm9tIHRoZSBJRVRGIA0KbGlhaXNvbiB3ZWJwYWdlIHlvdSB3
aWxsIHNlZSB0aGF0IGEgc2V0IG9mIGV4Y2hhbmdlcyBiZXR3ZWVuIGJvZGllcyBoYXMgDQpiZWVu
IGNvbmR1Y3RlZCB0byBlbnN1cmUgc3VjaCBhbGlnbm1lbnQ7IGhvd2V2ZXIsIGFzIElUVSBzaG91
bGQgYmUgDQpkZWZpbmluZyBBU09OIHJvdXRpbmcgcmVxdWlyZW1lbnRzIHlvdXIgc3RhdGVtZW50
ICJJIGNhbm5vdCBzYXkgdGhhdCB0aGV5IA0KYXJlIGFsaWduZWQgd2l0aCB0aGUgcmVxdWlyZW1l
bnRzIG9mIHRoZSBPSUYiIGlzIHRvdGFsbHkgdW5jbGVhciB0byBtZS4gDQpEb2VzIE9JRiBoYXMg
aXRzIG93biByZXF1aXJlbWVudHMgb3IgYXJlIE9JRiByZXF1aXJlbWVudHMgbm90IGZ1bGx5IA0K
YWxpZ25lZCB3aXRoIElUVSBHLjc3MTUvLjEgPyBUaGlzIHF1ZXN0aW9uIHNob3VsZCBiZSByZWZs
ZWN0ZWQgaW4gdGhlIA0KbGlhaXNvbiB0byBPSUYgLSBhcyBhIENMRUFSIHJlc3BvbnNlIGZyb20g
T0lGIHdpbGwgc3VyZWx5IGhlbHAgc29ydGluZyB0aGUgDQpwcmVzZW50IHNpdHVhdGlvbiANCg0K
bykgd2hhdCBpcyB0aGUgcmVhbCAiaXNzdWUiIGJ5IHBvaW50aW5nIHRvIHRoZSBhZGRyZXNzaW5n
IGktZCwgdGhlIGxhdHRlciANCmp1c3QgcHJvdmlkZXMgcmVjb21tZW5kYXRpb24gaW4gY2FzZSBv
ZiAxOjEgY29yci4gYmV0d2VlbiBkYXRhIGFuZCBjb250cm9sIA0KcGxhbmUgZW50aXRpZXM7IGkg
dGhvdWdodCBBU09OIHdhcyBsb29raW5nIGF0IGxhcmdlciBzY29wZSAtIHNvIHdoYXQncyB0aGUg
DQpwb2ludCBiZXNpZGUgdHJ5aW5nIHRvIG1pcy11c2UgYW55IElFVEYgcHJvZHVjdGlvbiB0byBj
b3Jyb2JvcmF0ZSB0aGUgDQpHTVBMUyBPU1BGIGRpZ3Jlc3Npb24gb2YgU2VjdGlvbiA0LjEgb2Yg
dGhlIE9JRiBJQSA/DQoNCm8pIHRoZSB0b25lIG9mIHRoZSBPSUYgSUEgaXMgaXRzIGZpcnN0IHNl
Y3Rpb25zIGlzIHRvdGFsbHkgaW5hcHByb3ByaWF0ZSANCmFuZCBtaXNsZWFkaW5nIC0gc28gcmVx
dWlyZXMgbWFqb3IgcmV2aXNpb24gLSBieSByZWFkaW5nIG9uZSBnb3QgdGhlIA0KaW1wcmVzc2lv
biBieSByZWFkaW5nIHRoYXQgYSkgT0lGIHB1dHMgcHJlbWlzZXMgb2YgYSBuZXcgcHJvdG9jb2wg
DQpyZWNvbW1lbmRhdGlvbiB3aGlsZSBhbHNvIHN0YXRpbmcgaXQgaXMgYSBkZW1vIGNvZGUgcmVw
b3J0aW5nIGZvciBhIHNpbmdsZSANCmxldmVsIC0gdGhpcyBtdXN0IGJlIHNlcmlvdXNseSByZXZp
c2l0ZWQgYikgT0lGIGhhcyBhcHBhcmVudGx5IGRpc2NvdmVyZWQgDQptYWpvciBob2xlcyBhbmQg
Zmxhd3MsIHdoaWxlIGlzc3VlIGlzIGxpbWl0ZWQgdG8gdW5udW1iZXJlZCBsaW5rcyB3aXRoIA0K
b3ZlcmxhcHBpbmcgSUQgc3BhY2UgcGVyIFRFIFJvdXRlciBJRCAoYXMgZGV0YWlsZWQgaW4gc2Vj
dGlvbiA1Ljcgb2YgdGhlIA0KZXZhbCBkb2MpIC0gYWxpZ25tZW50IG9uIHRoZXNlIGFzcGVjdChz
KSBpcyBhbHNvIG1vcmUgdGhhbiByZWNvbW1lbmRlZCANCmltaG8gDQoNCm8pIGF0IHRoZSBlbmQs
IHRoZSBtYWpvciBjb25jZXJuIGlzIHRoYXQgaXQgaXMgdG90YWxseSB1bmNsZWFyIHdoYXQgdGhl
IA0KcHVycG9zZSBvZiB0aGUgT0lGIElBIE9TUEYgZXh0ZW5zaW9ucyBhcmUsIGlmIHRoZSBpbnRl
bnRpb24gb2YgT0lGIGlzIHRvIA0KcHVzaCB0aGVtIG91dHNpZGUgT0lGIGRlbW8gc2NvcGUgKHdo
aWNoIHNlZW1zIHRvIGJlIHRoZSBjYXNlIHNpbmNlIHRoZSANCmRvY3VtZW50IHBhc3NlcyB0aHJv
dWdoIE9JRiBiYWxsb3QgcHJvY2VzcyBhbmQgdGh1cyB3aWxsIGJlIG9wZW5seSANCmF2YWlsYWJs
ZSBhZnRlciB0aGlzIHBoYXNlKSwgdGhlbiBkZS1mYWN0byBpdCBpcyBhbiBPSUYgZHV0dHkgdG8g
YXNrIElFVEYgDQpmb3IgaW4tZGVwdGggcmV2aXNpb24gYW5kIGZ1bGwgYWxpZ25tZW50IGJlZm9y
ZSBwdWJsaWNhdGlvbiANCg0KcHM6IHRvIGFjaGlldmUgYSBzdGFuZGFyZCB5b3UgbmVlZCBydW5u
aW5nIGNvZGUsIGJ1dCBub3QgYW55IHJ1bm5pbmcgY29kZSANCmJlY29tZXMgYSBzdGFuZGFyZCBl
dmVuIGluZm9ybWF0aW9uYWwgKGhvcGVmdWxseSk7DQoNCi1kLg0KDQoNCg0KDQoNCiJTYWRsZXIs
IEpvbmF0aGFuIEIuIiA8Sm9uYXRoYW4uU2FkbGVyQHRlbGxhYnMuY29tPg0KU2VudCBieTogb3du
ZXItY2NhbXBAb3BzLmlldGYub3JnDQoyNC8wNy8yMDA2IDIyOjMxDQogDQogICAgICAgIFRvOiAg
ICAgIkJydW5nYXJkLCBEZWJvcmFoIEEsIEFMQUJTIiA8ZGJydW5nYXJkQGF0dC5jb20+LCAiT25n
LCANCkx5bmRvbiIgPEx5b25nQENpZW5hLmNvbT4sIDxjY2FtcEBvcHMuaWV0Zi5vcmc+DQogICAg
ICAgIGNjOiAgICAgIkFkcmlhbiBGYXJyZWwiIDxhZHJpYW5Ab2xkZG9nLmNvLnVrPg0KICAgICAg
ICBTdWJqZWN0OiAgICAgICAgUkU6IFByb3Bvc2VkIHJlc3BvbnNlIHRvIE9JRiBvbiBPU1BGIEVO
TkkNCg0KDQpIaSBEZWJvcmFoLCBMeW5kb24sIGV0IGFsLA0KIA0KU29tZSBhZGRpdGlvbmFsIGNv
bW1lbnRzOg0KIC0gVGhlIGhpZXJhcmNoaWNhbCBtb2RlbCBkaXNjdXNzZWQgaW4gdGhlIGRyYWZ0
IElBIGxpYWlzZWQgbWF5IGJlIA0Kc3VwcG9ydGVkIHdpdGhvdXQgYW55IG1vZGlmaWNhdGlvbnMg
dG8gT1NQRi4gIEFzIGRpc2N1c3NlZCBpbiBlYXJsaWVyIA0KZW1haWxzLCBpdCBjYW4gYmUgaW1w
bGVtZW50ZWQgc29sZWx5IHRocm91Z2ggdGhlIGltcG9ydC9leHBvcnQgb2YgDQppbmZvcm1hdGlv
biBkZXNjcmliZWQgaW4gQXBwZW5kaXggSSBvZiBHLjc3MTUuDQogLSBUaGUgZHJhZnQgSUEgYWxz
byByZWNvZ25pemVzIG5hbWVzcGFjZSBpc3N1ZXMgZXhpc3QgYmV0d2VlbiBSb3V0ZXIgSUQgDQph
bmQgdGhlIElQIEFkZHJlc3MgdGhhdCBtZXNzYWdlcyBhcmUgc2VudCB0byAoSVRVIGNhbGxzIHRo
aXMgdGhlIFJDIFBDIFNDTiANCmFkZHJlc3MpLiAgVGhpcyBpc3N1ZSBpcyBhbHNvIGRpc2N1c3Nl
ZCBpbiANCmRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtYWRkcmVzc2luZy4NCiANCkdpdmVuIHRoYXQ6
DQotICAgICAgICAgIENDQU1QIGhhcyBhIG1pbGVzdG9uZSB0byBwdWJsaXNoIGFuIEFTT04gcm91
dGluZyBzb2x1dGlvbiBieSANCk5vdiAyMDA2LCANCi0gICAgICAgICAgQ0NBTVAgZGlkbuKAmXQg
aGF2ZSBhdCB0aGUgdGltZSB0aGlzIHdhcyBsaWFpc2VkIChkb2VzbuKAmXQgaGF2ZSANCnRvZGF5
PykgYSB3b3JraW5nIGdyb3VwIGRvY3VtZW50LCBhbmQNCi0gICAgICAgICAgdGhlIGRyYWZ0IElB
IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBpbXBsZW1lbnRlZCBieSBtb3JlIHRoYW4gYSANCmRvemVu
IHZlbmRvcnMgYW5kIGludGVyb3AtdGVzdGVkIG1hbnkgdGltZXMsDQpJIHdvdWxkIGV4cGVjdCB0
aGF0IHdlIHNob3VsZCBiZSBsb29raW5nIGF0IHRoaXMgYXMgZXhwZXJpZW5jZS90ZXh0IHRoYXQg
DQpjb3VsZCBiZSBsZXZlcmFnZWQuLi4gIOKAnFJ1bm5pbmcgY29kZeKApuKAnSBhbmQgYWxsIHRo
YXTigKYNCiANClJlZ2FyZHMsDQogDQpKb25hdGhhbiBTYWRsZXINCiANCg0KRnJvbTogT25nLCBM
eW5kb24gW21haWx0bzpMeW9uZ0BDaWVuYS5jb21dIA0KU2VudDogTW9uZGF5LCBKdWx5IDI0LCAy
MDA2IDI6MzMgUE0NClRvOiBCcnVuZ2FyZCwgRGVib3JhaCBBLCBBTEFCUzsgU2FkbGVyLCBKb25h
dGhhbiBCLjsgY2NhbXBAb3BzLmlldGYub3JnDQpDYzogQWRyaWFuIEZhcnJlbA0KU3ViamVjdDog
UkU6IFByb3Bvc2VkIHJlc3BvbnNlIHRvIE9JRiBvbiBPU1BGIEVOTkkNCiANCkhpIERlYm9yYWgs
DQogDQpIZXJlJ3Mgd2hhdCBJIHdvdWxkIHNheSBpcyBpbiBhbmQgbm90IGluIHRoZSBPSUYgZG9j
dW1lbnQ6DQogDQotLSBHLjc3MTUsIEcuNzcxNS4xIGFuZCB0aGUgSUVURiBldmFsIGFuZCBzb2x1
dGlvbnMgZHJhZnQgYWxsIGlkZW50aWZ5IGEgDQpuZWVkIHRvIHN1cHBvcnQgaGllcmFyY2hpY2Fs
DQpyb3V0aW5nIGFyZWFzIGZvciBBU09OLCBJIGFtIHBlcnBsZXhlZCBhcyB0byB3aHkgdGhpcyBz
ZWVtcyB0byBiZSB2aWV3ZWQgDQphcyBhIG5ldyBmZWF0dXJlLg0KIA0KLS0gdGhlIGRvY3VtZW50
IGRvZXMgbm90IHNwZWNpZnkgdGhlIGRvbWFpbiBvZiB1c2FnZSBhbmQgbGVhdmVzIHRoaXMgdG8g
DQp0aGUgY2Fycmllci4gIFRoaXMgaXMgbm8gZGlmZmVyZW50DQpmcm9tIEcuNzcxNS4xIGFuZCBJ
RVRGIGRyYWZ0cyB0aGF0IGRvIG5vdCBleHBsaWNpdGx5IHN0YXRlIHdoZXRoZXIgdGhleSANCmFy
ZSB1c2VkIGZvciBpbnRyYS0gb3IgaW50ZXItZG9tYWluDQppbnRlcmZhY2VzLg0KIA0KLS0gR01Q
TFMgT1NQRiBkb2VzIG5vdCBzdXBwb3J0IGEgMTpOIG9yIE46MSByZWxhdGlvbnNoaXAgYmV0d2Vl
biByb3V0aW5nIA0KY29udHJvbGxlciBhbmQgdHJhbnNwb3J0DQpub2RlLCBoZW5jZSBleHRlbnNp
b25zIGFyZSBmZWx0IHRvIGJlIHJlcXVpcmVkIC0gYW5kIGFyZSBwcm9wb3NlZCBpbiB0aGUgDQpl
dmFsIHNvbHV0aW9ucyBkcmFmdC4gVGhlIA0KY29uY2x1c2lvbnMgYXJlIG5vIGRpZmZlcmVudC4N
CiANCi0tIHRoZSBkb2N1bWVudCBkb2VzIG5vdCBpbiBmYWN0IGRlZmluZSBhbnkgc3RhbmRhcmQg
ZXh0ZW5zaW9ucyB0byB0aGUgDQpwcm90b2NvbHMsIGFuZCBwb2ludHMgdG8gZnV0dXJlIHdvcmsN
CmluIElFVEYgYW5kIElUVSB0byBwcm92aWRlIHRoZXNlLiAgVGhlcmVmb3JlIEkgY2Fubm90IHVu
ZGVyc3RhbmQgd2hlcmUgeW91IA0Kc2F5ICJuZXcgZXh0ZW5zaW9ucyB0bw0KT1NQRiBhcmUgc3Bl
Y2lmaWVkIiBhbmQgIm5vbmUuLi5hbGlnbiB3aXRoIHRoZSBDQ0FNUCdzIEdNUExTLUFTT04gd29y
ayIuIA0KIA0KSSB0aGluayB3ZSdyZSBleHBlcmllbmNpbmcgYSBzaWduaWZpY2FudCBtaXNjb21t
dW5pY2F0aW9uLi4uDQogDQpDaGVlcnMsDQogDQpMeW5kb24NCiANCg0KRnJvbTogb3duZXItY2Nh
bXBAb3BzLmlldGYub3JnIFttYWlsdG86b3duZXItY2NhbXBAb3BzLmlldGYub3JnXSBPbiBCZWhh
bGYgDQpPZiBCcnVuZ2FyZCwgRGVib3JhaCBBLCBBTEFCUw0KU2VudDogTW9uZGF5LCBKdWx5IDI0
LCAyMDA2IDEyOjE1IFBNDQpUbzogU2FkbGVyLCBKb25hdGhhbiBCLjsgY2NhbXBAb3BzLmlldGYu
b3JnDQpDYzogQWRyaWFuIEZhcnJlbA0KU3ViamVjdDogUkU6IFByb3Bvc2VkIHJlc3BvbnNlIHRv
IE9JRiBvbiBPU1BGIEVOTkkNCkhpIEpvbmF0aGFuLCAoYW5kIEx5bmRvbiksDQogDQpUaGFua3Mg
dG8gYm90aCBvZiB5b3UgZm9yIHJlc3BvbmRpbmcuDQogDQoiU2lnbmlmaWNhbnQiIHdhcyByZWZl
cmVuY2luZzoNCiANCi0gc3VwcG9ydHMgYSAobmV3KSBoaWVyYXJjaGljYWwgT1NQRiBtb2RlbA0K
LSBzdXBwb3J0cyBpbnRlci1kb21haW4gKGludGVyLWNhcnJpZXIpIE9TUEYgKG5vdCBzdXBwb3J0
ZWQgYnkgdG9kYXkncyANCk9TUEYpDQotIGlkZW50aWZpZXMgbmFtZXNwYWNlIGlzc3VlcyB3aXRo
IEdNUExTIE9TUEYgd2hpY2ggZG8gbm90IGV4aXN0LCBhbmQgDQpwcm9wb3NlcyBleHRlbnNpb25z
IHRvICJmaXgiDQotIG5ldyBleHRlbnNpb25zIHRvIE9TUEYgYXJlIHNwZWNpZmllZA0KLSBub25l
IG9mIHRoZSBwcm9wb3NlZCBleHRlbnNpb25zIGFsaWduIHdpdGggQ0NBTVAncyBHTVBMUy1BU09O
IHdvcmsNCiANCkRpZCB5b3UgaGF2ZSBhbm90aGVyIGFkamVjdGl2ZSB0byBzdWdnZXN0PyBXZSB3
ZXJlIHRoaW5raW5nICJzaWduaWZpY2FudCIgDQp3YXMgcmF0aGVyIHNvZnQgY29uc2lkZXJpbmcg
dGhlIGFib3ZlLiBUaG91Z2ggaWYgaXQncyBqdXN0IElUVS1zcGVhayANCmRpZmZlcmVuY2VzLCB3
aHkgZG9lcyB0aGUgT0lGIGxpYWlzb24gc3RhdGUgaXQgcmVmbGVjdHMgc2V2ZXJhbCB5ZWFycyBv
ZiANCndvcmsgaW5jbHVkaW5nIHRlc3Rpbmc/IEFueSBpbnNpZ2h0IChhbGlnbm1lbnQgbWFwcGlu
ZyB0byBDQ0FNUCdzIHdvcmspIA0Kd2hpY2ggeW91IG9yIEx5bmRvbiBjYW4gcHJvdmlkZSB3b3Vs
ZCBiZSBoZWxwZnVsLiBUaGUgZGl2ZXJnZW5jZSBpcyANCmJhZmZsaW5nIHRvIHVzLg0KIA0KRGVi
b3JhaA0KIA0KIA0KDQpGcm9tOiBTYWRsZXIsIEpvbmF0aGFuIEIuIFttYWlsdG86Sm9uYXRoYW4u
U2FkbGVyQHRlbGxhYnMuY29tXSANClNlbnQ6IEZyaWRheSwgSnVseSAyMSwgMjAwNiAxMTozNCBB
TQ0KVG86IEJydW5nYXJkLCBEZWJvcmFoIEEsIEFMQUJTOyBjY2FtcEBvcHMuaWV0Zi5vcmcNCkNj
OiBBZHJpYW4gRmFycmVsDQpTdWJqZWN0OiBSRTogUHJvcG9zZWQgcmVzcG9uc2UgdG8gT0lGIG9u
IE9TUEYgRU5OSQ0KSGkgRGVib3JhaCBhbmQgQWRyaWFuLA0KIA0KSSBoYXZlbuKAmXQgc2VlbiBt
dWNoIGRpc2N1c3Npb24gb2YgdGhlIE9JRiBFLU5OSSBSb3V0aW5nIGRvY3VtZW50IG9uIHRoZSAN
CkNDQU1QIGxpc3QuICBDYW4geW91IHRlbGwgbWUgd2hhdCBwYXJ0cyBvZiB0aGUgZG9jdW1lbnQg
YXJlIOKAnHNpZ25pZmljYW50IA0KbW9kaWZpY2F0aW9ucyB0byB0aGUgb3BlcmF0aW9uIG9mIE9T
UEbigJ0/DQogDQpUaGFua3MsDQogDQpKb25hdGhhbiBTYWRsZXINCiANCg0KRnJvbTogb3duZXIt
Y2NhbXBAb3BzLmlldGYub3JnIFttYWlsdG86b3duZXItY2NhbXBAb3BzLmlldGYub3JnXSBPbiBC
ZWhhbGYgDQpPZiBCcnVuZ2FyZCwgRGVib3JhaCBBLCBBTEFCUw0KU2VudDogRnJpZGF5LCBKdWx5
IDIxLCAyMDA2IDk6MzggQU0NClRvOiBjY2FtcEBvcHMuaWV0Zi5vcmcNCkNjOiBBZHJpYW4gRmFy
cmVsDQpTdWJqZWN0OiBQcm9wb3NlZCByZXNwb25zZSB0byBPSUYgb24gT1NQRiBFTk5JDQogDQpI
aSwNCiANCldlIGhhZCBhIGNvbW11bmljYXRpb24gZnJvbSBPSUYgb24gdGhlaXIgT1NQRiBFTk5J
IHNwZWNpZmljYXRpb24uIFlvdSBjYW4gDQpzZWUgdGhlIG9yaWdpbmFsIGZpbGVzIG9uIGh0dHA6
Ly93d3cub2xkZG9nLmNvLnVrL2NjYW1wLmh0bS4gSGF2aW5nIA0KYXNzZW1ibGVkIGNvbW1lbnRz
IGZyb20gc2V2ZXJhbCBwZW9wbGUgYW5kIG91ciBkaXNjdXNzaW9ucyBpbiBNb250cmVhbCwgd2Ug
DQpoYXZlIHB1dCB0b2dldGhlciB0aGUgZm9sbG93aW5nIHJlc3BvbnNlLg0KIA0KUGxlYXNlIGNv
bW1lbnQgb24gdGhlIGxpc3QgaW4gdGhlIG5leHQgd2Vlay4NCiANClRoYW5rcywNCkFkcmlhbiBh
bmQgRGVib3JhaA0KIA0KPSA9ID0gPSA9ID0gPSA9ID0gPQ0KRGVhciBKaW0sDQogDQpXZSB0aGFu
ayB5b3UgZm9yIHNlbmRpbmcgdXMgdGhlIE9JRiBFTk5JIGRvY3VtZW50IGluIHJlc3BvbnNlIHRv
IG91ciANCnJlcXVlc3QuIFdoaWxlIHdlIGFwcHJlY2lhdGUgdGhlIGRvY3VtZW50IGJlaW5nIHBy
b3ZpZGVkIGZvciBpbmZvcm1hdGlvbiwgDQppdCBpcyBjb25jZXJuaW5nIHRoYXQgdGhpcyBkb2N1
bWVudCBoYXMgbm90IGJlZW4gcHJldmlvdXNseSBzaGFyZWQgd2l0aCANCkNDQU1QIG9yIHRoZSBP
U1BGIFdHIGNvbnNpZGVyaW5nIHRoZSBkb2N1bWVudCBjb250YWlucyBzaWduaWZpY2FudCANCm1v
ZGlmaWNhdGlvbnMgdG8gdGhlIG9wZXJhdGlvbiBvZiBPU1BGIGFuZCByZWZsZWN0cyBPSUYgd29y
ayBvdmVyIHRoZSBsYXN0IA0Kc2V2ZXJhbCB5ZWFycy4gQ0NBTVAgaGFzIGJlZW4gd29ya2luZyBv
biBHTVBMUyBBU09OIGZvciBzZXZlcmFsIHllYXJzIGFuZCANCm91ciBEZXNpZ24gVGVhbXMgaW5j
bHVkZSBPSUYgcGFydGljaXBhbnRzLiBFdmVuIHRob3VnaCBhIHJlcGx5IHdhcyBub3QgDQpyZXF1
ZXN0ZWQsIHdlIGFyZSByZXBseWluZywgYXMgd2Ugc3Ryb25nbHkgcmVjb21tZW5kIHRoYXQgdGhl
IGRvY3VtZW50IG5vdCANCmJlIHB1Ymxpc2hlZCBmb3IgcHVibGljIGluZm9ybWF0aW9uIGluIGl0
cyBjdXJyZW50IGZvcm0uDQogDQpPZiBtb3N0IGNvbmNlcm4gdG8gQ0NBTVAgaXMgdGhhdCBpdCBp
cyBub3QgYWxpZ25lZCB3aXRoIFJGQyA0MjU4IA0KKFJlcXVpcmVtZW50cyBmb3IgR2VuZXJhbGl6
ZWQgTXVsdGktUHJvdG9jb2wgTGFiZWwgU3dpdGNoaW5nIChHTVBMUykgDQpSb3V0aW5nIGZvciB0
aGUgQXV0b21hdGljYWxseSBTd2l0Y2hlZCBPcHRpY2FsIE5ldHdvcmsgKEFTT04pKSBvciB0aGUg
DQp0by1iZS1wdWJsaXNoZWQ6IA0KZnRwOi8vZnRwLmlzaS5lZHUvaW50ZXJuZXQtZHJhZnRzL2Ry
YWZ0LWlldGYtY2NhbXAtZ21wbHMtYXNvbi1yb3V0aW5nLWV2YWwtMDMudHh0DQouIENvbnNpZGVy
aW5nIG5vdGFibGUgT0lGIHBhcnRpY2lwYW50cyBhcmUgYXV0aG9ycyBvZiBib3RoIHRoZXNlIElF
VEYgDQpkb2N1bWVudHMgKGFuZCB0aGUgc2FtZSBwYXJ0aWNpcGFudHMgYXJlIGNvbnRyaWJ1dG9y
cyBhbmQgdGhlIEVkaXRvciBmb3IgDQp0aGUgT0lGIGRvY3VtZW50KSwgdGhlIG5vbi1hbGlnbm1l
bnQgaXMgcGVycGxleGluZy4gQ29uc2lkZXJpbmcgdGhlIElFVEYgDQpkb2N1bWVudCBpcyByZWFk
eSBmb3IgcHVibGljYXRpb24sIHdlIHN1Z2dlc3QgaW4gdGhlIGludGVyZXN0cyBvZiB0aW1lLCAN
CnRoYXQgeW91IGFsaWduIHlvdXIgZG9jdW1lbnQgd2l0aCB0aGUgSUVURiBkb2N1bWVudC4gSWYg
YW55IHF1ZXN0aW9ucyBvbiANCnRoZSBpbnRlcnByZXRhdGlvbiBvZiB0aGUgSUVURuKAmXMgd29y
aywgd2UgcmVjb21tZW5kIHRoYXQgeW91IGVpdGhlciANCnV0aWxpemUgdGhlIENDQU1QIG1haWwg
ZXhwbG9kZXIgb3Igc2VuZCBhIGNvbW11bmljYXRpb24uDQogDQpTcGVjaWZpYyBjb21tZW50cyBp
bmNsdWRlOg0KMS4gICAgICBXaGF0IGlzIHRoZSBpbnRlbnQgb2YgdGhpcyBkb2N1bWVudD8gV2ls
bCBpdCBiZSBwdWJsaXNoZWQgYXMgYW4gDQpJbXBsZW1lbnRhdGlvbiBBZ3JlZW1lbnQgKElBKT8N
ClRoZSB0aXRsZSBpbmRpY2F0ZXMgaXQgd2lsbCBiZSBhbiBJbXBsZW1lbnRhdGlvbiBBZ3JlZW1l
bnQgb24gR01QTFMgT1NQRiANCmV4dGVuc2lvbnMsIGJ1dCB0aGUgbWFpbiBib2R5IG9mIHRoZSBk
b2N1bWVudCBpcyBhIGxpc3Qgb2YgaXNzdWVzIHdpdGggDQpHTVBMUyBPU1BGLiBGdXJ0aGVyLCB5
b3VyIGNvbW11bmljYXRpb24gdG8gdXMgc3RhdGVkIHRoZSBkb2N1bWVudCB3YXMgDQpyZXF1aXJl
bWVudHMgb24gYW5kIHVzZSBvZiBPU1BGLVRFIGF0IHRoZSBFTk5JLiBUaGVzZSB0aHJlZSB2aWV3
cyBzZWVtIHRvIA0KYmUgaW5jb25zaXN0ZW50Lg0KMi4gICAgICBUaGUgbGlzdCBvZiBjaGFuZ2Vz
IGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gKGxpc3RlZCB1bmRlciB0aGUgDQpUYWJsZSBvZiBD
b250ZW50cykgaW5jbHVkZXMg4oCccmVtb3ZlZCDigJxpbnRyYS1jYXJyaWVy4oCdIGxpbWl0YXRp
b27igJ0gYW5kIHRoZSANCmluY2x1c2lvbiBvZiBGaWd1cmUgMSBzaG93aW5nIHRoZSBPU1BGIEVO
TkkgZm9yIHVzZSBiZXR3ZWVuIHZlbmRvciBkb21haW5zIA0KYW5kIGJldHdlZW4gY2FycmllciBk
b21haW5zLiBHTVBMUyBPU1BGLVRFIGFscmVhZHkgc3VwcG9ydHMgaW50ZXItdmVuZG9yIA0Kb3Bl
cmF0aW9ucy4gDQpUaGUgSUVURuKAmXMgR01QTFMgQVNPTiByb3V0aW5nIGZvY3VzIGhhcyBiZWVu
IG9uIHRoZSB1c2Ugb2YgYSBsaW5rLXN0YXRlIA0KYmFzZWQgcHJvdG9jb2wgdG8gc3VwcG9ydCBh
IGhpZXJhcmNoaWNhbCByb3V0aW5nIGFyY2hpdGVjdHVyZSAoRy43NzE1LjEpIA0Kd2l0aGluIGEg
Y2FycmllcuKAmXMgZG9tYWluLiBSZXF1aXJlbWVudHMgZm9yIHVzaW5nIGEgbGluayBzdGF0ZSBw
cm90b2NvbCBhcyANCmFuIGludGVyLWRvbWFpbiBwcm90b2NvbCBiZXR3ZWVuIGNhcnJpZXJzIGFy
ZSBzaWduaWZpY2FudGx5IGRpZmZlcmVudC4gV2UgDQpzdHJvbmdseSBkaXNhZ3JlZSBpZiB5b3Ug
aW50ZW5kIHRvIHB1Ymxpc2ggdGhpcyBkb2N1bWVudCBhcyBhbiANCmludGVyLWNhcnJpZXIgT1NQ
RiBFTk5JIEltcGxlbWVudGF0aW9uIEFncmVlbWVudCBjbGFpbWluZyBhbGlnbm1lbnQgd2l0aCAN
CklFVEYgUkZDcyB3aXRob3V0IHJldmlldyAob3IgYWdyZWVtZW50KSBieSBhbnkgb2YgdGhlIElF
VEYgV29ya2luZyBHcm91cHMuDQozLiAgICAgIFNlY3Rpb24gNC4xL1RhYmxlIDEgYW5kIHRoZSBz
dGF0ZW1lbnQgdW5kZXIgdGhlIHRhYmxlIGlkZW50aWZ5aW5nIA0KaXNzdWVzIHdpdGggR01QTFMg
aWRlbnRpZmllciBuYW1lc3BhY2VzIGFyZSBub3QgY29ycmVjdC4gR01QTFMgaWRlbnRpZmllciAN
Cm5hbWVzcGFjZXMgZG8gbWVldCBBU09OIHJlcXVpcmVtZW50cyBmb3IgbmFtZXNwYWNlIHNlcGFy
YXRpb24gb2YgdGhlIA0KdHJhbnNwb3J0IHBsYW5lIGFuZCBjb250cm9sIHBsYW5lIChTZWN0aW9u
IDUuMiBhbmQgNS4zL0V2YWx1YXRpb24pLiANClBlcmhhcHMgeW91IGFyZSBjb25mdXNpbmcgT1NQ
RiBhbmQgR01QTFMgT1NQRj8gQXMgeW91IGFsc28gaWRlbnRpZmllZCBpbiANCnlvdXIgbGlhaXNv
biB0aGF0IHRoZSBrZXkgYXJlYSBuZWVkaW5nIHJldmlldyB3YXMgdGhlIHN1cHBvcnQgb2YgDQpp
bmRlcGVuZGVuY2Ugb2YgZnVuY3Rpb25hbCBjb21wb25lbnQgdG8gcGh5c2ljYWwgbG9jYXRpb24s
IHRoaXMgYXBwZWFycyB0byANCmJlIGEga2V5IGFyZWEgb2YgbWlzdW5kZXJzdGFuZGluZyBvbiBH
TVBMUy4gV2UgcmVjb21tZW5kIHJldmlld2luZyBSRkMzOTQ1IA0KKEdNUExTIEFyY2hpdGVjdHVy
ZSkgdG8gdW5kZXJzdGFuZCB0aGF0IHRoZSBrZXkgYXJjaGl0ZWN0dXJlIGRpZmZlcmVuY2UgDQpi
ZXR3ZWVuIEdNUExTIGFuZCBNUExTIGlzIHRoZSBkZWNvdXBsaW5nIG9mIHRoZSB0cmFuc3BvcnQg
cGxhbmUgYW5kIA0KY29udHJvbCBwbGFuZS4gQWRkaXRpb25hbGx5LCBSRkM0Mzk0LCBSRkM0Mzk3
LCBhbmQgUkZDNDI1OCwgcHJvdmlkZSBhIA0KbWFwcGluZyB0byBJVFUgdGVybWlub2xvZ3kgd2hp
Y2ggbWF5IGJlIGhlbHBmdWwgcmVhZGluZy4NCiANCldlIHJlcXVlc3QgYW4gYWRkaXRpb25hbCBy
b3VuZCBvZiBjb21tdW5pY2F0aW9uIG9mIHRoaXMgZG9jdW1lbnQgdG8gdGhlIA0KSUVURiBiZWZv
cmUgYXBwcm92YWwgdG8gYWxsb3cgdXMgdG8gd29yayB3aXRoIHlvdSB0byBwcm9kdWNlIGNvbnZl
cmdlbmNlIA0KYmV0d2VlbiBPSUYgYW5kIElFVEYgd29yayB3aGljaCwgd2UgYmVsaWV2ZSwgd2ls
bCBiZSBpbiB0aGUgYmVzdCBpbnRlcmVzdHMgDQpvZiB0aGUgaW5kdXN0cnkuDQogDQpCZXN0IHJl
Z2FyZHMsDQpBZHJpYW4gRmFycmVsIGFuZCBEZWJvcmFoIEJydW5nYXJkLA0KQ0NBTVAgY28tY2hh
aXJzDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT0NClRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtZXNzYWdlIG1heSBi
ZSBwcml2aWxlZ2VkDQphbmQgY29uZmlkZW50aWFsIGFuZCBwcm90ZWN0ZWQgZnJvbSBkaXNjbG9z
dXJlLiBJZiB0aGUgcmVhZGVyDQpvZiB0aGlzIG1lc3NhZ2UgaXMgbm90IHRoZSBpbnRlbmRlZCBy
ZWNpcGllbnQsIG9yIGFuIGVtcGxveWVlDQpvciBhZ2VudCByZXNwb25zaWJsZSBmb3IgZGVsaXZl
cmluZyB0aGlzIG1lc3NhZ2UgdG8gdGhlDQppbnRlbmRlZCByZWNpcGllbnQsIHlvdSBhcmUgaGVy
ZWJ5IG5vdGlmaWVkIHRoYXQgYW55IHJlcHJvZHVjdGlvbiwNCmRpc3NlbWluYXRpb24gb3IgZGlz
dHJpYnV0aW9uIG9mIHRoaXMgY29tbXVuaWNhdGlvbiBpcyBzdHJpY3RseQ0KcHJvaGliaXRlZC4g
SWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9yLA0KcGxlYXNl
IG5vdGlmeSB1cyBpbW1lZGlhdGVseSBieSByZXBseWluZyB0byB0aGUgbWVzc2FnZSBhbmQNCmRl
bGV0aW5nIGl0IGZyb20geW91ciBjb21wdXRlci4gVGhhbmsgeW91LiBUZWxsYWJzDQo9PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCj09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PQ0KVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1lc3NhZ2UgbWF5IGJlIHByaXZp
bGVnZWQNCmFuZCBjb25maWRlbnRpYWwgYW5kIHByb3RlY3RlZCBmcm9tIGRpc2Nsb3N1cmUuIElm
IHRoZSByZWFkZXINCm9mIHRoaXMgbWVzc2FnZSBpcyBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVu
dCwgb3IgYW4gZW1wbG95ZWUNCm9yIGFnZW50IHJlc3BvbnNpYmxlIGZvciBkZWxpdmVyaW5nIHRo
aXMgbWVzc2FnZSB0byB0aGUNCmludGVuZGVkIHJlY2lwaWVudCwgeW91IGFyZSBoZXJlYnkgbm90
aWZpZWQgdGhhdCBhbnkgcmVwcm9kdWN0aW9uLA0KZGlzc2VtaW5hdGlvbiBvciBkaXN0cmlidXRp
b24gb2YgdGhpcyBjb21tdW5pY2F0aW9uIGlzIHN0cmljdGx5DQpwcm9oaWJpdGVkLiBJZiB5b3Ug
aGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3IsDQpwbGVhc2Ugbm90aWZ5
IHVzIGltbWVkaWF0ZWx5IGJ5IHJlcGx5aW5nIHRvIHRoZSBtZXNzYWdlIGFuZA0KZGVsZXRpbmcg
aXQgZnJvbSB5b3VyIGNvbXB1dGVyLiBUaGFuayB5b3UuIFRlbGxhYnMNCj09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KDQoNCg==

Envelope-to: ccamp-data@psg.com
Delivery-date: Mon, 24 Jul 2006 23:38:07 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Proposed response to OIF on OSPF ENNI
Date: Mon, 24 Jul 2006 19:37:08 -0400
Message-ID: <0901D1988E815341A0103206A834DA07F1A1E6@mdmxm02.ciena.com>
Thread-Topic: Proposed response to OIF on OSPF ENNI
Thread-Index: Acavcs3mO8IY/mSXRJ+Fchtq1gp9RgAAFvaA
From: "Ong, Lyndon" <Lyong@Ciena.com>
To: <Dimitri.Papadimitriou@alcatel.be>, "Brungard, Deborah A, ALABS" <dbrungard@att.com>
Cc: "Adrian Farrel" <adrian@olddog.co.uk>, <ccamp@ops.ietf.org>, <owner-ccamp@ops.ietf.org>

Hi Dimitri,

Thank you!  I was putting together a response to Deborah's email, but=20
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=20
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=20
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: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On
Behalf Of Dimitri.Papadimitriou@alcatel.be
Sent: Monday, July 24, 2006 3:42 PM
To: Brungard, Deborah A, ALABS
Cc: Adrian Farrel; ccamp@ops.ietf.org; owner-ccamp@ops.ietf.org
Subject: Re: Proposed response to OIF on OSPF ENNI

hi -=20

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

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

thanks,
- dimitri.

"Brungard, Deborah A, ALABS" <dbrungard@att.com> Sent by:
owner-ccamp@ops.ietf.org
21/07/2006 16:37
=20
        To:     <ccamp@ops.ietf.org>
        cc:     "Adrian Farrel" <adrian@olddog.co.uk>
        Subject:        Proposed response to OIF on OSPF ENNI

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:=20
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.      What is the intent of this document? Will it be published as an=20
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=20
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.      Section 4.1/Table 1 and the statement under the table
identifying=20
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).=20
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

Envelope-to: ccamp-data@psg.com
Delivery-date: Mon, 24 Jul 2006 22:59:51 +0000
Message-ID: <44C550D7.90104@kddilabs.jp>
Date: Tue, 25 Jul 2006 07:59:35 +0900
From: Tomohiro Otani <otani@kddilabs.jp>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: "Brungard, Deborah A, ALABS" <dbrungard@att.com>
Cc: ccamp@ops.ietf.org, Adrian Farrel <adrian@olddog.co.uk>
Subject: Re: Proposed response to OIF on OSPF ENNI
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit

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:
> 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.
>  
> 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-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$B!G(Bs 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 $B!H(B/removed $B!H(Bintra-carrier$B!I(B limitation/$B!I(B 
> 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$B!G(Bs 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$B!G(Bs 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
> 

Envelope-to: ccamp-data@psg.com
Delivery-date: Mon, 24 Jul 2006 22:43:23 +0000
To: "Brungard, Deborah A, ALABS" <dbrungard@att.com>
Cc: "Adrian Farrel" <adrian@olddog.co.uk>, ccamp@ops.ietf.org, owner-ccamp@ops.ietf.org
Subject: Re: Proposed response to OIF on OSPF ENNI
MIME-Version: 1.0
Message-ID: <OF356FF5E0.AA963565-ONC12571B5.0078B3A1-C12571B5.007CBAC0@netfr.alcatel.fr>
From: Dimitri.Papadimitriou@alcatel.be
Date: Tue, 25 Jul 2006 00:42:22 +0200
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: base64

aGkgLSANCg0KaSBsb29rZWQgYXQgdGhlIE9JRiBJQSBkb2N1bWVudCwgdGhlIGJlbG93IHRleHQg
cHJvcG9zZWQgZm9yIGxpYWlzb24gDQppbmNsdWRlcyBtb3N0IG9mIHRoZSBjb25jZXJucw0KDQpv
KSBzZWN0aW9uIDQuMSBwcm92aWRlcyBhIHRhYmxlIGJlaW5nIGFuIGludGVycHJldGF0aW9uIG9m
IE9TUEYgdGhhdCANCmRlc2VydmVzIHNlcmlvdXMgSUVURiByZXZpZXcgYi9mIHB1YmxpY2F0aW9u
IA0KDQpvKSBwb3NpdGlvbmluZyBvZiB0aGlzIElBIGlzIGNvbmZ1c2luZyBib3RoIGluIHRlcm1z
IG9mIHNjb3BlIGludHJhLSB2cy4gDQppbnRlci1jYXJyaWVyIChpdCAqc2VlbXMqIGFwcGxpY2Fi
bGUgdG8gYm90aCB3aGlsZSB1c2luZyBPU1BGIGFzIA0KaW50ZXItY2FycmllciByb3V0aW5nIHBy
b3RvY29sIGlzIG1vcmUgdGhhbiBxdWVzdGlvbmFibGUgaWYgbm90IHRvdGFsbHkgDQp3cm9uZykg
YW5kIHRhcmdldCAocmVxdWlyZW1lbnRzICh3aGljaCkgPyBhcHBsaWNhYmlsaXR5IG9mIGRlbW8g
Y29kZSA/IA0KZXhwZXJpbWVudGFsIGV4dGVuc2lvbnMgPykNCg0Kbykgc2VjdGlvbiAxLjIgaXMg
dW5jbGVhciBhYm91dCBwb3NpdGlvbmluZyBvZiB0aGUgcHJvcG9zZWQgZXh0ZW5zaW9ucyAoaW4g
DQpBcHBlbmRpeCkgIlRoZXNlIGV4dGVuc2lvbnMgdXNlIGNvZGVwb2ludHMgaW4gdGhlIHJhbmdl
IHJlc2VydmVkIGJ5IElBTkEgDQpmb3IgcHJpdmF0ZSBhbmQgZXhwZXJpbWVudGFsIHVzZSwgYW5k
IGFyZSBub3QgYWdyZWVkIHN0YW5kYXJkIGNvZGVwb2ludHMgDQphdCB0aGlzIHRpbWUuICBGdXR1
cmUgZGV2ZWxvcG1lbnRzIG1heSByZXN1bHQgaW4gY2hhbmdlIHRvIHRoZSBjb2RlcG9pbnRzIA0K
YW5kL29yIGZvcm1hdHMgb2YgdGhlc2UgZXh0ZW5zaW9ucy4iIG1lYW5pbmcgYmFzaWNhbGx5IHRo
YXQgT0lGIGhhcyANCmRlY2lkZWQgb24gaXRzIG93biB0aGF0IHRoZSBwcm9wb3NlZCBPU1BGIG1l
Y2hhbmlzbXMgYXJlIHZhbGlkIGFuZCB0aGF0IA0Kb25seSBlbmNvZGluZyBjb3VsZCBiZSBzdWJq
ZWN0IHRvIGRpc2N1c3Npb24gYnV0IGFmYWlrIE9JRiBpcyBub3QgDQphdXRob3JpdGF0aXZlIGZv
ciBPU1BGIA0KDQp0aGFua3MsDQotIGRpbWl0cmkuDQoNCg0KDQoNCg0KDQoNCiJCcnVuZ2FyZCwg
RGVib3JhaCBBLCBBTEFCUyIgPGRicnVuZ2FyZEBhdHQuY29tPg0KU2VudCBieTogb3duZXItY2Nh
bXBAb3BzLmlldGYub3JnDQoyMS8wNy8yMDA2IDE2OjM3DQogDQogICAgICAgIFRvOiAgICAgPGNj
YW1wQG9wcy5pZXRmLm9yZz4NCiAgICAgICAgY2M6ICAgICAiQWRyaWFuIEZhcnJlbCIgPGFkcmlh
bkBvbGRkb2cuY28udWs+DQogICAgICAgIFN1YmplY3Q6ICAgICAgICBQcm9wb3NlZCByZXNwb25z
ZSB0byBPSUYgb24gT1NQRiBFTk5JDQoNCg0KSGksDQogDQpXZSBoYWQgYSBjb21tdW5pY2F0aW9u
IGZyb20gT0lGIG9uIHRoZWlyIE9TUEYgRU5OSSBzcGVjaWZpY2F0aW9uLiBZb3UgY2FuIA0Kc2Vl
IHRoZSBvcmlnaW5hbCBmaWxlcyBvbiBodHRwOi8vd3d3Lm9sZGRvZy5jby51ay9jY2FtcC5odG0u
IEhhdmluZyANCmFzc2VtYmxlZCBjb21tZW50cyBmcm9tIHNldmVyYWwgcGVvcGxlIGFuZCBvdXIg
ZGlzY3Vzc2lvbnMgaW4gTW9udHJlYWwsIHdlIA0KaGF2ZSBwdXQgdG9nZXRoZXIgdGhlIGZvbGxv
d2luZyByZXNwb25zZS4NCiANClBsZWFzZSBjb21tZW50IG9uIHRoZSBsaXN0IGluIHRoZSBuZXh0
IHdlZWsuDQogDQpUaGFua3MsDQpBZHJpYW4gYW5kIERlYm9yYWgNCiANCj0gPSA9ID0gPSA9ID0g
PSA9ID0NCkRlYXIgSmltLA0KIA0KV2UgdGhhbmsgeW91IGZvciBzZW5kaW5nIHVzIHRoZSBPSUYg
RU5OSSBkb2N1bWVudCBpbiByZXNwb25zZSB0byBvdXIgDQpyZXF1ZXN0LiBXaGlsZSB3ZSBhcHBy
ZWNpYXRlIHRoZSBkb2N1bWVudCBiZWluZyBwcm92aWRlZCBmb3IgaW5mb3JtYXRpb24sIA0KaXQg
aXMgY29uY2VybmluZyB0aGF0IHRoaXMgZG9jdW1lbnQgaGFzIG5vdCBiZWVuIHByZXZpb3VzbHkg
c2hhcmVkIHdpdGggDQpDQ0FNUCBvciB0aGUgT1NQRiBXRyBjb25zaWRlcmluZyB0aGUgZG9jdW1l
bnQgY29udGFpbnMgc2lnbmlmaWNhbnQgDQptb2RpZmljYXRpb25zIHRvIHRoZSBvcGVyYXRpb24g
b2YgT1NQRiBhbmQgcmVmbGVjdHMgT0lGIHdvcmsgb3ZlciB0aGUgbGFzdCANCnNldmVyYWwgeWVh
cnMuIENDQU1QIGhhcyBiZWVuIHdvcmtpbmcgb24gR01QTFMgQVNPTiBmb3Igc2V2ZXJhbCB5ZWFy
cyBhbmQgDQpvdXIgRGVzaWduIFRlYW1zIGluY2x1ZGUgT0lGIHBhcnRpY2lwYW50cy4gRXZlbiB0
aG91Z2ggYSByZXBseSB3YXMgbm90IA0KcmVxdWVzdGVkLCB3ZSBhcmUgcmVwbHlpbmcsIGFzIHdl
IHN0cm9uZ2x5IHJlY29tbWVuZCB0aGF0IHRoZSBkb2N1bWVudCBub3QgDQpiZSBwdWJsaXNoZWQg
Zm9yIHB1YmxpYyBpbmZvcm1hdGlvbiBpbiBpdHMgY3VycmVudCBmb3JtLg0KIA0KT2YgbW9zdCBj
b25jZXJuIHRvIENDQU1QIGlzIHRoYXQgaXQgaXMgbm90IGFsaWduZWQgd2l0aCBSRkMgNDI1OCAN
CihSZXF1aXJlbWVudHMgZm9yIEdlbmVyYWxpemVkIE11bHRpLVByb3RvY29sIExhYmVsIFN3aXRj
aGluZyAoR01QTFMpIA0KUm91dGluZyBmb3IgdGhlIEF1dG9tYXRpY2FsbHkgU3dpdGNoZWQgT3B0
aWNhbCBOZXR3b3JrIChBU09OKSkgb3IgdGhlIA0KdG8tYmUtcHVibGlzaGVkOiANCmZ0cDovL2Z0
cC5pc2kuZWR1L2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLWNjYW1wLWdtcGxzLWFzb24tcm91
dGluZy1ldmFsLTAzLnR4dA0KLiBDb25zaWRlcmluZyBub3RhYmxlIE9JRiBwYXJ0aWNpcGFudHMg
YXJlIGF1dGhvcnMgb2YgYm90aCB0aGVzZSBJRVRGIA0KZG9jdW1lbnRzIChhbmQgdGhlIHNhbWUg
cGFydGljaXBhbnRzIGFyZSBjb250cmlidXRvcnMgYW5kIHRoZSBFZGl0b3IgZm9yIA0KdGhlIE9J
RiBkb2N1bWVudCksIHRoZSBub24tYWxpZ25tZW50IGlzIHBlcnBsZXhpbmcuIENvbnNpZGVyaW5n
IHRoZSBJRVRGIA0KZG9jdW1lbnQgaXMgcmVhZHkgZm9yIHB1YmxpY2F0aW9uLCB3ZSBzdWdnZXN0
IGluIHRoZSBpbnRlcmVzdHMgb2YgdGltZSwgDQp0aGF0IHlvdSBhbGlnbiB5b3VyIGRvY3VtZW50
IHdpdGggdGhlIElFVEYgZG9jdW1lbnQuIElmIGFueSBxdWVzdGlvbnMgb24gDQp0aGUgaW50ZXJw
cmV0YXRpb24gb2YgdGhlIElFVEbigJlzIHdvcmssIHdlIHJlY29tbWVuZCB0aGF0IHlvdSBlaXRo
ZXIgDQp1dGlsaXplIHRoZSBDQ0FNUCBtYWlsIGV4cGxvZGVyIG9yIHNlbmQgYSBjb21tdW5pY2F0
aW9uLg0KIA0KU3BlY2lmaWMgY29tbWVudHMgaW5jbHVkZToNCjEuICAgICAgV2hhdCBpcyB0aGUg
aW50ZW50IG9mIHRoaXMgZG9jdW1lbnQ/IFdpbGwgaXQgYmUgcHVibGlzaGVkIGFzIGFuIA0KSW1w
bGVtZW50YXRpb24gQWdyZWVtZW50IChJQSk/DQpUaGUgdGl0bGUgaW5kaWNhdGVzIGl0IHdpbGwg
YmUgYW4gSW1wbGVtZW50YXRpb24gQWdyZWVtZW50IG9uIEdNUExTIE9TUEYgDQpleHRlbnNpb25z
LCBidXQgdGhlIG1haW4gYm9keSBvZiB0aGUgZG9jdW1lbnQgaXMgYSBsaXN0IG9mIGlzc3VlcyB3
aXRoIA0KR01QTFMgT1NQRi4gRnVydGhlciwgeW91ciBjb21tdW5pY2F0aW9uIHRvIHVzIHN0YXRl
ZCB0aGUgZG9jdW1lbnQgd2FzIA0KcmVxdWlyZW1lbnRzIG9uIGFuZCB1c2Ugb2YgT1NQRi1URSBh
dCB0aGUgRU5OSS4gVGhlc2UgdGhyZWUgdmlld3Mgc2VlbSB0byANCmJlIGluY29uc2lzdGVudC4N
CjIuICAgICAgVGhlIGxpc3Qgb2YgY2hhbmdlcyBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIChs
aXN0ZWQgdW5kZXIgdGhlIA0KVGFibGUgb2YgQ29udGVudHMpIGluY2x1ZGVzIOKAnHJlbW92ZWQg
4oCcaW50cmEtY2FycmllcuKAnSBsaW1pdGF0aW9u4oCdIGFuZCB0aGUgDQppbmNsdXNpb24gb2Yg
RmlndXJlIDEgc2hvd2luZyB0aGUgT1NQRiBFTk5JIGZvciB1c2UgYmV0d2VlbiB2ZW5kb3IgZG9t
YWlucyANCmFuZCBiZXR3ZWVuIGNhcnJpZXIgZG9tYWlucy4gR01QTFMgT1NQRi1URSBhbHJlYWR5
IHN1cHBvcnRzIGludGVyLXZlbmRvciANCm9wZXJhdGlvbnMuIA0KVGhlIElFVEbigJlzIEdNUExT
IEFTT04gcm91dGluZyBmb2N1cyBoYXMgYmVlbiBvbiB0aGUgdXNlIG9mIGEgbGluay1zdGF0ZSAN
CmJhc2VkIHByb3RvY29sIHRvIHN1cHBvcnQgYSBoaWVyYXJjaGljYWwgcm91dGluZyBhcmNoaXRl
Y3R1cmUgKEcuNzcxNS4xKSANCndpdGhpbiBhIGNhcnJpZXLigJlzIGRvbWFpbi4gUmVxdWlyZW1l
bnRzIGZvciB1c2luZyBhIGxpbmsgc3RhdGUgcHJvdG9jb2wgYXMgDQphbiBpbnRlci1kb21haW4g
cHJvdG9jb2wgYmV0d2VlbiBjYXJyaWVycyBhcmUgc2lnbmlmaWNhbnRseSBkaWZmZXJlbnQuIFdl
IA0Kc3Ryb25nbHkgZGlzYWdyZWUgaWYgeW91IGludGVuZCB0byBwdWJsaXNoIHRoaXMgZG9jdW1l
bnQgYXMgYW4gDQppbnRlci1jYXJyaWVyIE9TUEYgRU5OSSBJbXBsZW1lbnRhdGlvbiBBZ3JlZW1l
bnQgY2xhaW1pbmcgYWxpZ25tZW50IHdpdGggDQpJRVRGIFJGQ3Mgd2l0aG91dCByZXZpZXcgKG9y
IGFncmVlbWVudCkgYnkgYW55IG9mIHRoZSBJRVRGIFdvcmtpbmcgR3JvdXBzLg0KMy4gICAgICBT
ZWN0aW9uIDQuMS9UYWJsZSAxIGFuZCB0aGUgc3RhdGVtZW50IHVuZGVyIHRoZSB0YWJsZSBpZGVu
dGlmeWluZyANCmlzc3VlcyB3aXRoIEdNUExTIGlkZW50aWZpZXIgbmFtZXNwYWNlcyBhcmUgbm90
IGNvcnJlY3QuIEdNUExTIGlkZW50aWZpZXIgDQpuYW1lc3BhY2VzIGRvIG1lZXQgQVNPTiByZXF1
aXJlbWVudHMgZm9yIG5hbWVzcGFjZSBzZXBhcmF0aW9uIG9mIHRoZSANCnRyYW5zcG9ydCBwbGFu
ZSBhbmQgY29udHJvbCBwbGFuZSAoU2VjdGlvbiA1LjIgYW5kIDUuMy9FdmFsdWF0aW9uKS4gDQpQ
ZXJoYXBzIHlvdSBhcmUgY29uZnVzaW5nIE9TUEYgYW5kIEdNUExTIE9TUEY/IEFzIHlvdSBhbHNv
IGlkZW50aWZpZWQgaW4gDQp5b3VyIGxpYWlzb24gdGhhdCB0aGUga2V5IGFyZWEgbmVlZGluZyBy
ZXZpZXcgd2FzIHRoZSBzdXBwb3J0IG9mIA0KaW5kZXBlbmRlbmNlIG9mIGZ1bmN0aW9uYWwgY29t
cG9uZW50IHRvIHBoeXNpY2FsIGxvY2F0aW9uLCB0aGlzIGFwcGVhcnMgdG8gDQpiZSBhIGtleSBh
cmVhIG9mIG1pc3VuZGVyc3RhbmRpbmcgb24gR01QTFMuIFdlIHJlY29tbWVuZCByZXZpZXdpbmcg
UkZDMzk0NSANCihHTVBMUyBBcmNoaXRlY3R1cmUpIHRvIHVuZGVyc3RhbmQgdGhhdCB0aGUga2V5
IGFyY2hpdGVjdHVyZSBkaWZmZXJlbmNlIA0KYmV0d2VlbiBHTVBMUyBhbmQgTVBMUyBpcyB0aGUg
ZGVjb3VwbGluZyBvZiB0aGUgdHJhbnNwb3J0IHBsYW5lIGFuZCANCmNvbnRyb2wgcGxhbmUuIEFk
ZGl0aW9uYWxseSwgUkZDNDM5NCwgUkZDNDM5NywgYW5kIFJGQzQyNTgsIHByb3ZpZGUgYSANCm1h
cHBpbmcgdG8gSVRVIHRlcm1pbm9sb2d5IHdoaWNoIG1heSBiZSBoZWxwZnVsIHJlYWRpbmcuDQog
DQpXZSByZXF1ZXN0IGFuIGFkZGl0aW9uYWwgcm91bmQgb2YgY29tbXVuaWNhdGlvbiBvZiB0aGlz
IGRvY3VtZW50IHRvIHRoZSANCklFVEYgYmVmb3JlIGFwcHJvdmFsIHRvIGFsbG93IHVzIHRvIHdv
cmsgd2l0aCB5b3UgdG8gcHJvZHVjZSBjb252ZXJnZW5jZSANCmJldHdlZW4gT0lGIGFuZCBJRVRG
IHdvcmsgd2hpY2gsIHdlIGJlbGlldmUsIHdpbGwgYmUgaW4gdGhlIGJlc3QgaW50ZXJlc3RzIA0K
b2YgdGhlIGluZHVzdHJ5Lg0KIA0KQmVzdCByZWdhcmRzLA0KQWRyaWFuIEZhcnJlbCBhbmQgRGVi
b3JhaCBCcnVuZ2FyZCwNCkNDQU1QIGNvLWNoYWlycw0KDQo=

Envelope-to: ccamp-data@psg.com
Delivery-date: Mon, 24 Jul 2006 22:02:20 +0000
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: <A1A52203CA93634BA1748887B9993AEA02FC5B6C@USNVEX1.tellabs-west.tellabsinc.net>
Thread-Topic: Proposed response to OIF on OSPF ENNI
Thread-Index: Acas0Ha/aYxFikOBS5m873SVRoVJxgAACLxQAAHPZJAAnZ89IAACGznwAAEdy+AAA5YHgA==
From: "Sadler, Jonathan B." <Jonathan.Sadler@tellabs.com>
To: "Brungard, Deborah A, ALABS" <dbrungard@att.com>, "Ong, Lyndon" <Lyong@Ciena.com>, <ccamp@ops.ietf.org>
Cc: "Adrian Farrel" <adrian@olddog.co.uk>

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

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:p=3D"urn:schemas-microsoft-com:office:powerpoint" xmlns:oa=3D"urn:sch=
emas-microsoft-com:office:activation" xmlns:st1=3D"urn:schemas-microsoft-co=
m:office:smarttags" xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]--><o:SmartTagType
 namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" name=3D"City"
 downloadurl=3D"http://www.5iamas-microsoft-com:office:smarttags"/>
<o:SmartTagType namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"place" downloadurl=3D"http://www.5iantlavalamp.com/"/>
<o:SmartTagType namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"PersonName" downloadurl=3D"http://www.microsoft.com"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"MS Mincho";
	panose-1:2 2 6 9 4 2 5 8 3 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:"\@MS Mincho";
	panose-1:2 2 6 9 4 2 5 8 3 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:blue;
	text-decoration:underline;}
pre
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
span.EmailStyle17
	{mso-style-type:personal;
	font-family:Arial;
	color:navy;}
span.EmailStyle19
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dblue>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Hi Deborah, Lyndon, et al.,<o:p></o:p>=
</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>You mention:<o:p></o:p></span></font><=
/p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>&gt;&gt; -- G.7715, G.7715.1 and the I=
ETF
eval and solutions draft all identify a need to support hierarchical<o:p></=
o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>&gt;&gt; routing areas for ASON, I am
perplexed as to why this seems to be viewed as a new feature.&nbsp;</span><=
/font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>&gt; db&gt; &quot;significant&quot; was
not based on &quot;newness&quot; as a feature, it was based on what GMPLS O=
SPF
can<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>&gt; support today.</span></font><o:p>=
</o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Regards,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><st1:PersonName w:st=3D"on"><font size=3D2 color=3Dnavy
 face=3DArial><span style=3D'font-size:10.0pt;font-family:Arial;color:navy'=
>Jonathan
 Sadler</span></font></st1:PersonName><font size=3D2 color=3Dnavy face=3DAr=
ial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p></o:p></span><=
/font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font siz=
e=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span style=3D'font-si=
ze:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'> Brungard,
Deborah A, ALABS [mailto:dbrungard@att.com] <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Monday, July 24, 2006 =
4:22
PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Ong, Lyndon; Sadler, Jon=
athan
B=2E; ccamp@ops.ietf.org<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> Adrian Farrel<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: Proposed respon=
se to
OIF on OSPF ENNI</span></font><o:p></o:p></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>below (noted as db&gt;)...</span></fon=
t><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Lyndon, do you think the OIF document =
and
CCAMP's ASON Requirements and Evaluation document are aligned?</span></font=
><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Thanks,</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Deborah</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font siz=
e=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabIndex=3D-1>

</span></font></div>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><b><font size=3D2 face=
=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma;font-weight:bold'>From:</span>=
</font></b><font
size=3D2 face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'>=
 Ong,
Lyndon [mailto:Lyong@Ciena.com] <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Monday, July 24, 2006 =
3:33
PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Brungard, Deborah A, ALA=
BS;
Sadler, Jonathan B.; ccamp@ops.ietf.org<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> Adrian Farrel<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: Proposed respon=
se to
OIF on OSPF ENNI</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Hi Deborah,</span></font><o:p></o:p></=
p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Here's what I would say&nbsp;is in and=
 not
in the OIF document:</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>-- G.7715, G.7715.1 and the IETF eval =
and
solutions draft all identify a need to support hierarchical</span></font><o=
:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>routing areas for ASON, I am perplexed=
 as
to why this seems to be viewed as a new feature.&nbsp;</span></font><o:p></=
o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>db&gt; &quot;significant&quot; was not
based on &quot;newness&quot; as a feature, it was based on what GMPLS OSPF =
can support
today.</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>&nbsp;</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>-- the document does not specify the
domain of usage and leaves this to the carrier.&nbsp; This is no different<=
/span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>from G.7715.1 and IETF drafts that do =
not
explicitly state whether they are used for intra- or inter-domain</span></f=
ont><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>interfaces.</span></font><o:p></o:p></=
p>

db&gt; 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&nbsp;- Figure&nb=
sp;1
shows it for use between Carriers. The document may &quot;leave it to the
carrier&quot;, but OIF&nbsp;claims it can do. I would presuppose an
Implementation Agreement would properly scope the solution.
Inter-carrier&nbsp;was&nbsp;not included in the ASON-GMPLS routing
requirements. Do you think the same solution can be used inter-carrier?</sp=
an><o:p></o:p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>-- GMPLS OSPF does not support a 1:N or
N:1 relationship between routing controller and transport</span></font><o:p=
></o:p></p>

node, hence extensions are felt to be
required - and are proposed in the eval solutions draft. The =
<o:p></o:p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>conclusions are no different.</span></=
font><o:p></o:p></p>

db&gt; 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 &quot;transport plane name&quot;. The o=
nly
GMPLS-ASON identified need was&nbsp;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&nbsp;&quot;data plane&quot;
(RFC4394 provides a good mapping of terminology).&nbsp;And, this was not ba=
sed
on the issue which OIF identified in section 4.2, &quot;identifier namespac=
es
are merged together&quot; in GMPLS.<o:p></o:p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>-- the document does not in fact define
any standard extensions to the protocols, and points to future work</span><=
/font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>in IETF and ITU to provide these.&nbsp;
Therefore I cannot understand where you say &quot;new extensions to</span><=
/font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>OSPF are specified&quot; and
&quot;none...align with the CCAMP's GMPLS-ASON work&quot;.&nbsp; </span></f=
ont><o:p></o:p></p>

<div>

db&gt; None of the identified &quot;is=
sues
for extensions&quot; 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?=
<o:p></o:p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>I think we're experiencing a significa=
nt
miscommunication...</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>db&gt; Agree;-)</span></font><o:p></o:=
p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Cheers,</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Lyndon</span></font><o:p></o:p></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font siz=
e=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabIndex=3D-1>

</span></font></div>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><b><font size=3D2 face=
=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma;font-weight:bold'>From:</span>=
</font></b><font
size=3D2 face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'>
owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] <b><span
style=3D'font-weight:bold'>On Behalf Of </span></b>Brungard, Deborah A, ALA=
BS<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Monday, July 24, 2006 =
12:15
PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Sadler, Jonathan B.;
ccamp@ops.ietf.org<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> Adrian Farrel<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: Proposed respon=
se to
OIF on OSPF ENNI</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Hi Jonathan, (and Lyndon),</span></fon=
t><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Thanks to both of you for responding.<=
/span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>&quot;Significant&quot; was referencin=
g:</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>- supports&nbsp;a&nbsp;(new) hierarchi=
cal
OSPF model</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>-&nbsp;supports&nbsp;inter-domain
(inter-carrier) OSPF (not supported by today's OSPF)</span></font><o:p></o:=
p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>- identifies namespace issues with GMP=
LS
OSPF which do not exist, and proposes extensions to &quot;fix&quot;</span><=
/font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>- new extensions to OSPF are specified=
</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>- none of the proposed extensions align
with CCAMP's GMPLS-ASON work</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

Did you have another adjective to sugg=
est?
We&nbsp;were thinking&nbsp;&quot;significant&quot; 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.&nbsp;The divergence is&nbsp;baffling to us.<o:p></o:=
p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Deborah</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font siz=
e=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabIndex=3D-1>

</span></font></div>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><b><font size=3D2 face=
=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma;font-weight:bold'>From:</span>=
</font></b><font
size=3D2 face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'>=
 Sadler, Jonathan
B=2E [mailto:Jonathan.Sadler@tellabs.com] <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Friday, July 21, 2006 =
11:34
AM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Brungard, Deborah A, ALA=
BS;
ccamp@ops.ietf.org<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> Adrian Farrel<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: Proposed respon=
se to
OIF on OSPF ENNI</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Hi Deborah and Adrian,<o:p></o:p></spa=
n></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

I haven&#8217;t seen much discussion of
the OIF E-NNI Routing document on the CCAMP list. &nbsp;Can you tell me what
parts of the document are &#8220;significant modifications to the operation=
 of
OSPF&#8221;?<o:p></o:p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Thanks,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><st1:PersonName w:st=3D"on"><font size=3D2 color=3Dnavy
 face=3DArial><span style=3D'font-size:10.0pt;font-family:Arial;color:navy'=
>Jonathan
 Sadler</span></font></st1:PersonName><font size=3D2 color=3Dnavy face=3DAr=
ial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p></o:p></span><=
/font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font siz=
e=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabIndex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span style=3D'font-si=
ze:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'>
owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] <b><span
style=3D'font-weight:bold'>On Behalf Of </span></b>Brungard, Deborah A, ALA=
BS<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Friday, July 21, 2006 =
9:38
AM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> ccamp@ops.ietf.org<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> Adrian Farrel<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> Proposed response t=
o OIF
on OSPF ENNI</span></font><o:p></o:p></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Hi,</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

We had a communication from OIF on the=
ir
OSPF ENNI specification. You can see the original files on <a
href=3D"http://www.olddog.co.uk/ccamp.htm">http://www.olddog.co.uk/ccamp.=
htm</a>. Having assembled comments from several people and our discuss=
ions
in <st1:place w:st=3D"on"><st1:City w:st=3D"on">Montreal</st1:City></st1:pl=
ace>, we
have put together the following response.<o:p></o:p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Please comment on the list in the next
week.</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Thanks,</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Adrian and Deborah</span></font><o:p><=
/o:p></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>=3D =3D =3D =3D =3D =3D =3D =3D =3D =3D<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>Dear Jim,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

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.<o:p></o:p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

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: <a
href=3D"ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpls-ason-routi=
ng-eval-03.txt">ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpls-as=
on-routing-eval-03.txt</a>.
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&#8217;s work, we recommend that you either utilize the CCAMP mail expl=
oder
or send a communication.<o:p></o:p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>Specific comments include:<o:p></o:p></span></font></p>

1.<=
font
size=3D1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </s=
pan>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></o:p>

<p class=3DMsoNormal style=3D'margin-left:.25in;text-indent:-.25in'><i><font
size=3D3 face=3D"Times New Roman"><span style=3D'font-size:12.0pt;font-styl=
e:italic'>2.</span></font></i><i><font
size=3D1><span style=3D'font-size:7.0pt;font-style:italic'>&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;
</span></font></i>The list of changes from the previous version (listed und=
er
the Table of Contents) includes &#8220;<i><span style=3D'font-style:italic'=
>removed
&#8220;intra-carrier&#8221; limitation</span></i>&#8221; 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. <b=
r>
The IETF&#8217;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&#8217;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.<i><span style=3D'font-style:i=
talic'><o:p></o:p></span></i></p>

3.<=
font
size=3D1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </s=
pan>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.<o:p></o:p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>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.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>Best regards,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><st1:PersonName w:st=3D"on"><font size=3D3 face=3D"Tim=
es New Roman"><span
 style=3D'font-size:12.0pt'>Adrian Farrel</span></font></st1:PersonName> and
Deborah Brungard,<o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>CCAMP co-chairs<o:p></o:p></span></font></p>

</div>

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

<pre>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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
</pre></body>

</html>

------_=_NextPart_001_01C6AF6C.C2554A22--

Envelope-to: ccamp-data@psg.com
Delivery-date: Mon, 24 Jul 2006 21:41:41 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6AF69.D7935803"
Subject: RE: Proposed response to OIF on OSPF ENNI
Date: Mon, 24 Jul 2006 16:38:05 -0500
Message-ID: <A1A52203CA93634BA1748887B9993AEA02FC5B46@USNVEX1.tellabs-west.tellabsinc.net>
Thread-Topic: Proposed response to OIF on OSPF ENNI
Thread-Index: Acas0Ha/aYxFikOBS5m873SVRoVJxgAACLxQAAHPZJAAnZ89IAACGznwAAEH8mAAAxLNQAAAS4QQ
From: "Sadler, Jonathan B." <Jonathan.Sadler@tellabs.com>
To: "Brungard, Deborah A, ALABS" <dbrungard@att.com>, "Ong, Lyndon" <Lyong@Ciena.com>, <ccamp@ops.ietf.org>
Cc: "Adrian Farrel" <adrian@olddog.co.uk>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6AF69.D7935803
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="us-ascii"

Hi Deborah,

=20

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.

=20

Regards,

=20

Jonathan Sadler

=20

________________________________

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

=20

Hi Jonathan,

=20

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.

=20

Thanks,

Deborah

=20

________________________________

From: Sadler, Jonathan B. [mailto:Jonathan.Sadler@tellabs.com]=20
Sent: Monday, July 24, 2006 4:32 PM
To: Brungard, Deborah A, ALABS; Ong, Lyndon; ccamp@ops.ietf.org
Cc: Adrian Farrel
Subject: RE: Proposed response to OIF on OSPF ENNI

Hi Deborah, Lyndon, et al,

=20

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.

=20

Given that:

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

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

=20

Regards,

=20

Jonathan Sadler

=20

________________________________

From: Ong, Lyndon [mailto:Lyong@Ciena.com]=20
Sent: Monday, July 24, 2006 2: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

=20

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

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

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

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

=20

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

=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
<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
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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_01C6AF69.D7935803
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset="us-ascii"

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:p=3D"urn:schemas-microsoft-com:office:powerpoint" xmlns:oa=3D"urn:sch=
emas-microsoft-com:office:activation" xmlns:st1=3D"urn:schemas-microsoft-co=
m:office:smarttags" xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]--><o:SmartTagType
 namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" name=3D"City"
 downloadurl=3D"http://www.5iamas-microsoft-com:office:smarttags"/>
<o:SmartTagType namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"place" downloadurl=3D"http://www.5iantlavalamp.com/"/>
<o:SmartTagType namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"PersonName" downloadurl=3D"http://www.microsoft.com"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"MS Mincho";
	panose-1:2 2 6 9 4 2 5 8 3 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:"\@MS Mincho";
	panose-1:2 2 6 9 4 2 5 8 3 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:blue;
	text-decoration:underline;}
pre
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
span.EmailStyle18
	{mso-style-type:personal;
	font-family:Arial;
	color:navy;}
span.EmailStyle19
	{mso-style-type:personal;
	font-family:Arial;
	color:navy;}
span.EmailStyle20
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dblue>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Hi Deborah,<o:p></o:p></span></font></=
p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

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 Req=
uirements
and Architecture specified in G.8080, G.7715 and G.7715.1. &nbsp;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.<o:p></o:p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Regards,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><st1:PersonName w:st=3D"on"><font size=3D2 color=3Dnavy
 face=3DArial><span style=3D'font-size:10.0pt;font-family:Arial;color:navy'=
>Jonathan
 Sadler</span></font></st1:PersonName><font size=3D2 color=3Dnavy face=3DAr=
ial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p></o:p></span><=
/font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font siz=
e=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span style=3D'font-si=
ze:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'> Brungard,
Deborah A, ALABS [mailto:dbrungard@att.com] <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Monday, July 24, 2006 =
4:31
PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Sadler, Jonathan B.; Ong,
Lyndon; ccamp@ops.ietf.org<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> Adrian Farrel<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: Proposed respon=
se to
OIF on OSPF ENNI</span></font><o:p></o:p></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Hi Jonathan,</span></font><o:p></o:p><=
/p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

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&nbsp;want to
ensure that the work is aligned.<o:p></o:p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Thanks,</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Deborah</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font siz=
e=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabIndex=3D-1>

</span></font></div>

From:=
=
 Sadler,
Jonathan B. [mailto:Jonathan.Sadler@tellabs.com] 
Sent: Monday, July 24, 2006 =
4:32
PM 
To: Brungard, Deborah A, ALA=
BS;
Ong, Lyndon; ccamp@ops.ietf.org 
Cc: Adrian Farrel 
Subject: RE: Proposed respon=
se to
OIF on OSPF ENNI<o:p></o:p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Hi Deborah, Lyndon, et al,<o:p></o:p><=
/span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Some additional comments:<o:p></o:p></=
span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;- The hierarchical model discuss=
ed
in the draft IA liaised may be supported without any modifications to
OSPF.&nbsp; As discussed in earlier emails, it can be implemented solely
through the import/export of information described in Appendix I of G.7715.=
<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;- The draft IA also recognizes
namespace issues exist between Router ID and the IP Address that messages a=
re
sent to (ITU calls this the RC PC SCN address).&nbsp; This issue is also
discussed in draft-ietf-ccamp-gmpls-addressing.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Given that:<o:p></o:p></span></font></=
p>

<p class=3DMsoNormal style=3D'margin-left:21.0pt;text-indent:-.25in'><font =
size=3D2
color=3Dnavy face=3DArial><span style=3D'font-size:10.0pt;font-family:Arial;
color:navy'>-</span></font><font size=3D1 color=3Dnavy><span style=3D'font-=
size:7.0pt;
color:navy'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span><=
/font><font
size=3D2 color=3Dnavy face=3DArial><span style=3D'font-size:10.0pt;font-fam=
ily:Arial;
color:navy'>CCAMP has a milestone to publish an ASON routing solution by Nov
2006, <o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:21.0pt;text-indent:-.25in'><font =
size=3D2
color=3Dnavy face=3DArial><span style=3D'font-size:10.0pt;font-family:Arial;
color:navy'>-</span></font><font size=3D1 color=3Dnavy><span style=3D'font-=
size:7.0pt;
color:navy'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span><=
/font><font
size=3D2 color=3Dnavy face=3DArial><span style=3D'font-size:10.0pt;font-fam=
ily:Arial;
color:navy'>CCAMP didn&#8217;t have at the time this was liaised (doesn&#82=
17;t
have today?) a working group document, and<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:21.0pt;text-indent:-.25in'><font =
size=3D2
color=3Dnavy face=3DArial><span style=3D'font-size:10.0pt;font-family:Arial;
color:navy'>-</span></font><font size=3D1 color=3Dnavy><span style=3D'font-=
size:7.0pt;
color:navy'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span><=
/font><font
size=3D2 color=3Dnavy face=3DArial><span style=3D'font-size:10.0pt;font-fam=
ily:Arial;
color:navy'>the draft IA has been successfully implemented by more than a d=
ozen
vendors and interop-tested many times,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>I would expect that we should be looki=
ng
at this as experience/text that could be leveraged...&nbsp; &#8220;Running
code&#8230;&#8221; and all that&#8230;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Regards,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><st1:PersonName w:st=3D"on"><font size=3D2 color=3Dnavy
 face=3DArial><span style=3D'font-size:10.0pt;font-family:Arial;color:navy'=
>Jonathan
 Sadler</span></font></st1:PersonName><font size=3D2 color=3Dnavy face=3DAr=
ial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p></o:p></span><=
/font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font siz=
e=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabIndex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span style=3D'font-si=
ze:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'> Ong, Lyn=
don
[mailto:Lyong@Ciena.com] <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Monday, July 24, 2006 =
2:33
PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Brungard, Deborah A, ALA=
BS;
Sadler, Jonathan B.; ccamp@ops.ietf.org<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> Adrian Farrel<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: Proposed respon=
se to
OIF on OSPF ENNI</span></font><o:p></o:p></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Hi Deborah,</span></font><o:p></o:p></=
p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Here's what I would say&nbsp;is in and=
 not
in the OIF document:</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>-- G.7715, G.7715.1 and the IETF eval =
and
solutions draft all identify a need to support hierarchical</span></font><o=
:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>routing areas for ASON, I am perplexed=
 as
to why this seems to be viewed as a new feature.</span></font><o:p></o:p></=
p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>-- the document does not specify the
domain of usage and leaves this to the carrier.&nbsp; This is no different<=
/span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>from G.7715.1 and IETF drafts that do =
not
explicitly state whether they are used for intra- or inter-domain</span></f=
ont><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>interfaces.</span></font><o:p></o:p></=
p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>-- GMPLS OSPF does not support a 1:N or
N:1 relationship between routing controller and transport</span></font><o:p=
></o:p></p>

node, hence extensions are felt to be
required - and are proposed in the eval solutions draft. The =
<o:p></o:p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>conclusions are no different.</span></=
font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>-- the document does not in fact define
any standard extensions to the protocols, and points to future work</span><=
/font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>in IETF and ITU to provide these.&nbsp;
Therefore I cannot understand where you say &quot;new extensions to</span><=
/font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>OSPF are specified&quot; and
&quot;none...align with the CCAMP's GMPLS-ASON work&quot;.&nbsp; </span></f=
ont><o:p></o:p></p>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>I think we're experiencing a significa=
nt
miscommunication...</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Cheers,</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Lyndon</span></font><o:p></o:p></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font siz=
e=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabIndex=3D-1>

</span></font></div>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><b><font size=3D2 face=
=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma;font-weight:bold'>From:</span>=
</font></b><font
size=3D2 face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'>
owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] <b><span
style=3D'font-weight:bold'>On Behalf Of </span></b>Brungard, Deborah A, ALA=
BS<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Monday, July 24, 2006 =
12:15
PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Sadler, Jonathan B.; cca=
mp@ops.ietf.org<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> Adrian Farrel<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: Proposed respon=
se to
OIF on OSPF ENNI</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Hi Jonathan, (and Lyndon),</span></fon=
t><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Thanks to both of you for responding.<=
/span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>&quot;Significant&quot; was referencin=
g:</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>- supports&nbsp;a&nbsp;(new) hierarchi=
cal
OSPF model</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>-&nbsp;supports&nbsp;inter-domain (int=
er-carrier)
OSPF (not supported by today's OSPF)</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>- identifies namespace issues with GMP=
LS
OSPF which do not exist, and proposes extensions to &quot;fix&quot;</span><=
/font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>- new extensions to OSPF are specified=
</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>- none of the proposed extensions align
with CCAMP's GMPLS-ASON work</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

Did you have another adjective to sugg=
est?
We&nbsp;were thinking&nbsp;&quot;significant&quot; 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 (ali=
gnment
mapping to CCAMP's work) which you or Lyndon can provide would be
helpful.&nbsp;The divergence is&nbsp;baffling to us.<o:p></o:=
p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Deborah</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font siz=
e=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabIndex=3D-1>

</span></font></div>

From:=
=
 Sadler,
Jonathan B. [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<o:p></o:p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Hi Deborah and Adrian,<o:p></o:p></spa=
n></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

I haven&#8217;t seen much discussion of
the OIF E-NNI Routing document on the CCAMP list. &nbsp;Can you tell me what
parts of the document are &#8220;significant modifications to the operation=
 of
OSPF&#8221;?<o:p></o:p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Thanks,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><st1:PersonName w:st=3D"on"><font size=3D2 color=3Dnavy
 face=3DArial><span style=3D'font-size:10.0pt;font-family:Arial;color:navy'=
>Jonathan
 Sadler</span></font></st1:PersonName><font size=3D2 color=3Dnavy face=3DAr=
ial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p></o:p></span><=
/font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font siz=
e=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabIndex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span style=3D'font-si=
ze:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'>
owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] <b><span
style=3D'font-weight:bold'>On Behalf Of </span></b>Brungard, Deborah A, ALA=
BS<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Friday, July 21, 2006 =
9:38
AM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> ccamp@ops.ietf.org<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> Adrian Farrel<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> Proposed response t=
o OIF
on OSPF ENNI</span></font><o:p></o:p></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Hi,</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

We had a communication from OIF on the=
ir
OSPF ENNI specification. You can see the original files on <a
href=3D"http://www.olddog.co.uk/ccamp.htm">http://www.olddog.co.uk/ccamp.=
htm</a>. Having assembled comments from several people and our discuss=
ions
in <st1:place w:st=3D"on"><st1:City w:st=3D"on">Montreal</st1:City></st1:pl=
ace>, we
have put together the following response.<o:p></o:p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Please comment on the list in the next
week.</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Thanks,</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Adrian and Deborah</span></font><o:p><=
/o:p></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>=3D =3D =3D =3D =3D =3D =3D =3D =3D =3D<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>Dear Jim,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

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.<o:p></o:p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

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: <a
href=3D"ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpls-ason-routi=
ng-eval-03.txt">ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpls-as=
on-routing-eval-03.txt</a>.
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&#8217;s work, we recommend that you either utilize the CCAMP mail expl=
oder
or send a communication.<o:p></o:p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>Specific comments include:<o:p></o:p></span></font></p>

1.<=
font
size=3D1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </s=
pan>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></o:p>

<p class=3DMsoNormal style=3D'margin-left:.25in;text-indent:-.25in'><i><font
size=3D3 face=3D"Times New Roman"><span style=3D'font-size:12.0pt;font-styl=
e:italic'>2.</span></font></i><i><font
size=3D1><span style=3D'font-size:7.0pt;font-style:italic'>&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;
</span></font></i>The list of changes from the previous version (listed und=
er
the Table of Contents) includes &#8220;<i><span style=3D'font-style:italic'=
>removed
&#8220;intra-carrier&#8221; limitation</span></i>&#8221; 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. <b=
r>
The IETF&#8217;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&#8217;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.<i><span style=3D'font-style:i=
talic'><o:p></o:p></span></i></p>

3.<=
font
size=3D1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </s=
pan>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.<o:p></o:p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>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.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>Best regards,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><st1:PersonName w:st=3D"on"><font size=3D3 face=3D"Tim=
es New Roman"><span
 style=3D'font-size:12.0pt'>Adrian Farrel</span></font></st1:PersonName> and
Deborah Brungard,<o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>CCAMP co-chairs<o:p></o:p></span></font></p>

</div>

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

<pre>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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
</pre></body>

</html>

------_=_NextPart_001_01C6AF69.D7935803--

Envelope-to: ccamp-data@psg.com
Delivery-date: Mon, 24 Jul 2006 21:31:32 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6AF68.7FFC9299"
Subject: RE: Proposed response to OIF on OSPF ENNI
Date: Mon, 24 Jul 2006 16:31:17 -0500
Message-ID: <449B2580D802A443A923DABF3EAB82AF0C72C0D0@OCCLUST04EVS1.ugd.att.com>
Thread-Topic: Proposed response to OIF on OSPF ENNI
Thread-Index: Acas0Ha/aYxFikOBS5m873SVRoVJxgAACLxQAAHPZJAAnZ89IAACGznwAAEH8mAAAxLNQA==
From: "Brungard, Deborah A, ALABS" <dbrungard@att.com>
To: "Sadler, Jonathan B." <Jonathan.Sadler@tellabs.com>, "Ong, Lyndon" <Lyong@Ciena.com>, <ccamp@ops.ietf.org>
Cc: "Adrian Farrel" <adrian@olddog.co.uk>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6AF68.7FFC9299
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Jonathan,
=20
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.
=20
Thanks,
Deborah

________________________________

From: Sadler, Jonathan B. [mailto:Jonathan.Sadler@tellabs.com]=20
Sent: Monday, July 24, 2006 4:32 PM
To: Brungard, Deborah A, ALABS; Ong, Lyndon; ccamp@ops.ietf.org
Cc: Adrian Farrel
Subject: RE: Proposed response to OIF on OSPF ENNI

Hi Deborah, Lyndon, et al,

=20

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.

=20

Given that:

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

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

=20

Regards,

=20

Jonathan Sadler

=20

________________________________

From: Ong, Lyndon [mailto:Lyong@Ciena.com]=20
Sent: Monday, July 24, 2006 2: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

=20

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

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

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

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

=20

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

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

=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_01C6AF68.7FFC9299
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:v =3D=20
"urn:schemas-microsoft-com:vml" xmlns:o =3D=20
"urn:schemas-microsoft-com:office:office" xmlns:w =3D=20
"urn:schemas-microsoft-com:office:word" xmlns:p =3D=20
"urn:schemas-microsoft-com:office:powerpoint" xmlns:oa =3D=20
"urn:schemas-microsoft-com:office:activation" xmlns:st1 =3D=20
"urn:schemas-microsoft-com:office:smarttags"><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.2914" name=3DGENERATOR><!--[if !mso]>
<STYLE>v\:* {
	BEHAVIOR: url(#default#VML)
}
o\:* {
	BEHAVIOR: url(#default#VML)
}
w\:* {
	BEHAVIOR: url(#default#VML)
}
.shape {
	BEHAVIOR: url(#default#VML)
}
</STYLE>
<![endif]--><o:SmartTagType=20
downloadurl=3D"http://www.5iamas-microsoft-com:office:smarttags" =
name=3D"City"=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTagT=
ype><o:SmartTagType=20
downloadurl=3D"http://www.5iantlavalamp.com/" name=3D"place"=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTagT=
ype><o:SmartTagType=20
downloadurl=3D"http://www.microsoft.com" name=3D"PersonName"=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTagT=
ype><!--[if !mso]>
<STYLE>st1\:* {
	BEHAVIOR: url(#default#ieooui)
}
</STYLE>
<![endif]-->
<STYLE>@font-face {
	font-family: Wingdings;
}
@font-face {
	font-family: MS Mincho;
}
@font-face {
	font-family: Tahoma;
}
@font-face {
	font-family: @MS Mincho;
}
@page Section1 {size: 8.5in 11.0in; margin: 1.0in 1.25in 1.0in 1.25in; }
P.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
LI.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
DIV.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline
}
A:visited {
	COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlinkFollowed {
	COLOR: blue; TEXT-DECORATION: underline
}
PRE {
	FONT-SIZE: 10pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Courier New"
}
SPAN.EmailStyle17 {
	COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal
}
SPAN.EmailStyle19 {
	COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal-reply
}
DIV.Section1 {
	page: Section1
}
OL {
	MARGIN-BOTTOM: 0in
}
UL {
	MARGIN-BOTTOM: 0in
}
</STYLE>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]--></HEAD>
<BODY lang=3DEN-US vLink=3Dblue link=3Dblue>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D279482121-24072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Hi Jonathan,</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D279482121-24072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D279482121-24072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>I just sent mail to Lyndon to ask if he felt =
CCAMP's work=20
was aligned. From your mail below, you do believe that CCAMP's ASON =
requirements=20
document and evaluation document meet the needs of OIF? As the OIF =
Liaison=20
stated it specified requirements, we do&nbsp;want to ensure that the =
work is=20
aligned.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D279482121-24072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D279482121-24072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Thanks,</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D279482121-24072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Deborah</FONT></SPAN></DIV><BR>
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
<HR tabIndex=3D-1>
<FONT face=3DTahoma size=3D2><B>From:</B> Sadler, Jonathan B.=20
[mailto:Jonathan.Sadler@tellabs.com] <BR><B>Sent:</B> Monday, July 24, =
2006 4:32=20
PM<BR><B>To:</B> Brungard, Deborah A, ALABS; Ong, Lyndon;=20
ccamp@ops.ietf.org<BR><B>Cc:</B> Adrian Farrel<BR><B>Subject:</B> RE: =
Proposed=20
response to OIF on OSPF ENNI<BR></FONT><BR></DIV>
<DIV></DIV>
<DIV class=3DSection1>
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Hi Deborah, =
Lyndon, et=20
al,<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Some =
additional=20
comments:<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">&nbsp;- The=20
hierarchical model discussed in the draft IA liaised may be supported =
without=20
any modifications to OSPF.&nbsp; As discussed in earlier emails, it can =
be=20
implemented solely through the import/export of information described in =

Appendix I of G.7715.<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">&nbsp;- The =
draft IA=20
also recognizes namespace issues exist between Router ID and the IP =
Address that=20
messages are sent to (ITU calls this the RC PC SCN address).&nbsp; This =
issue is=20
also discussed in=20
draft-ietf-ccamp-gmpls-addressing.<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Given=20
that:<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal=20
style=3D"MARGIN-LEFT: 21pt; TEXT-INDENT: -0.25in; mso-list: l0 level1 =
lfo1"><![if !supportLists]><FONT=20
face=3DArial color=3Dnavy size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><SPAN=20
style=3D"mso-list: Ignore">-<FONT face=3D"Times New Roman" =
size=3D1><SPAN=20
style=3D"FONT: 7pt 'Times New =
Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></FONT></SPAN></SPAN></FONT><![endif]><FONT face=3DArial =
color=3Dnavy=20
size=3D2><SPAN style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">CCAMP has=20
a milestone to publish an ASON routing solution by Nov 2006,=20
<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal=20
style=3D"MARGIN-LEFT: 21pt; TEXT-INDENT: -0.25in; mso-list: l0 level1 =
lfo1"><![if !supportLists]><FONT=20
face=3DArial color=3Dnavy size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><SPAN=20
style=3D"mso-list: Ignore">-<FONT face=3D"Times New Roman" =
size=3D1><SPAN=20
style=3D"FONT: 7pt 'Times New =
Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></FONT></SPAN></SPAN></FONT><![endif]><FONT face=3DArial =
color=3Dnavy=20
size=3D2><SPAN style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">CCAMP=20
didn&#8217;t have at the time this was liaised (doesn&#8217;t have =
today?) a working group=20
document, and<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal=20
style=3D"MARGIN-LEFT: 21pt; TEXT-INDENT: -0.25in; mso-list: l0 level1 =
lfo1"><![if !supportLists]><FONT=20
face=3DArial color=3Dnavy size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><SPAN=20
style=3D"mso-list: Ignore">-<FONT face=3D"Times New Roman" =
size=3D1><SPAN=20
style=3D"FONT: 7pt 'Times New =
Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></FONT></SPAN></SPAN></FONT><![endif]><FONT face=3DArial =
color=3Dnavy=20
size=3D2><SPAN style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">the draft=20
IA has been successfully implemented by more than a dozen vendors and=20
interop-tested many times,<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">I would =
expect that we=20
should be looking at this as experience/text that could be =
leveraged...&nbsp;=20
&#8220;Running code&#8230;&#8221; and all =
that&#8230;<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">Regards,<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=3DMsoNormal><st1:PersonName w:st=3D"on"><FONT face=3DArial =
color=3Dnavy=20
size=3D2><SPAN style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">Jonathan=20
Sadler</SPAN></FONT></st1:PersonName><FONT face=3DArial color=3Dnavy =
size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<DIV>
<DIV class=3DMsoNormal style=3D"TEXT-ALIGN: center" align=3Dcenter><FONT =

face=3D"Times New Roman" size=3D3>
<HR tabIndex=3D-1 align=3Dcenter width=3D"100%" SIZE=3D2>
</DIV>
<SPAN=20
style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma">From:<FONT=20
face=3DTahoma size=3D2> Ong,=20
Lyndon [mailto:Lyong@Ciena.com] <SPAN=20
style=3D"FONT-WEIGHT: bold">Sent: Monday, July 24, 2006 2:33=20
PM To: Brungard, =
Deborah A,=20
ALABS; Sadler, Jonathan B.; ccamp@ops.ietf.org <SPAN=20
style=3D"FONT-WEIGHT: bold">Cc: Adrian Farrel <SPAN=20
style=3D"FONT-WEIGHT: bold">Subject: RE: Proposed response to =
OIF on=20
OSPF ENNI<o:p></o:p></DIV>
<SPAN=20
style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Hi=20
Deborah,<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Here's what I =
would=20
say&nbsp;is in and not in the OIF document:<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">-- G.7715, =
G.7715.1 and=20
the IETF eval and solutions draft all identify a need to support=20
hierarchical<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">routing areas =
for ASON,=20
I am perplexed as to why this seems to be viewed as a new=20
feature.<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">-- the =
document does=20
not specify the domain of usage and leaves this to the carrier.&nbsp; =
This is no=20
different<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">from G.7715.1 =
and IETF=20
drafts that do not explicitly state whether they are used for intra- or=20
inter-domain<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
Arial">interfaces.<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">-- GMPLS OSPF =
does not=20
support a 1:N or N:1 relationship between routing controller and=20
transport<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">node, hence =
extensions=20
are felt to be required - and are proposed in the eval solutions draft. =
The=20
<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">conclusions =
are no=20
different.<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">-- the =
document does=20
not in fact define any standard extensions to the protocols, and points =
to=20
future work<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">in IETF and =
ITU to=20
provide these.&nbsp; Therefore I cannot understand where you say "new =
extensions=20
to<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">OSPF are =
specified" and=20
"none...align with the CCAMP's GMPLS-ASON work".&nbsp;=20
<o:p></o:p>
<DIV>
<SPAN=20
style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p></DIV>
<DIV>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">I think we're =

experiencing a significant=20
miscommunication...</SPAN></FONT><o:p></o:p></P></DIV>
<DIV>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p></SPAN></FONT></P></DIV>
<DIV>
<P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
Arial">Cheers,</SPAN></FONT><o:p></o:p></P></DIV>
<DIV>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p></SPAN></FONT></P></DIV>
<DIV>
<P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
Arial">Lyndon</SPAN></FONT><o:p></o:p></P></DIV>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<DIV class=3DMsoNormal style=3D"TEXT-ALIGN: center" align=3Dcenter><FONT =

face=3D"Times New Roman" size=3D3><SPAN style=3D"FONT-SIZE: 12pt">
<HR tabIndex=3D-1 align=3Dcenter width=3D"100%" SIZE=3D2>
</SPAN></FONT></DIV>
<P class=3DMsoNormal style=3D"MARGIN-BOTTOM: 12pt"><B><FONT =
face=3DTahoma size=3D2><SPAN=20
style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma">From:</SPAN></FONT></B><FONT=20
face=3DTahoma size=3D2><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma">=20
owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] <B><SPAN=20
style=3D"FONT-WEIGHT: bold">On Behalf Of </SPAN></B>Brungard, Deborah A, =

ALABS Sent: Monday, =
July 24,=20
2006 12:15 PM To: =
Sadler,=20
Jonathan B.; ccamp@ops.ietf.org <SPAN=20
style=3D"FONT-WEIGHT: bold">Cc: Adrian Farrel <SPAN=20
style=3D"FONT-WEIGHT: bold">Subject: RE: Proposed response to =
OIF on=20
OSPF ENNI<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Hi Jonathan, =
(and=20
Lyndon),<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Thanks to =
both of you=20
for responding.<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">"Significant" =
was=20
referencing:<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">-=20
supports&nbsp;a&nbsp;(new) hierarchical OSPF =
model<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
Arial">-&nbsp;supports&nbsp;inter-domain=20
(inter-carrier) OSPF (not supported by today's=20
OSPF)<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">- identifies =
namespace=20
issues with GMPLS OSPF which do not exist, and proposes extensions to=20
"fix"<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">- new =
extensions to=20
OSPF are specified<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">- none of the =
proposed=20
extensions align with CCAMP's GMPLS-ASON =
work<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Did you have =
another=20
adjective to suggest? We&nbsp;were thinking&nbsp;"significant" was =
rather soft=20
considering the above. Though if it's just ITU-speak differences, why =
does the=20
OIF liaison state it reflects several years of work including testing? =
Any=20
insight (alignment mapping to CCAMP's work) which you or Lyndon can =
provide=20
would be helpful.&nbsp;The divergence is&nbsp;baffling to=20
us.<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
Arial">Deborah<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p>
<DIV class=3DMsoNormal style=3D"TEXT-ALIGN: center" align=3Dcenter><FONT =

face=3D"Times New Roman" size=3D3><SPAN style=3D"FONT-SIZE: 12pt">
<HR tabIndex=3D-1 align=3Dcenter width=3D"100%" SIZE=3D2>
</SPAN></FONT></DIV>
<P class=3DMsoNormal style=3D"MARGIN-BOTTOM: 12pt"><B><FONT =
face=3DTahoma size=3D2><SPAN=20
style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma">From:</SPAN></FONT></B><FONT=20
face=3DTahoma size=3D2><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma"> Sadler,=20
Jonathan B. [mailto:Jonathan.Sadler@tellabs.com] <BR><B><SPAN=20
style=3D"FONT-WEIGHT: bold">Sent:</SPAN></B> Friday, July 21, 2006 11:34 =

AM To: Brungard, =
Deborah A,=20
ALABS; ccamp@ops.ietf.org Cc:=20
Adrian Farrel Subject: RE:=20
Proposed response to OIF on OSPF ENNI<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Hi Deborah =
and=20
Adrian,<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">I =
haven&#8217;t seen much=20
discussion of the OIF E-NNI Routing document on the CCAMP list. =
&nbsp;Can you=20
tell me what parts of the document are &#8220;significant modifications =
to the=20
operation of OSPF&#8221;?<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">Thanks,<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p>
<st1:PersonName w:st=3D"on">Jonathan=20
Sadler</st1:PersonName><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p>
<DIV>
<DIV class=3DMsoNormal style=3D"TEXT-ALIGN: center" align=3Dcenter><FONT =

face=3D"Times New Roman" size=3D3><SPAN style=3D"FONT-SIZE: 12pt">
<HR tabIndex=3D-1 align=3Dcenter width=3D"100%" SIZE=3D2>
</SPAN></FONT></DIV>
<P class=3DMsoNormal><B><FONT face=3DTahoma size=3D2><SPAN=20
style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma">From:</SPAN></FONT></B><FONT=20
face=3DTahoma size=3D2><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma">=20
owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] <B><SPAN=20
style=3D"FONT-WEIGHT: bold">On Behalf Of </SPAN></B>Brungard, Deborah A, =

ALABS<BR><B><SPAN style=3D"FONT-WEIGHT: bold">Sent:</SPAN></B> Friday, =
July 21,=20
2006 9:38 AM<BR><B><SPAN style=3D"FONT-WEIGHT: bold">To:</SPAN></B>=20
ccamp@ops.ietf.org<BR><B><SPAN style=3D"FONT-WEIGHT: =
bold">Cc:</SPAN></B> Adrian=20
Farrel<BR><B><SPAN style=3D"FONT-WEIGHT: bold">Subject:</SPAN></B> =
Proposed=20
response to OIF on OSPF ENNI</SPAN></FONT><o:p></o:p></P></DIV>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
Arial">Hi,</SPAN></FONT><o:p></o:p></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">We had a =
communication=20
from OIF on their OSPF ENNI specification. You can see the original =
files on=20
</SPAN></FONT><A href=3D"http://www.olddog.co.uk/ccamp.htm"><FONT =
face=3DArial=20
size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial">http://www.olddog.co.uk/ccamp.htm</SPAN></FONT></A><FONT=20
face=3DArial color=3Dblue size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">. Having =
assembled=20
comments from several people and our discussions in <st1:place=20
w:st=3D"on"><st1:City w:st=3D"on">Montreal</st1:City></st1:place>, we =
have put=20
together the following response.</SPAN></FONT><o:p></o:p></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p></SPAN></FONT></P>
<DIV>
<P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Please =
comment on the=20
list in the next week.</SPAN></FONT><o:p></o:p></P></DIV>
<DIV>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p></SPAN></FONT></P></DIV>
<DIV>
<P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
Arial">Thanks,</SPAN></FONT><o:p></o:p></P></DIV>
<DIV>
<P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Adrian and=20
Deborah</SPAN></FONT><o:p></o:p></P></DIV>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p></SPAN></FONT></P>
<DIV>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">=3D =3D =3D =3D =3D =3D =3D =3D =3D =
=3D<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">Dear Jim,<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">We thank you for sending us the OIF ENNI =
document in=20
response to our request. While we appreciate the document being provided =
for=20
information, it is concerning that this document has not been previously =
shared=20
with CCAMP or the OSPF WG considering the document contains significant=20
modifications to the operation of OSPF and reflects OIF work over the =
last=20
several years. CCAMP has been working on GMPLS ASON for several years =
and our=20
Design Teams include OIF participants. Even though a reply was not =
requested, we=20
are replying, as we strongly recommend that the document not be =
published for=20
public information in its current form.<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">Of most concern to CCAMP is that it is not =
aligned with=20
RFC 4258 (Requirements for Generalized Multi-Protocol Label Switching =
(GMPLS)=20
Routing for the Automatically Switched Optical Network (ASON)) or the=20
to-be-published: <A=20
href=3D"ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpls-ason-rou=
ting-eval-03.txt">ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpl=
s-ason-routing-eval-03.txt</A>.=20
Considering notable OIF participants are authors of both these IETF =
documents=20
(and the same participants are contributors and the Editor for the OIF=20
document), the non-alignment is perplexing. Considering the IETF =
document is=20
ready for publication, we suggest in the interests of time, that you =
align your=20
document with the IETF document. If any questions on the interpretation =
of the=20
IETF&#8217;s work, we recommend that you either utilize the CCAMP mail =
exploder or=20
send a communication.<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">Specific comments =
include:<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal style=3D"MARGIN-LEFT: 0.25in; TEXT-INDENT: =
-0.25in"><FONT=20
face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">1.</SPAN></FONT><FONT size=3D1><SPAN=20
style=3D"FONT-SIZE: 7pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</SPAN></FONT>What is the=20
intent of this document? Will it be published as an Implementation =
Agreement=20
(IA)?<BR>The title indicates it will be an Implementation Agreement on =
GMPLS=20
OSPF extensions, but the main body of the document is a list of issues =
with=20
GMPLS OSPF. Further, your communication to us stated the document was=20
requirements on and use of OSPF-TE at the ENNI. These three views seem =
to be=20
inconsistent.<o:p></o:p></P>
<P class=3DMsoNormal style=3D"MARGIN-LEFT: 0.25in; TEXT-INDENT: =
-0.25in"><I><FONT=20
face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-STYLE: =
italic">2.</SPAN></FONT></I><I><FONT=20
size=3D1><SPAN=20
style=3D"FONT-SIZE: 7pt; FONT-STYLE: =
italic">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></FONT></I>The list of changes from the previous version (listed =
under=20
the Table of Contents) includes &#8220;<I><SPAN style=3D"FONT-STYLE: =
italic">removed=20
&#8220;intra-carrier&#8221; limitation</SPAN></I>&#8221; and the =
inclusion of Figure 1 showing the=20
OSPF ENNI for use between vendor domains and between carrier domains. =
GMPLS=20
OSPF-TE already supports inter-vendor operations. <BR>The IETF&#8217;s =
GMPLS ASON=20
routing focus has been on the use of a link-state based protocol to =
support a=20
hierarchical routing architecture (G.7715.1) within a carrier&#8217;s =
domain.=20
Requirements for using a link state protocol as an inter-domain protocol =
between=20
carriers are significantly different. We strongly disagree if you intend =
to=20
publish this document as an inter-carrier OSPF ENNI Implementation =
Agreement=20
claiming alignment with IETF RFCs without review (or agreement) by any =
of the=20
IETF Working Groups.<I><SPAN=20
style=3D"FONT-STYLE: italic"><o:p></o:p></SPAN></I></P>
<P class=3DMsoNormal style=3D"MARGIN-LEFT: 0.25in; TEXT-INDENT: =
-0.25in"><FONT=20
face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">3.</SPAN></FONT><FONT size=3D1><SPAN=20
style=3D"FONT-SIZE: 7pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</SPAN></FONT>Section=20
4.1/Table 1 and the statement under the table identifying issues with =
GMPLS=20
identifier namespaces are not correct. GMPLS identifier namespaces do =
meet ASON=20
requirements for namespace separation of the transport plane and control =
plane=20
(Section 5.2 and 5.3/Evaluation). Perhaps you are confusing OSPF and =
GMPLS OSPF?=20
As you also identified in your liaison that the key area needing review =
was the=20
support of independence of functional component to physical location, =
this=20
appears to be a key area of misunderstanding on GMPLS. We recommend =
reviewing=20
RFC3945 (GMPLS Architecture) to understand that the key architecture =
difference=20
between GMPLS and MPLS is the decoupling of the transport plane and =
control=20
plane. Additionally, RFC4394, RFC4397, and RFC4258, provide a mapping to =
ITU=20
terminology which may be helpful reading.<o:p></o:p></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">We request an additional round of =
communication of this=20
document to the IETF before approval to allow us to work with you to =
produce=20
convergence between OIF and IETF work which, we believe, will be in the =
best=20
interests of the industry.<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">Best regards,<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><st1:PersonName w:st=3D"on"><FONT face=3D"Times New =
Roman"=20
size=3D3><SPAN style=3D"FONT-SIZE: 12pt">Adrian=20
Farrel</SPAN></FONT></st1:PersonName> and Deborah =
Brungard,<o:p></o:p></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">CCAMP =
co-chairs<o:p></o:p></SPAN></FONT></P></DIV><PRE><FONT face=3D"Courier =
New" size=3D2><SPAN style=3D"FONT-SIZE: =
10pt">=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<o:p></o:p></SPAN></FONT></PRE><PRE><=
FONT face=3D"Courier New" size=3D2><SPAN style=3D"FONT-SIZE: 10pt">The =
information contained in this message may be =
privileged<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
size=3D2><SPAN style=3D"FONT-SIZE: 10pt">and confidential and protected =
from disclosure. If the reader<o:p></o:p></SPAN></FONT></PRE><PRE><FONT =
face=3D"Courier New" size=3D2><SPAN style=3D"FONT-SIZE: 10pt">of this =
message is not the intended recipient, or an =
employee<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
size=3D2><SPAN style=3D"FONT-SIZE: 10pt">or agent responsible for =
delivering this message to the<o:p></o:p></SPAN></FONT></PRE><PRE><FONT =
face=3D"Courier New" size=3D2><SPAN style=3D"FONT-SIZE: 10pt">intended =
recipient, you are hereby notified that any =
reproduction,<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier =
New" size=3D2><SPAN style=3D"FONT-SIZE: 10pt">dissemination or =
distribution of this communication is =
strictly<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
size=3D2><SPAN style=3D"FONT-SIZE: 10pt">prohibited. If you have =
received this communication in =
error,<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
size=3D2><SPAN style=3D"FONT-SIZE: 10pt">please notify us immediately by =
replying to the message and<o:p></o:p></SPAN></FONT></PRE><PRE><FONT =
face=3D"Courier New" size=3D2><SPAN style=3D"FONT-SIZE: 10pt">deleting =
it from your computer. Thank you. =
Tellabs<o:p></o:p></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
size=3D2><SPAN style=3D"FONT-SIZE: =
10pt">=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<o:p></o:p></SPAN></FONT></PRE></DIV>=
<PRE>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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
</PRE></BODY></HTML>

------_=_NextPart_001_01C6AF68.7FFC9299--

Envelope-to: ccamp-data@psg.com
Delivery-date: Mon, 24 Jul 2006 21:22:17 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6AF67.28CCE0D0"
Subject: RE: Proposed response to OIF on OSPF ENNI
Date: Mon, 24 Jul 2006 16:21:41 -0500
Message-ID: <449B2580D802A443A923DABF3EAB82AF0C72C0BC@OCCLUST04EVS1.ugd.att.com>
Thread-Topic: Proposed response to OIF on OSPF ENNI
Thread-Index: Acas0Ha/aYxFikOBS5m873SVRoVJxgAACLxQAAHPZJAAnZ89IAACGznwAAEdy+A=
From: "Brungard, Deborah A, ALABS" <dbrungard@att.com>
To: "Ong, Lyndon" <Lyong@Ciena.com>, "Sadler, Jonathan B." <Jonathan.Sadler@tellabs.com>, <ccamp@ops.ietf.org>
Cc: "Adrian Farrel" <adrian@olddog.co.uk>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6AF67.28CCE0D0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

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

________________________________

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

________________________________

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

________________________________

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

=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

------_=_NextPart_001_01C6AF67.28CCE0D0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:v =3D=20
"urn:schemas-microsoft-com:vml" xmlns:o =3D=20
"urn:schemas-microsoft-com:office:office" xmlns:w =3D=20
"urn:schemas-microsoft-com:office:word" xmlns:p =3D=20
"urn:schemas-microsoft-com:office:powerpoint" xmlns:oa =3D=20
"urn:schemas-microsoft-com:office:activation" xmlns:st1 =3D=20
"urn:schemas-microsoft-com:office:smarttags" xmlns:ns0 =3D=20
"urn:schemas-microsoft-com:office:smarttags"><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.2914" name=3DGENERATOR><!--[if !mso]>
<STYLE>v\:* {
	BEHAVIOR: url(#default#VML)
}
o\:* {
	BEHAVIOR: url(#default#VML)
}
w\:* {
	BEHAVIOR: url(#default#VML)
}
.shape {
	BEHAVIOR: url(#default#VML)
}
</STYLE>
<![endif]--><o:SmartTagType=20
downloadurl=3D"http://www.5iamas-microsoft-com:office:smarttags" =
name=3D"City"=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTagT=
ype><o:SmartTagType=20
downloadurl=3D"http://www.5iantlavalamp.com/" name=3D"place"=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTagT=
ype><o:SmartTagType=20
downloadurl=3D"http://www.microsoft.com" name=3D"PersonName"=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTagT=
ype><!--[if !mso]>
<STYLE>st1\:* {
	BEHAVIOR: url(#default#ieooui)
}
</STYLE>
<![endif]-->
<STYLE>@font-face {
	font-family: MS Mincho;
}
@font-face {
	font-family: Tahoma;
}
@font-face {
	font-family: @MS Mincho;
}
@page Section1 {size: 8.5in 11.0in; margin: 1.0in 1.25in 1.0in 1.25in; }
P.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
LI.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
DIV.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline
}
A:visited {
	COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlinkFollowed {
	COLOR: blue; TEXT-DECORATION: underline
}
SPAN.EmailStyle17 {
	COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal-reply
}
DIV.Section1 {
	page: Section1
}
</STYLE>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]--></HEAD>
<BODY lang=3DEN-US vLink=3Dblue link=3Dblue>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D749145619-24072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>below (noted as db&gt;)...</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D749145619-24072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D749145619-24072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Lyndon, do you think the OIF document and =
CCAMP's ASON=20
Requirements and Evaluation document are aligned?</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D749145619-24072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D749145619-24072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Thanks,</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D749145619-24072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Deborah</FONT></SPAN></DIV><BR>
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
<HR tabIndex=3D-1>
<FONT face=3DTahoma size=3D2><B>From:</B> Ong, Lyndon =
[mailto:Lyong@Ciena.com]=20
<BR><B>Sent:</B> Monday, July 24, 2006 3:33 PM<BR><B>To:</B> Brungard, =
Deborah=20
A, ALABS; Sadler, Jonathan B.; ccamp@ops.ietf.org<BR><B>Cc:</B> Adrian=20
Farrel<BR><B>Subject:</B> RE: Proposed response to OIF on OSPF=20
ENNI<BR></FONT><BR></DIV>
<DIV></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D839162419-24072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Hi Deborah,</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D839162419-24072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D839162419-24072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Here's what I would say&nbsp;is in and not in =
the OIF=20
document:</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D839162419-24072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D839162419-24072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>-- G.7715, G.7715.1 and the IETF eval and =
solutions draft=20
all identify a need to support hierarchical</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D839162419-24072006><FONT =
face=3DArial><FONT=20
color=3D#0000ff><FONT size=3D2>routing areas for ASON, I am perplexed as =
to why this=20
seems to be viewed as a new feature.<SPAN=20
class=3D749145619-24072006>&nbsp;</SPAN></FONT></FONT></FONT></SPAN></DIV=
>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D839162419-24072006><FONT =
face=3DArial><FONT=20
color=3D#0000ff><FONT size=3D2><SPAN class=3D749145619-24072006>db&gt; =
"significant"=20
was not based on "newness" as a feature, it was based on what GMPLS OSPF =
can=20
support today.</SPAN></FONT></FONT></FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D839162419-24072006><FONT =
face=3DArial><FONT=20
color=3D#0000ff><FONT size=3D2><SPAN=20
class=3D749145619-24072006>&nbsp;</SPAN></FONT></FONT></FONT></SPAN></DIV=
>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D839162419-24072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>-- the document does not specify the domain of =
usage and=20
leaves this to the carrier.&nbsp; This is no =
different</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D839162419-24072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>from G.7715.1 and IETF drafts that do not =
explicitly state=20
whether they are used for intra- or inter-domain</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D839162419-24072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>interfaces.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D839162419-24072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2><SPAN class=3D749145619-24072006>db&gt; =
G.7715.1 is on=20
requirements for link state protocols - it does not define requirements =
for=20
inter-carrier ENNI routing protocols. And, I differ with your view on =
IETF=20
documents, IETF documents do specify. And this OIF document also=20
specifies&nbsp;- Figure&nbsp;1 shows it for use between Carriers. The =
document=20
may "leave it to the carrier", but OIF&nbsp;claims it can do. I would =
presuppose=20
an Implementation Agreement would properly scope the solution.=20
Inter-carrier&nbsp;was&nbsp;not included in the ASON-GMPLS routing =
requirements.=20
Do you think the same solution can be used=20
inter-carrier?</SPAN></FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D839162419-24072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2><SPAN=20
class=3D749145619-24072006></SPAN></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D839162419-24072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>-- GMPLS OSPF does not support a 1:N or N:1 =
relationship=20
between routing controller and transport</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D839162419-24072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>node, hence extensions are felt to be required =
- and are=20
proposed in the eval solutions draft. The </FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D839162419-24072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>conclusions are no =
different.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D839162419-24072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2><SPAN class=3D749145619-24072006>db&gt; =
GMPLS-ASON did not=20
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".=20
The only GMPLS-ASON identified need was&nbsp;if non-unique link =
IDs (e.g.=20
unnumbered) were supported, an optional TLV was identified which =
could be=20
used. Note, GMPLS links are not representing&nbsp;"data plane" (RFC4394 =
provides=20
a good mapping of terminology).&nbsp;And, this was not based on the =
issue which=20
OIF identified in section 4.2, "identifier namespaces are merged =
together" in=20
GMPLS.</DIV>
<DIV dir=3Dltr align=3Dleft>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft>-- the document does not in fact define any =
standard=20
extensions to the protocols, and points to future =
work</DIV>
<DIV dir=3Dltr align=3Dleft>in IETF and ITU to provide these.&nbsp; =
Therefore I cannot=20
understand where you say "new extensions to</DIV>
<DIV dir=3Dltr align=3Dleft>OSPF are specified" and "none...align with the =
CCAMP's=20
GMPLS-ASON work".&nbsp; </DIV>
<DIV><SPAN=20
class=3D749145619-24072006>db&gt; None of the identified "issues for =
extensions"=20
aligns, and none of the DDRP protocol elements listed in the Appendix =
and used=20
for prototype testing align. If the identified issues do not align, how =
will=20
IETF provide extensions? ITU future work?</DIV>
<DIV><SPAN=20
class=3D749145619-24072006>&nbsp;</DIV>
<DIV>I=20
think we're experiencing a significant =
miscommunication...</DIV>
<DIV><SPAN=20
class=3D749145619-24072006>db&gt; Agree;-)</DIV>
<DIV><SPAN=20
class=3D749145619-24072006>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff =

size=3D2>Cheers,</FONT></SPAN></DIV>
<DIV><SPAN class=3D839162419-24072006><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D839162419-24072006><FONT face=3DArial color=3D#0000ff =

size=3D2>Lyndon</DIV>
<DIV dir=3Dltr align=3Dleft> </DIV>
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
<HR tabIndex=3D-1>
From: owner-ccamp@ops.ietf.org=20
[mailto:owner-ccamp@ops.ietf.org] On Behalf Of Brungard, Deborah =
A,=20
ALABS Sent: Monday, July 24, 2006 12:15 PM To: =
Sadler,=20
Jonathan B.; ccamp@ops.ietf.org Cc: Adrian =
Farrel Subject:=20
RE: Proposed response to OIF on OSPF ENNI </DIV>
<DIV></DIV>
<DIV dir=3Dltr align=3Dleft>Hi Jonathan, (and Lyndon),</DIV>
<DIV dir=3Dltr align=3Dleft>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft>Thanks to both of you for =
responding.</DIV>
<DIV dir=3Dltr align=3Dleft>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft>"Significant" was =
referencing:</DIV>
<DIV dir=3Dltr align=3Dleft>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN=20
class=3D176582318-24072006>- supports&nbsp;a&nbsp;(new) hierarchical =
OSPF=20
model</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN=20
class=3D176582318-24072006><FONT=20
size=3D2><SPAN=20
class=3D176582318-24072006>-&nbsp;supports&nbsp;inter-domain =
(inter-carrier) OSPF=20
(not supported by today's OSPF)</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN=20
class=3D176582318-24072006>- identifies namespace issues with GMPLS OSPF =
which do=20
not exist, and proposes extensions to =
"fix"</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN=20
class=3D176582318-24072006>- new extensions to OSPF are=20
specified</DIV>
<DIV dir=3Dltr align=3Dleft>- none of the proposed extensions align with =
CCAMP's=20
GMPLS-ASON work</DIV>
<DIV dir=3Dltr align=3Dleft>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft>Did you have another adjective to suggest? =
We&nbsp;were=20
thinking&nbsp;"significant" was rather soft considering the above. =
Though if=20
it's just ITU-speak differences, why does the OIF liaison state it =
reflects=20
several years of work including testing? Any insight (alignment mapping =
to=20
CCAMP's work) which you or Lyndon can provide would be helpful.&nbsp;The =

divergence is&nbsp;baffling to us.</DIV>
<DIV dir=3Dltr align=3Dleft>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft>Deborah</DIV>
<DIV dir=3Dltr align=3Dleft>&nbsp;</DIV> 
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
<HR tabIndex=3D-1>
From: Sadler, Jonathan B.=20
[mailto:Jonathan.Sadler@tellabs.com] Sent: Friday, July 21, =
2006=20
11:34 AM To: Brungard, Deborah A, ALABS;=20
ccamp@ops.ietf.org Cc: Adrian Farrel Subject: RE: =
Proposed=20
response to OIF on OSPF ENNI </DIV>
<DIV></DIV>
<DIV class=3DSection1>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Hi Deborah =
and=20
Adrian,<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">I =
haven&#8217;t seen much=20
discussion of the OIF E-NNI Routing document on the CCAMP list. =
&nbsp;Can you=20
tell me what parts of the document are &#8220;significant modifications =
to the=20
operation of OSPF&#8221;?<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">Thanks,<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p>
<st1:PersonName w:st=3D"on">Jonathan=20
Sadler</st1:PersonName><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p>
<DIV>
<DIV class=3DMsoNormal style=3D"TEXT-ALIGN: center" align=3Dcenter><FONT =

face=3D"Times New Roman" size=3D3><SPAN style=3D"FONT-SIZE: 12pt">
<HR tabIndex=3D-1 align=3Dcenter width=3D"100%" SIZE=3D2>
</SPAN></FONT></DIV>
<P class=3DMsoNormal><B><FONT face=3DTahoma size=3D2><SPAN=20
style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma">From:</SPAN></FONT></B><FONT=20
face=3DTahoma size=3D2><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma">=20
owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] <B><SPAN=20
style=3D"FONT-WEIGHT: bold">On Behalf Of </SPAN></B>Brungard, Deborah A, =

ALABS<BR><B><SPAN style=3D"FONT-WEIGHT: bold">Sent:</SPAN></B> Friday, =
July 21,=20
2006 9:38 AM<BR><B><SPAN style=3D"FONT-WEIGHT: bold">To:</SPAN></B>=20
ccamp@ops.ietf.org<BR><B><SPAN style=3D"FONT-WEIGHT: =
bold">Cc:</SPAN></B> Adrian=20
Farrel<BR><B><SPAN style=3D"FONT-WEIGHT: bold">Subject:</SPAN></B> =
Proposed=20
response to OIF on OSPF ENNI</SPAN></FONT><o:p></o:p></P></DIV>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
Arial">Hi,</SPAN></FONT><o:p></o:p></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">We had a =
communication=20
from OIF on their OSPF ENNI specification. You can see the original =
files on=20
</SPAN></FONT><A href=3D"http://www.olddog.co.uk/ccamp.htm"><FONT =
face=3DArial=20
size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial">http://www.olddog.co.uk/ccamp.htm</SPAN></FONT></A><FONT=20
face=3DArial color=3Dblue size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">. Having =
assembled=20
comments from several people and our discussions in <st1:City=20
w:st=3D"on"><st1:place w:st=3D"on">Montreal</st1:place></st1:City>, we =
have put=20
together the following response.</SPAN></FONT><o:p></o:p></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p></SPAN></FONT></P>
<DIV>
<P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Please =
comment on the=20
list in the next week.</SPAN></FONT><o:p></o:p></P></DIV>
<DIV>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p></SPAN></FONT></P></DIV>
<DIV>
<P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
Arial">Thanks,</SPAN></FONT><o:p></o:p></P></DIV>
<DIV>
<P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Adrian and=20
Deborah</SPAN></FONT><o:p></o:p></P></DIV>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p></SPAN></FONT></P>
<DIV>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">=3D =3D =3D =3D =3D =3D =3D =3D =3D =
=3D<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">Dear Jim,<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">We thank you for sending us the OIF ENNI =
document in=20
response to our request. While we appreciate the document being provided =
for=20
information, it is concerning that this document has not been previously =
shared=20
with CCAMP or the OSPF WG considering the document contains significant=20
modifications to the operation of OSPF and reflects OIF work over the =
last=20
several years. CCAMP has been working on GMPLS ASON for several years =
and our=20
Design Teams include OIF participants. Even though a reply was not =
requested, we=20
are replying, as we strongly recommend that the document not be =
published for=20
public information in its current form.<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">Of most concern to CCAMP is that it is not =
aligned with=20
RFC 4258 (Requirements for Generalized Multi-Protocol Label Switching =
(GMPLS)=20
Routing for the Automatically Switched Optical Network (ASON)) or the=20
to-be-published: <A=20
href=3D"ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpls-ason-rou=
ting-eval-03.txt">ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpl=
s-ason-routing-eval-03.txt</A>.=20
Considering notable OIF participants are authors of both these IETF =
documents=20
(and the same participants are contributors and the Editor for the OIF=20
document), the non-alignment is perplexing. Considering the IETF =
document is=20
ready for publication, we suggest in the interests of time, that you =
align your=20
document with the IETF document. If any questions on the interpretation =
of the=20
IETF&#8217;s work, we recommend that you either utilize the CCAMP mail =
exploder or=20
send a communication.<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">Specific comments =
include:<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal style=3D"MARGIN-LEFT: 0.25in; TEXT-INDENT: =
-0.25in"><FONT=20
face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">1.</SPAN></FONT><FONT size=3D1><SPAN=20
style=3D"FONT-SIZE: 7pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</SPAN></FONT>What is the=20
intent of this document? Will it be published as an Implementation =
Agreement=20
(IA)?<BR>The title indicates it will be an Implementation Agreement on =
GMPLS=20
OSPF extensions, but the main body of the document is a list of issues =
with=20
GMPLS OSPF. Further, your communication to us stated the document was=20
requirements on and use of OSPF-TE at the ENNI. These three views seem =
to be=20
inconsistent.<o:p></o:p></P>
<P class=3DMsoNormal style=3D"MARGIN-LEFT: 0.25in; TEXT-INDENT: =
-0.25in"><I><FONT=20
face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-STYLE: =
italic">2.</SPAN></FONT></I><I><FONT=20
size=3D1><SPAN=20
style=3D"FONT-SIZE: 7pt; FONT-STYLE: =
italic">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></FONT></I>The list of changes from the previous version (listed =
under=20
the Table of Contents) includes &#8220;<I><SPAN style=3D"FONT-STYLE: =
italic">removed=20
&#8220;intra-carrier&#8221; limitation</SPAN></I>&#8221; and the =
inclusion of Figure 1 showing the=20
OSPF ENNI for use between vendor domains and between carrier domains. =
GMPLS=20
OSPF-TE already supports inter-vendor operations. <BR>The IETF&#8217;s =
GMPLS ASON=20
routing focus has been on the use of a link-state based protocol to =
support a=20
hierarchical routing architecture (G.7715.1) within a carrier&#8217;s =
domain.=20
Requirements for using a link state protocol as an inter-domain protocol =
between=20
carriers are significantly different. We strongly disagree if you intend =
to=20
publish this document as an inter-carrier OSPF ENNI Implementation =
Agreement=20
claiming alignment with IETF RFCs without review (or agreement) by any =
of the=20
IETF Working Groups.<I><SPAN=20
style=3D"FONT-STYLE: italic"><o:p></o:p></SPAN></I></P>
<P class=3DMsoNormal style=3D"MARGIN-LEFT: 0.25in; TEXT-INDENT: =
-0.25in"><FONT=20
face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">3.</SPAN></FONT><FONT size=3D1><SPAN=20
style=3D"FONT-SIZE: 7pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</SPAN></FONT>Section=20
4.1/Table 1 and the statement under the table identifying issues with =
GMPLS=20
identifier namespaces are not correct. GMPLS identifier namespaces do =
meet ASON=20
requirements for namespace separation of the transport plane and control =
plane=20
(Section 5.2 and 5.3/Evaluation). Perhaps you are confusing OSPF and =
GMPLS OSPF?=20
As you also identified in your liaison that the key area needing review =
was the=20
support of independence of functional component to physical location, =
this=20
appears to be a key area of misunderstanding on GMPLS. We recommend =
reviewing=20
RFC3945 (GMPLS Architecture) to understand that the key architecture =
difference=20
between GMPLS and MPLS is the decoupling of the transport plane and =
control=20
plane. Additionally, RFC4394, RFC4397, and RFC4258, provide a mapping to =
ITU=20
terminology which may be helpful reading.<o:p></o:p></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">We request an additional round of =
communication of this=20
document to the IETF before approval to allow us to work with you to =
produce=20
convergence between OIF and IETF work which, we believe, will be in the =
best=20
interests of the industry.<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">Best regards,<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt"><ns0:PersonName =
w:endInsDate=3D"2006-07-21T10:10:00Z"=20
w:endInsAuthor=3D"Unknown" w:insDate=3D"2006-07-21T10:10:00Z"=20
w:insAuthor=3D"Unknown">Adrian Farrel</ns0:PersonName> and Deborah=20
Brungard,<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">CCAMP =
co-chairs<o:p></o:p></SPAN></FONT></P></DIV></DIV><PRE>=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=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
</PRE></BODY></HTML>

------_=_NextPart_001_01C6AF67.28CCE0D0--

Envelope-to: ccamp-data@psg.com
Delivery-date: Mon, 24 Jul 2006 21:03:27 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: Working Group Last Call on draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt
Date: Mon, 24 Jul 2006 16:03:02 -0500
Message-ID: <A1A52203CA93634BA1748887B9993AEA02FC5B11@USNVEX1.tellabs-west.tellabsinc.net>
Thread-Topic: Working Group Last Call on draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt
Thread-Index: AcaubGSrS9U9J5tzSXa9HR0LsRnWtwAwMnpQ
From: "Mack-Crane, T. Benjamin" <Ben.Mack-Crane@tellabs.com>
To: "Adrian Farrel" <adrian@olddog.co.uk>
Cc: <ccamp@ops.ietf.org>, "Brungard, Deborah A, ALABS" <dbrungard@att.com>
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="us-ascii"

Hi Adrian,

Some more questions in-line.

Regards,
Ben

> -----Original Message-----
> From: Adrian Farrel [mailto:adrian@olddog.co.uk]
> Sent: Sunday, July 23, 2006 10:19 AM
> To: Mack-Crane, T. Benjamin
> Cc: ccamp@ops.ietf.org; Brungard, Deborah A, ALABS
> Subject: Re: Working Group Last Call on
draft-ietf-ccamp-gmpls-rsvp-te-
> call-00.txt
>=20
> Hi Ben,
>=20
> Thanks. These questions give us something to chew on.
>=20
.=2E.snip...
>> Do the ingress and egress nodes terminate the LSP to be setup?
>
> Yes, indeed. Rooted in RFC3031, section 3.15.

Does the "link between the network and the egress node" connect directly
to the egress node?

> > How is the "link between the network and the egress node"
> > determined?
>=20
> Good question. Clearly if there is only one such link, we are done. In
the
> case of a "dual-homed" egress, the Link Capability object may report
on
> more than one link.=20

>From your answer it is still not clear HOW the link is determined.  Is
it assumed that the link (or set of links) is directly identified by the
destination of the call?=20

> This is, perhaps not abundantly clear, but it is covered by
> the final paragraph of section 5.3.
>=20
>    This object MAY also be used to exchange more than one bundled link
>    capability. In this case, the following ordering MUST be followed:
>    one identifier subobject (Type 1, 2 or 4) MUST be inserted before
any
>    capability subobject (Type 64 or 65) to which it refers.

Does the term "bundled link" used here have any relation to the term
"bundled link" defined in RFC 4201?

>=20
> >   This information may allow the ingress node to tailor its LSP
request
> >   to fit those capabilities and to better utilize network resources
> >   with regard to those capabilities.
> >
> > Generally an LSP setup request is generated by a network operator,
who
> > has a particular purpose in mind.  What leeway does the ingress LSR
have
> > to modify this request?
>=20
> I think that this is the difference between LSPs under the parentage
of a
> Call, and LSPs directly controlled by the operator.
> When an operator requests an LSP directly, you are quite right that
there
> is
> no scope for the LSR (i.e. the connection controller) to vary the
request
> for the LSP.
> However, when an operator requests a service, the service is converted
> into
> one or more LSP requests. A good example of this might be VCAT.
> So, when an operator requests a service and a Call is used to
coordinate
> the
> end points, the Call Controller has some leeway about what Connections
> (LSPs) it instantiates to satisfy the call.
>=20
> > Generally networks work best when there are uniform means of
> > providing connectivity between clients of the network.  What
> > kinds of "tailoring" are envisioned?
>=20
> I think that the VCAT example is the best. The ingress may have the
> ability
> to generate a whole pile of signals, but the egress may only have the
> ability to terminate a limited set of signals.
> You might regard this as choosing between sub-layers, I suppose.

A functional model would help here.  Are you saying that the ingress (i)
can generate different LSP types (i.e., different layer network
technologies) or (ii) can generate a different number of signals (e.g.,
as in VCAT) or (iii) that the ingress offers different adaptations from
a client to the LSP(s)?

>=20
> >  In particular, this may be used to achieve end-to-end spectral
> >  routing attribute negotiation for signal quality negotiation (such
as
> >  BER) in photonic environments where network edges are signal
> >  regeneration capable. Similarly, it may be used to provide
end-to-end
> >  spatial routing attribute negotiation in multi-area routing
> >  environments, in particular, when TE links have been bundled based
on
> >  technology specific attributes.
> >
> >What is "end-to-end spectral routing attribute negotiation"?
>=20
> It is a completely ridiculous and over-florid way of saying
"end-to-end
> lambda negotiation for use in transparent optical networks".

OK, but what egress link information is used by the ingress in this
case?

>=20
> >What is "end-to-end spatial routing attribute negotiation"?
>=20
> Similarly poor choice of words for "end-to-end port negotiation for
use in
> fiber switching networks".

OK, again what egress link information is used by the ingress in this
case?

>=20
> Thanks for flagging these.
>=20
> >  Call setup may provide a suitable mechanism to exchange information
> >   for this purpose, although several other possibilities exist.
> >
> > Just because a mechanism can be defined does not mean that it should
be.
> > Why is it necessary to define this mechanism, and add complexity to
call
> > control, if another mechanism is required to do the same thing in
cases
> > where call control is not used?
>=20
> Hmmm.
> Well that is a good question.
>=20
> I guess the answer is:
> Because the Call control mechanism a good one where this type of
> information
> (i.e. access connectivity information such as access addressing) is
often
> exchanged.

What is "access addressing"?  Can you give an example use case?

> Maybe more important are:
> - this mechanism is one that several implementers want to /  have
>   implemented.

OK, but why?  There ought to be an explainable technical reason.

> - no-one raised any concerns about this mechanism during a
>   couple of years of discussion of this process and during WG
>   last call.

Was there discussion of the technical reasons for this feature on the
mailing list?  If you can provide a pointer I can look at the reasons
put forth there.  (BTW, I raised this concern during working group last
call;-)

> It is possible that this is not the best way of achieving this
(although
> it
> is my favourite), but if other mechanisms exist then (as Yakov fondly
> says)
> the market will decide which is the best mechanism.

If other mechanisms must exist, and these can also be used in the cases
covered by this draft, then adding this mechanism doesn't really help.

If you could give an example showing where this mechanism is needed,
that might be enlightening.

>=20
> Cheers,
> Adrian
>=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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

Envelope-to: ccamp-data@psg.com
Delivery-date: Mon, 24 Jul 2006 20:35:34 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6AF60.995C5E4B"
Subject: RE: Proposed response to OIF on OSPF ENNI
Date: Mon, 24 Jul 2006 15:31:55 -0500
Message-ID: <A1A52203CA93634BA1748887B9993AEA02FC5AC2@USNVEX1.tellabs-west.tellabsinc.net>
Thread-Topic: Proposed response to OIF on OSPF ENNI
Thread-Index: Acas0Ha/aYxFikOBS5m873SVRoVJxgAACLxQAAHPZJAAnZ89IAACGznwAAEH8mA=
From: "Sadler, Jonathan B." <Jonathan.Sadler@tellabs.com>
To: "Brungard, Deborah A, ALABS" <dbrungard@att.com>, "Ong, Lyndon" <Lyong@Ciena.com>, <ccamp@ops.ietf.org>
Cc: "Adrian Farrel" <adrian@olddog.co.uk>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6AF60.995C5E4B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="us-ascii"

Hi Deborah, Lyndon, et al,

=20

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.

=20

Given that:

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

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

=20

Regards,

=20

Jonathan Sadler

=20

________________________________

From: Ong, Lyndon [mailto:Lyong@Ciena.com]=20
Sent: Monday, July 24, 2006 2: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

=20

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

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

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

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

=20

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

=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
<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_01C6AF60.995C5E4B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset="us-ascii"

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:p=3D"urn:schemas-microsoft-com:office:powerpoint" xmlns:oa=3D"urn:sch=
emas-microsoft-com:office:activation" xmlns:st1=3D"urn:schemas-microsoft-co=
m:office:smarttags" xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]--><o:SmartTagType
 namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" name=3D"City"
 downloadurl=3D"http://www.5iamas-microsoft-com:office:smarttags"/>
<o:SmartTagType namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"place" downloadurl=3D"http://www.5iantlavalamp.com/"/>
<o:SmartTagType namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"PersonName" downloadurl=3D"http://www.microsoft.com"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:"MS Mincho";
	panose-1:2 2 6 9 4 2 5 8 3 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:"\@MS Mincho";
	panose-1:2 2 6 9 4 2 5 8 3 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:blue;
	text-decoration:underline;}
pre
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
span.EmailStyle17
	{mso-style-type:personal;
	font-family:Arial;
	color:navy;}
span.EmailStyle19
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 @list l0
	{mso-list-id:172189309;
	mso-list-type:hybrid;
	mso-list-template-ids:-959315850 -1603784330 67698691 67698693 67698689 67=
698691 67698693 67698689 67698691 67698693;}
@list l0:level1
	{mso-level-start-at:630;
	mso-level-number-format:bullet;
	mso-level-text:-;
	mso-level-tab-stop:21.0pt;
	mso-level-number-position:left;
	margin-left:21.0pt;
	text-indent:-.25in;
	font-family:Arial;
	mso-fareast-font-family:"MS Mincho";}
ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dblue>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Hi Deborah, Lyndon, et al,<o:p></o:p><=
/span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Some additional comments:<o:p></o:p></=
span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;- The hierarchical model discuss=
ed in
the draft IA liaised may be supported without any modifications to OSPF.&nb=
sp; As
discussed in earlier emails, it can be implemented solely through the
import/export of information described in Appendix I of G.7715.<o:p></o:p><=
/span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;- The draft IA also recognizes n=
amespace
issues exist between Router ID and the IP Address that messages are sent to
(ITU calls this the RC PC SCN address).&nbsp; This issue is also discussed =
in draft-ietf-ccamp-gmpls-addressing.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Given that:<o:p></o:p></span></font></=
p>

<p class=3DMsoNormal style=3D'margin-left:21.0pt;text-indent:-.25in;mso-lis=
t:l0 level1 lfo1'><![if !supportLists]><font
size=3D2 color=3Dnavy face=3DArial><span style=3D'font-size:10.0pt;font-fam=
ily:Arial;
color:navy'><span style=3D'mso-list:Ignore'>-<font size=3D1 face=3D"Times N=
ew Roman"><span
style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;
</span></font></span></span></font><![endif]><font size=3D2 color=3Dnavy
face=3DArial><span style=3D'font-size:10.0pt;font-family:Arial;color:navy'>=
CCAMP has
a milestone to publish an ASON routing solution by Nov 2006, <o:p></o:p></s=
pan></font></p>

<p class=3DMsoNormal style=3D'margin-left:21.0pt;text-indent:-.25in;mso-lis=
t:l0 level1 lfo1'><![if !supportLists]><font
size=3D2 color=3Dnavy face=3DArial><span style=3D'font-size:10.0pt;font-fam=
ily:Arial;
color:navy'><span style=3D'mso-list:Ignore'>-<font size=3D1 face=3D"Times N=
ew Roman"><span
style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;
</span></font></span></span></font><![endif]><font size=3D2 color=3Dnavy
face=3DArial><span style=3D'font-size:10.0pt;font-family:Arial;color:navy'>=
CCAMP didn&#8217;t
have at the time this was liaised (doesn&#8217;t have today?) a working gro=
up
document, and<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:21.0pt;text-indent:-.25in;mso-lis=
t:l0 level1 lfo1'><![if !supportLists]><font
size=3D2 color=3Dnavy face=3DArial><span style=3D'font-size:10.0pt;font-fam=
ily:Arial;
color:navy'><span style=3D'mso-list:Ignore'>-<font size=3D1 face=3D"Times N=
ew Roman"><span
style=3D'font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;
</span></font></span></span></font><![endif]><font size=3D2 color=3Dnavy
face=3DArial><span style=3D'font-size:10.0pt;font-family:Arial;color:navy'>=
the
draft IA has been successfully implemented by more than a dozen vendors and
interop-tested many times,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>I would expect that we should be looki=
ng at
this as experience/text that could be leveraged...&nbsp; &#8220;Running cod=
e&#8230;&#8221;
and all that&#8230;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Regards,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><st1:PersonName w:st=3D"on"><font size=3D2 color=3Dnavy
 face=3DArial><span style=3D'font-size:10.0pt;font-family:Arial;color:navy'=
>Jonathan
 Sadler</span></font></st1:PersonName><font size=3D2 color=3Dnavy face=3DAr=
ial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p></o:p></span><=
/font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font siz=
e=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span style=3D'font-si=
ze:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'> Ong, Lyn=
don
[mailto:Lyong@Ciena.com] <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Monday, July 24, 2006 =
2:33
PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Brungard, Deborah A, ALA=
BS;
Sadler, Jonathan B.; ccamp@ops.ietf.org<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> Adrian Farrel<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: Proposed respon=
se to
OIF on OSPF ENNI</span></font><o:p></o:p></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Hi Deborah,</span></font><o:p></o:p></=
p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Here's what I would say&nbsp;is in and=
 not
in the OIF document:</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>-- G.7715, G.7715.1 and the IETF eval =
and
solutions draft all identify a need to support hierarchical</span></font><o=
:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>routing areas for ASON, I am perplexed=
 as
to why this seems to be viewed as a new feature.</span></font><o:p></o:p></=
p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>-- the document does not specify the
domain of usage and leaves this to the carrier.&nbsp; This is no different<=
/span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>from G.7715.1 and IETF drafts that do =
not
explicitly state whether they are used for intra- or inter-domain</span></f=
ont><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>interfaces.</span></font><o:p></o:p></=
p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>-- GMPLS OSPF does not support a 1:N or
N:1 relationship between routing controller and transport</span></font><o:p=
></o:p></p>

node, hence extensions are felt to be
required - and are proposed in the eval solutions draft. The =
<o:p></o:p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>conclusions are no different.</span></=
font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>-- the document does not in fact define
any standard extensions to the protocols, and points to future work</span><=
/font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>in IETF and ITU to provide these.&nbsp;
Therefore I cannot understand where you say &quot;new extensions to</span><=
/font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>OSPF are specified&quot; and
&quot;none...align with the CCAMP's GMPLS-ASON work&quot;.&nbsp; </span></f=
ont><o:p></o:p></p>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>I think we're experiencing a significa=
nt
miscommunication...</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Cheers,</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Lyndon</span></font><o:p></o:p></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font siz=
e=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabIndex=3D-1>

</span></font></div>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><b><font size=3D2 face=
=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma;font-weight:bold'>From:</span>=
</font></b><font
size=3D2 face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'>
owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] <b><span
style=3D'font-weight:bold'>On Behalf Of </span></b>Brungard, Deborah A, ALA=
BS<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Monday, July 24, 2006 =
12:15
PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Sadler, Jonathan B.;
ccamp@ops.ietf.org<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> Adrian Farrel<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: Proposed respon=
se to
OIF on OSPF ENNI</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Hi Jonathan, (and Lyndon),</span></fon=
t><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Thanks to both of you for responding.<=
/span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>&quot;Significant&quot; was referencin=
g:</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>- supports&nbsp;a&nbsp;(new) hierarchi=
cal
OSPF model</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>-&nbsp;supports&nbsp;inter-domain
(inter-carrier) OSPF (not supported by today's OSPF)</span></font><o:p></o:=
p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>- identifies namespace issues with GMP=
LS
OSPF which do not exist, and proposes extensions to &quot;fix&quot;</span><=
/font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>- new extensions to OSPF are specified=
</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>- none of the proposed extensions align
with CCAMP's GMPLS-ASON work</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

Did you have another adjective to sugg=
est?
We&nbsp;were thinking&nbsp;&quot;significant&quot; 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.&nbsp;The divergence is&nbsp;baffling to us.<o:p></o:=
p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Deborah</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font siz=
e=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabIndex=3D-1>

</span></font></div>

From:=
=
 Sadler,
Jonathan B. [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<o:p></o:p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Hi Deborah and Adrian,<o:p></o:p></spa=
n></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

I haven&#8217;t seen much discussion of
the OIF E-NNI Routing document on the CCAMP list. &nbsp;Can you tell me what
parts of the document are &#8220;significant modifications to the operation=
 of
OSPF&#8221;?<o:p></o:p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Thanks,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><st1:PersonName w:st=3D"on"><font size=3D2 color=3Dnavy
 face=3DArial><span style=3D'font-size:10.0pt;font-family:Arial;color:navy'=
>Jonathan
 Sadler</span></font></st1:PersonName><font size=3D2 color=3Dnavy face=3DAr=
ial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p></o:p></span><=
/font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font siz=
e=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabIndex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span style=3D'font-si=
ze:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'>
owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] <b><span
style=3D'font-weight:bold'>On Behalf Of </span></b>Brungard, Deborah A, ALA=
BS<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Friday, July 21, 2006 =
9:38
AM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> ccamp@ops.ietf.org<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> Adrian Farrel<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> Proposed response t=
o OIF
on OSPF ENNI</span></font><o:p></o:p></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Hi,</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

We had a communication from OIF on the=
ir
OSPF ENNI specification. You can see the original files on <a
href=3D"http://www.olddog.co.uk/ccamp.htm">http://www.olddog.co.uk/ccamp.=
htm</a>. Having assembled comments from several people and our discuss=
ions
in <st1:place w:st=3D"on"><st1:City w:st=3D"on">Montreal</st1:City></st1:pl=
ace>, we
have put together the following response.<o:p></o:p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Please comment on the list in the next
week.</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Thanks,</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Adrian and Deborah</span></font><o:p><=
/o:p></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>=3D =3D =3D =3D =3D =3D =3D =3D =3D =3D<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>Dear Jim,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

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.<o:p></o:p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

Of most concern to CCAMP is that it is not aligned with RFC 4258 (R=
equirements
for Generalized Multi-Protocol Label Switching (GMPLS) Routing for the
Automatically Switched Optical Network (ASON)) or the to-be-published: <a
href=3D"ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpls-ason-routi=
ng-eval-03.txt">ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpls-as=
on-routing-eval-03.txt</a>.
Considering notable OIF participants are authors of both these IETF documen=
ts
(and the same participants are contributors and the Editor for the OIF docu=
ment),
the non-alignment is perplexing. Considering the IETF document is ready for
publication, we suggest in the interests of time, that you align your docum=
ent
with the IETF document. If any questions on the interpretation of the
IETF&#8217;s work, we recommend that you either utilize the CCAMP mail expl=
oder
or send a communication.<o:p></o:p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>Specific comments include:<o:p></o:p></span></font></p>

1.<=
font
size=3D1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </s=
pan>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></o:p>

<p class=3DMsoNormal style=3D'margin-left:.25in;text-indent:-.25in'><i><font
size=3D3 face=3D"Times New Roman"><span style=3D'font-size:12.0pt;font-styl=
e:italic'>2.</span></font></i><i><font
size=3D1><span style=3D'font-size:7.0pt;font-style:italic'>&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;
</span></font></i>The list of changes from the previous version (listed und=
er
the Table of Contents) includes &#8220;<i><span style=3D'font-style:italic'=
>removed
&#8220;intra-carrier&#8221; limitation</span></i>&#8221; 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. <b=
r>
The IETF&#8217;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&#8217;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.<i><span style=3D'font-style:italic'><o:p=
></o:p></span></i></p>

3.<=
font
size=3D1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </s=
pan>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.<o:p></o:p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>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.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>Best regards,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><st1:PersonName w:st=3D"on"><font size=3D3 face=3D"Tim=
es New Roman"><span
 style=3D'font-size:12.0pt'>Adrian Farrel</span></font></st1:PersonName> and
Deborah Brungard,<o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>CCAMP co-chairs<o:p></o:p></span></font></p>

</div>

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

<pre>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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
</pre></body>

</html>

------_=_NextPart_001_01C6AF60.995C5E4B--

Envelope-to: ccamp-data@psg.com
Delivery-date: Mon, 24 Jul 2006 19:34:48 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6AF58.099AD0DA"
Subject: RE: Proposed response to OIF on OSPF ENNI
Date: Mon, 24 Jul 2006 15:33:28 -0400
Message-ID: <0901D1988E815341A0103206A834DA07F1A1B7@mdmxm02.ciena.com>
Thread-Topic: Proposed response to OIF on OSPF ENNI
Thread-Index: Acas0Ha/aYxFikOBS5m873SVRoVJxgAACLxQAAHPZJAAnZ89IAACGznw
From: "Ong, Lyndon" <Lyong@Ciena.com>
To: "Brungard, Deborah A, ALABS" <dbrungard@att.com>, "Sadler, Jonathan B." <Jonathan.Sadler@tellabs.com>, <ccamp@ops.ietf.org>
Cc: "Adrian Farrel" <adrian@olddog.co.uk>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6AF58.099AD0DA
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

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

=20
I think we're experiencing a significant miscommunication...
=20
Cheers,
=20
Lyndon

________________________________

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

________________________________

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

=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

------_=_NextPart_001_01C6AF58.099AD0DA
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:v =3D=20
"urn:schemas-microsoft-com:vml" xmlns:o =3D=20
"urn:schemas-microsoft-com:office:office" xmlns:w =3D=20
"urn:schemas-microsoft-com:office:word" xmlns:p =3D=20
"urn:schemas-microsoft-com:office:powerpoint" xmlns:oa =3D=20
"urn:schemas-microsoft-com:office:activation" xmlns:st1 =3D=20
"urn:schemas-microsoft-com:office:smarttags" xmlns:ns0 =3D=20
"urn:schemas-microsoft-com:office:smarttags"><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.2912" name=3DGENERATOR><!--[if !mso]>
<STYLE>v\:* {
	BEHAVIOR: url(#default#VML)
}
o\:* {
	BEHAVIOR: url(#default#VML)
}
w\:* {
	BEHAVIOR: url(#default#VML)
}
.shape {
	BEHAVIOR: url(#default#VML)
}
</STYLE>
<![endif]--><o:SmartTagType=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" =
name=3D"City"=20
downloadurl=3D"http://www.5iamas-microsoft-com:office:smarttags"></o:Smar=
tTagType><o:SmartTagType=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" =
name=3D"place"=20
downloadurl=3D"http://www.5iantlavalamp.com/"></o:SmartTagType><o:SmartTa=
gType=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" =
name=3D"PersonName"=20
downloadurl=3D"http://www.microsoft.com"></o:SmartTagType><!--[if !mso]>
<STYLE>st1\:* {
	BEHAVIOR: url(#default#ieooui)
}
</STYLE>
<![endif]-->
<STYLE>@font-face {
	font-family: MS Mincho;
}
@font-face {
	font-family: Tahoma;
}
@font-face {
	font-family: @MS Mincho;
}
@page Section1 {size: 8.5in 11.0in; margin: 1.0in 1.25in 1.0in 1.25in; }
P.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
LI.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
DIV.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline
}
A:visited {
	COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlinkFollowed {
	COLOR: blue; TEXT-DECORATION: underline
}
SPAN.EmailStyle17 {
	COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal-reply
}
DIV.Section1 {
	page: Section1
}
</STYLE>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]--></HEAD>
<BODY lang=3DEN-US vLink=3Dblue link=3Dblue>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D839162419-24072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Hi Deborah,</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D839162419-24072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D839162419-24072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Here's what I would say&nbsp;is in and not in =
the OIF=20
document:</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D839162419-24072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D839162419-24072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>-- G.7715, G.7715.1 and the IETF eval and =
solutions draft=20
all identify a need to support hierarchical</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D839162419-24072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>routing areas for ASON, I am perplexed as to =
why this seems=20
to be viewed as a new feature.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D839162419-24072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D839162419-24072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>-- the document does not specify the domain of =
usage and=20
leaves this to the carrier.&nbsp; This is no =
different</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D839162419-24072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>from G.7715.1 and IETF drafts that do not =
explicitly state=20
whether they are used for intra- or inter-domain</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D839162419-24072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>interfaces.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D839162419-24072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D839162419-24072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>-- GMPLS OSPF does not support a 1:N or N:1 =
relationship=20
between routing controller and transport</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D839162419-24072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>node, hence extensions are felt to be required =
- and are=20
proposed in the eval solutions draft. The </FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D839162419-24072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>conclusions are no =
different.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D839162419-24072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D839162419-24072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>-- the document does not in fact define any =
standard=20
extensions to the protocols, and points to future =
work</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D839162419-24072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>in IETF and ITU to provide these.&nbsp; =
Therefore I cannot=20
understand where you say "new extensions to</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D839162419-24072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>OSPF are specified" and "none...align with the =
CCAMP's=20
GMPLS-ASON work".&nbsp; </FONT></SPAN></DIV>
<DIV><SPAN class=3D839162419-24072006><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D839162419-24072006><FONT face=3DArial color=3D#0000ff =
size=3D2>I=20
think we're experiencing a significant =
miscommunication...</FONT></SPAN></DIV>
<DIV><SPAN class=3D839162419-24072006><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D839162419-24072006><FONT face=3DArial color=3D#0000ff =

size=3D2>Cheers,</FONT></SPAN></DIV>
<DIV><SPAN class=3D839162419-24072006><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D839162419-24072006><FONT face=3DArial color=3D#0000ff =

size=3D2>Lyndon</DIV>
<DIV dir=3Dltr align=3Dleft> </DIV>
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
<HR tabIndex=3D-1>
From: owner-ccamp@ops.ietf.org=20
[mailto:owner-ccamp@ops.ietf.org] On Behalf Of Brungard, Deborah =
A,=20
ALABS Sent: Monday, July 24, 2006 12:15 PM To: =
Sadler,=20
Jonathan B.; ccamp@ops.ietf.org Cc: Adrian =
Farrel Subject:=20
RE: Proposed response to OIF on OSPF ENNI </DIV>
<DIV></DIV>
<DIV dir=3Dltr align=3Dleft>Hi Jonathan, (and Lyndon),</DIV>
<DIV dir=3Dltr align=3Dleft>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft>Thanks to both of you for =
responding.</DIV>
<DIV dir=3Dltr align=3Dleft>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft>"Significant" was =
referencing:</DIV>
<DIV dir=3Dltr align=3Dleft>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN=20
class=3D176582318-24072006>- supports&nbsp;a&nbsp;(new) hierarchical =
OSPF=20
model</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN=20
class=3D176582318-24072006><FONT=20
size=3D2><SPAN=20
class=3D176582318-24072006>-&nbsp;supports&nbsp;inter-domain =
(inter-carrier) OSPF=20
(not supported by today's OSPF)</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN=20
class=3D176582318-24072006>- identifies namespace issues with GMPLS OSPF =
which do=20
not exist, and proposes extensions to =
"fix"</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN=20
class=3D176582318-24072006>- new extensions to OSPF are=20
specified</DIV>
<DIV dir=3Dltr align=3Dleft>- none of the proposed extensions align with =
CCAMP's=20
GMPLS-ASON work</DIV>
<DIV dir=3Dltr align=3Dleft>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft>Did you have another adjective to suggest? =
We&nbsp;were=20
thinking&nbsp;"significant" was rather soft considering the above. =
Though if=20
it's just ITU-speak differences, why does the OIF liaison state it =
reflects=20
several years of work including testing? Any insight (alignment mapping =
to=20
CCAMP's work) which you or Lyndon can provide would be helpful.&nbsp;The =

divergence is&nbsp;baffling to us.</DIV>
<DIV dir=3Dltr align=3Dleft>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft>Deborah</DIV>
<DIV dir=3Dltr align=3Dleft>&nbsp;</DIV> 
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
<HR tabIndex=3D-1>
From: Sadler, Jonathan B.=20
[mailto:Jonathan.Sadler@tellabs.com] Sent: Friday, July 21, =
2006=20
11:34 AM To: Brungard, Deborah A, ALABS;=20
ccamp@ops.ietf.org Cc: Adrian Farrel Subject: RE: =
Proposed=20
response to OIF on OSPF ENNI </DIV>
<DIV></DIV>
<DIV class=3DSection1>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Hi Deborah =
and=20
Adrian,<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">I =
haven&#8217;t seen much=20
discussion of the OIF E-NNI Routing document on the CCAMP list. =
&nbsp;Can you=20
tell me what parts of the document are &#8220;significant modifications =
to the=20
operation of OSPF&#8221;?<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">Thanks,<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p>
<st1:PersonName w:st=3D"on">Jonathan=20
Sadler</st1:PersonName><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p>
<DIV>
<DIV class=3DMsoNormal style=3D"TEXT-ALIGN: center" align=3Dcenter><FONT =

face=3D"Times New Roman" size=3D3><SPAN style=3D"FONT-SIZE: 12pt">
<HR tabIndex=3D-1 align=3Dcenter width=3D"100%" SIZE=3D2>
</SPAN></FONT></DIV>
<P class=3DMsoNormal><B><FONT face=3DTahoma size=3D2><SPAN=20
style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma">From:</SPAN></FONT></B><FONT=20
face=3DTahoma size=3D2><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma">=20
owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] <B><SPAN=20
style=3D"FONT-WEIGHT: bold">On Behalf Of </SPAN></B>Brungard, Deborah A, =

ALABS<BR><B><SPAN style=3D"FONT-WEIGHT: bold">Sent:</SPAN></B> Friday, =
July 21,=20
2006 9:38 AM<BR><B><SPAN style=3D"FONT-WEIGHT: bold">To:</SPAN></B>=20
ccamp@ops.ietf.org<BR><B><SPAN style=3D"FONT-WEIGHT: =
bold">Cc:</SPAN></B> Adrian=20
Farrel<BR><B><SPAN style=3D"FONT-WEIGHT: bold">Subject:</SPAN></B> =
Proposed=20
response to OIF on OSPF ENNI</SPAN></FONT><o:p></o:p></P></DIV>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
Arial">Hi,</SPAN></FONT><o:p></o:p></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">We had a =
communication=20
from OIF on their OSPF ENNI specification. You can see the original =
files on=20
</SPAN></FONT><A href=3D"http://www.olddog.co.uk/ccamp.htm"><FONT =
face=3DArial=20
size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial">http://www.olddog.co.uk/ccamp.htm</SPAN></FONT></A><FONT=20
face=3DArial color=3Dblue size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">. Having =
assembled=20
comments from several people and our discussions in <st1:City=20
w:st=3D"on"><st1:place w:st=3D"on">Montreal</st1:place></st1:City>, we =
have put=20
together the following response.</SPAN></FONT><o:p></o:p></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p></SPAN></FONT></P>
<DIV>
<P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Please =
comment on the=20
list in the next week.</SPAN></FONT><o:p></o:p></P></DIV>
<DIV>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p></SPAN></FONT></P></DIV>
<DIV>
<P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
Arial">Thanks,</SPAN></FONT><o:p></o:p></P></DIV>
<DIV>
<P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Adrian and=20
Deborah</SPAN></FONT><o:p></o:p></P></DIV>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p></SPAN></FONT></P>
<DIV>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">=3D =3D =3D =3D =3D =3D =3D =3D =3D =
=3D<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">Dear Jim,<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">We thank you for sending us the OIF ENNI =
document in=20
response to our request. While we appreciate the document being provided =
for=20
information, it is concerning that this document has not been previously =
shared=20
with CCAMP or the OSPF WG considering the document contains significant=20
modifications to the operation of OSPF and reflects OIF work over the =
last=20
several years. CCAMP has been working on GMPLS ASON for several years =
and our=20
Design Teams include OIF participants. Even though a reply was not =
requested, we=20
are replying, as we strongly recommend that the document not be =
published for=20
public information in its current form.<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">Of most concern to CCAMP is that it is not =
aligned with=20
RFC 4258 (Requirements for Generalized Multi-Protocol Label Switching =
(GMPLS)=20
Routing for the Automatically Switched Optical Network (ASON)) or the=20
to-be-published: <A=20
href=3D"ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpls-ason-rou=
ting-eval-03.txt">ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpl=
s-ason-routing-eval-03.txt</A>.=20
Considering notable OIF participants are authors of both these IETF =
documents=20
(and the same participants are contributors and the Editor for the OIF=20
document), the non-alignment is perplexing. Considering the IETF =
document is=20
ready for publication, we suggest in the interests of time, that you =
align your=20
document with the IETF document. If any questions on the interpretation =
of the=20
IETF&#8217;s work, we recommend that you either utilize the CCAMP mail =
exploder or=20
send a communication.<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">Specific comments =
include:<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal style=3D"MARGIN-LEFT: 0.25in; TEXT-INDENT: =
-0.25in"><FONT=20
face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">1.</SPAN></FONT><FONT size=3D1><SPAN=20
style=3D"FONT-SIZE: 7pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</SPAN></FONT>What is the=20
intent of this document? Will it be published as an Implementation =
Agreement=20
(IA)?<BR>The title indicates it will be an Implementation Agreement on =
GMPLS=20
OSPF extensions, but the main body of the document is a list of issues =
with=20
GMPLS OSPF. Further, your communication to us stated the document was=20
requirements on and use of OSPF-TE at the ENNI. These three views seem =
to be=20
inconsistent.<o:p></o:p></P>
<P class=3DMsoNormal style=3D"MARGIN-LEFT: 0.25in; TEXT-INDENT: =
-0.25in"><I><FONT=20
face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-STYLE: =
italic">2.</SPAN></FONT></I><I><FONT=20
size=3D1><SPAN=20
style=3D"FONT-SIZE: 7pt; FONT-STYLE: =
italic">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></FONT></I>The list of changes from the previous version (listed =
under=20
the Table of Contents) includes &#8220;<I><SPAN style=3D"FONT-STYLE: =
italic">removed=20
&#8220;intra-carrier&#8221; limitation</SPAN></I>&#8221; and the =
inclusion of Figure 1 showing the=20
OSPF ENNI for use between vendor domains and between carrier domains. =
GMPLS=20
OSPF-TE already supports inter-vendor operations. <BR>The IETF&#8217;s =
GMPLS ASON=20
routing focus has been on the use of a link-state based protocol to =
support a=20
hierarchical routing architecture (G.7715.1) within a carrier&#8217;s =
domain.=20
Requirements for using a link state protocol as an inter-domain protocol =
between=20
carriers are significantly different. We strongly disagree if you intend =
to=20
publish this document as an inter-carrier OSPF ENNI Implementation =
Agreement=20
claiming alignment with IETF RFCs without review (or agreement) by any =
of the=20
IETF Working Groups.<I><SPAN=20
style=3D"FONT-STYLE: italic"><o:p></o:p></SPAN></I></P>
<P class=3DMsoNormal style=3D"MARGIN-LEFT: 0.25in; TEXT-INDENT: =
-0.25in"><FONT=20
face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">3.</SPAN></FONT><FONT size=3D1><SPAN=20
style=3D"FONT-SIZE: 7pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</SPAN></FONT>Section=20
4.1/Table 1 and the statement under the table identifying issues with =
GMPLS=20
identifier namespaces are not correct. GMPLS identifier namespaces do =
meet ASON=20
requirements for namespace separation of the transport plane and control =
plane=20
(Section 5.2 and 5.3/Evaluation). Perhaps you are confusing OSPF and =
GMPLS OSPF?=20
As you also identified in your liaison that the key area needing review =
was the=20
support of independence of functional component to physical location, =
this=20
appears to be a key area of misunderstanding on GMPLS. We recommend =
reviewing=20
RFC3945 (GMPLS Architecture) to understand that the key architecture =
difference=20
between GMPLS and MPLS is the decoupling of the transport plane and =
control=20
plane. Additionally, RFC4394, RFC4397, and RFC4258, provide a mapping to =
ITU=20
terminology which may be helpful reading.<o:p></o:p></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">We request an additional round of =
communication of this=20
document to the IETF before approval to allow us to work with you to =
produce=20
convergence between OIF and IETF work which, we believe, will be in the =
best=20
interests of the industry.<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">Best regards,<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt"><ns0:PersonName w:insAuthor=3D"Unknown"=20
w:insDate=3D"2006-07-21T10:10:00Z" w:endInsAuthor=3D"Unknown"=20
w:endInsDate=3D"2006-07-21T10:10:00Z">Adrian Farrel</ns0:PersonName> and =
Deborah=20
Brungard,<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">CCAMP =
co-chairs<o:p></o:p></SPAN></FONT></P></DIV></DIV><PRE>=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=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
</PRE></BODY></HTML>

------_=_NextPart_001_01C6AF58.099AD0DA--

Envelope-to: ccamp-data@psg.com
Delivery-date: Mon, 24 Jul 2006 19:17:34 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6AF55.877A60BC"
Subject: RE: Proposed response to OIF on OSPF ENNI
Date: Mon, 24 Jul 2006 14:15:29 -0500
Message-ID: <449B2580D802A443A923DABF3EAB82AF0C72BF47@OCCLUST04EVS1.ugd.att.com>
Thread-Topic: Proposed response to OIF on OSPF ENNI
Thread-Index: Acas0Ha/aYxFikOBS5m873SVRoVJxgAACLxQAAHPZJAAnZ89IA==
From: "Brungard, Deborah A, ALABS" <dbrungard@att.com>
To: "Sadler, Jonathan B." <Jonathan.Sadler@tellabs.com>, <ccamp@ops.ietf.org>
Cc: "Adrian Farrel" <adrian@olddog.co.uk>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6AF55.877A60BC
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

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

________________________________

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

=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

------_=_NextPart_001_01C6AF55.877A60BC
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:v =3D=20
"urn:schemas-microsoft-com:vml" xmlns:o =3D=20
"urn:schemas-microsoft-com:office:office" xmlns:w =3D=20
"urn:schemas-microsoft-com:office:word" xmlns:p =3D=20
"urn:schemas-microsoft-com:office:powerpoint" xmlns:oa =3D=20
"urn:schemas-microsoft-com:office:activation" xmlns:st1 =3D=20
"urn:schemas-microsoft-com:office:smarttags" xmlns:ns0 =3D=20
"urn:schemas-microsoft-com:office:smarttags"><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.2914" name=3DGENERATOR><!--[if !mso]>
<STYLE>v\:* {
	BEHAVIOR: url(#default#VML)
}
o\:* {
	BEHAVIOR: url(#default#VML)
}
w\:* {
	BEHAVIOR: url(#default#VML)
}
.shape {
	BEHAVIOR: url(#default#VML)
}
</STYLE>
<![endif]--><o:SmartTagType=20
downloadurl=3D"http://www.5iamas-microsoft-com:office:smarttags" =
name=3D"City"=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTagT=
ype><o:SmartTagType=20
downloadurl=3D"http://www.5iantlavalamp.com/" name=3D"place"=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTagT=
ype><o:SmartTagType=20
downloadurl=3D"http://www.microsoft.com" name=3D"PersonName"=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTagT=
ype><!--[if !mso]>
<STYLE>st1\:* {
	BEHAVIOR: url(#default#ieooui)
}
</STYLE>
<![endif]-->
<STYLE>@font-face {
	font-family: MS Mincho;
}
@font-face {
	font-family: Tahoma;
}
@font-face {
	font-family: @MS Mincho;
}
@page Section1 {size: 8.5in 11.0in; margin: 1.0in 1.25in 1.0in 1.25in; }
P.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
LI.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
DIV.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline
}
A:visited {
	COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlinkFollowed {
	COLOR: blue; TEXT-DECORATION: underline
}
SPAN.EmailStyle17 {
	COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal-reply
}
DIV.Section1 {
	page: Section1
}
</STYLE>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]--></HEAD>
<BODY lang=3DEN-US vLink=3Dblue link=3Dblue>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D176582318-24072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Hi Jonathan, (and Lyndon),</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D176582318-24072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D176582318-24072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Thanks to both of you for =
responding.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D176582318-24072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D176582318-24072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>"Significant" was =
referencing:</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D176582318-24072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial><FONT size=3D2><FONT =
color=3D#0000ff><SPAN=20
class=3D176582318-24072006>- supports&nbsp;a&nbsp;(new) hierarchical =
OSPF=20
model</SPAN></FONT></FONT></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial><FONT size=3D2><FONT =
color=3D#0000ff><SPAN=20
class=3D176582318-24072006></SPAN></FONT></FONT></FONT><FONT =
face=3DArial><FONT=20
size=3D2><FONT color=3D#0000ff><SPAN=20
class=3D176582318-24072006>-&nbsp;supports&nbsp;inter-domain =
(inter-carrier) OSPF=20
(not supported by today's OSPF)</SPAN></FONT></FONT></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial><FONT size=3D2><FONT =
color=3D#0000ff><SPAN=20
class=3D176582318-24072006>- identifies namespace issues with GMPLS OSPF =
which do=20
not exist, and proposes extensions to =
"fix"</SPAN></FONT></FONT></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial><FONT size=3D2><FONT =
color=3D#0000ff><SPAN=20
class=3D176582318-24072006>- new extensions to OSPF are=20
specified</SPAN></FONT></FONT></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D176582318-24072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>- none of the proposed extensions align with =
CCAMP's=20
GMPLS-ASON work</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D176582318-24072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D176582318-24072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Did you have another adjective to suggest? =
We&nbsp;were=20
thinking&nbsp;"significant" was rather soft considering the above. =
Though if=20
it's just ITU-speak differences, why does the OIF liaison state it =
reflects=20
several years of work including testing? Any insight (alignment mapping =
to=20
CCAMP's work) which you or Lyndon can provide would be helpful.&nbsp;The =

divergence is&nbsp;baffling to us.</DIV>
<DIV dir=3Dltr align=3Dleft>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft>Deborah</DIV>
<DIV dir=3Dltr align=3Dleft>&nbsp;</DIV> 
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
<HR tabIndex=3D-1>
From: Sadler, Jonathan B.=20
[mailto:Jonathan.Sadler@tellabs.com] Sent: Friday, July 21, =
2006=20
11:34 AM To: Brungard, Deborah A, ALABS;=20
ccamp@ops.ietf.org Cc: Adrian Farrel Subject: RE: =
Proposed=20
response to OIF on OSPF ENNI </DIV>
<DIV></DIV>
<DIV class=3DSection1>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Hi Deborah =
and=20
Adrian,<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">I =
haven&#8217;t seen much=20
discussion of the OIF E-NNI Routing document on the CCAMP list. =
&nbsp;Can you=20
tell me what parts of the document are &#8220;significant modifications =
to the=20
operation of OSPF&#8221;?<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">Thanks,<o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p>
<st1:PersonName w:st=3D"on">Jonathan=20
Sadler</st1:PersonName><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p></o:p>
<SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p>
<DIV>
<DIV class=3DMsoNormal style=3D"TEXT-ALIGN: center" align=3Dcenter><FONT =

face=3D"Times New Roman" size=3D3><SPAN style=3D"FONT-SIZE: 12pt">
<HR tabIndex=3D-1 align=3Dcenter width=3D"100%" SIZE=3D2>
</SPAN></FONT></DIV>
<P class=3DMsoNormal><B><FONT face=3DTahoma size=3D2><SPAN=20
style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma">From:</SPAN></FONT></B><FONT=20
face=3DTahoma size=3D2><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma">=20
owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] <B><SPAN=20
style=3D"FONT-WEIGHT: bold">On Behalf Of </SPAN></B>Brungard, Deborah A, =

ALABS<BR><B><SPAN style=3D"FONT-WEIGHT: bold">Sent:</SPAN></B> Friday, =
July 21,=20
2006 9:38 AM<BR><B><SPAN style=3D"FONT-WEIGHT: bold">To:</SPAN></B>=20
ccamp@ops.ietf.org<BR><B><SPAN style=3D"FONT-WEIGHT: =
bold">Cc:</SPAN></B> Adrian=20
Farrel<BR><B><SPAN style=3D"FONT-WEIGHT: bold">Subject:</SPAN></B> =
Proposed=20
response to OIF on OSPF ENNI</SPAN></FONT><o:p></o:p></P></DIV>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
Arial">Hi,</SPAN></FONT><o:p></o:p></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">We had a =
communication=20
from OIF on their OSPF ENNI specification. You can see the original =
files on=20
</SPAN></FONT><A href=3D"http://www.olddog.co.uk/ccamp.htm"><FONT =
face=3DArial=20
size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial">http://www.olddog.co.uk/ccamp.htm</SPAN></FONT></A><FONT=20
face=3DArial color=3Dblue size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">. Having =
assembled=20
comments from several people and our discussions in <st1:City=20
w:st=3D"on"><st1:place w:st=3D"on">Montreal</st1:place></st1:City>, we =
have put=20
together the following response.</SPAN></FONT><o:p></o:p></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p></SPAN></FONT></P>
<DIV>
<P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Please =
comment on the=20
list in the next week.</SPAN></FONT><o:p></o:p></P></DIV>
<DIV>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p></SPAN></FONT></P></DIV>
<DIV>
<P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
Arial">Thanks,</SPAN></FONT><o:p></o:p></P></DIV>
<DIV>
<P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Adrian and=20
Deborah</SPAN></FONT><o:p></o:p></P></DIV>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p></SPAN></FONT></P>
<DIV>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">=3D =3D =3D =3D =3D =3D =3D =3D =3D =
=3D<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">Dear Jim,<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">We thank you for sending us the OIF ENNI =
document in=20
response to our request. While we appreciate the document being provided =
for=20
information, it is concerning that this document has not been previously =
shared=20
with CCAMP or the OSPF WG considering the document contains significant=20
modifications to the operation of OSPF and reflects OIF work over the =
last=20
several years. CCAMP has been working on GMPLS ASON for several years =
and our=20
Design Teams include OIF participants. Even though a reply was not =
requested, we=20
are replying, as we strongly recommend that the document not be =
published for=20
public information in its current form.<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">Of most concern to CCAMP is that it is not =
aligned with=20
RFC 4258 (Requirements for Generalized Multi-Protocol Label Switching =
(GMPLS)=20
Routing for the Automatically Switched Optical Network (ASON)) or the=20
to-be-published: <A=20
href=3D"ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpls-ason-rou=
ting-eval-03.txt">ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpl=
s-ason-routing-eval-03.txt</A>.=20
Considering notable OIF participants are authors of both these IETF =
documents=20
(and the same participants are contributors and the Editor for the OIF=20
document), the non-alignment is perplexing. Considering the IETF =
document is=20
ready for publication, we suggest in the interests of time, that you =
align your=20
document with the IETF document. If any questions on the interpretation =
of the=20
IETF&#8217;s work, we recommend that you either utilize the CCAMP mail =
exploder or=20
send a communication.<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">Specific comments =
include:<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal style=3D"MARGIN-LEFT: 0.25in; TEXT-INDENT: =
-0.25in"><FONT=20
face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">1.</SPAN></FONT><FONT size=3D1><SPAN=20
style=3D"FONT-SIZE: 7pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</SPAN></FONT>What is the=20
intent of this document? Will it be published as an Implementation =
Agreement=20
(IA)?<BR>The title indicates it will be an Implementation Agreement on =
GMPLS=20
OSPF extensions, but the main body of the document is a list of issues =
with=20
GMPLS OSPF. Further, your communication to us stated the document was=20
requirements on and use of OSPF-TE at the ENNI. These three views seem =
to be=20
inconsistent.<o:p></o:p></P>
<P class=3DMsoNormal style=3D"MARGIN-LEFT: 0.25in; TEXT-INDENT: =
-0.25in"><I><FONT=20
face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-STYLE: =
italic">2.</SPAN></FONT></I><I><FONT=20
size=3D1><SPAN=20
style=3D"FONT-SIZE: 7pt; FONT-STYLE: =
italic">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></FONT></I>The list of changes from the previous version (listed =
under=20
the Table of Contents) includes &#8220;<I><SPAN style=3D"FONT-STYLE: =
italic">removed=20
&#8220;intra-carrier&#8221; limitation</SPAN></I>&#8221; and the =
inclusion of Figure 1 showing the=20
OSPF ENNI for use between vendor domains and between carrier domains. =
GMPLS=20
OSPF-TE already supports inter-vendor operations. <BR>The IETF&#8217;s =
GMPLS ASON=20
routing focus has been on the use of a link-state based protocol to =
support a=20
hierarchical routing architecture (G.7715.1) within a carrier&#8217;s =
domain.=20
Requirements for using a link state protocol as an inter-domain protocol =
between=20
carriers are significantly different. We strongly disagree if you intend =
to=20
publish this document as an inter-carrier OSPF ENNI Implementation =
Agreement=20
claiming alignment with IETF RFCs without review (or agreement) by any =
of the=20
IETF Working Groups.<I><SPAN=20
style=3D"FONT-STYLE: italic"><o:p></o:p></SPAN></I></P>
<P class=3DMsoNormal style=3D"MARGIN-LEFT: 0.25in; TEXT-INDENT: =
-0.25in"><FONT=20
face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">3.</SPAN></FONT><FONT size=3D1><SPAN=20
style=3D"FONT-SIZE: 7pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</SPAN></FONT>Section=20
4.1/Table 1 and the statement under the table identifying issues with =
GMPLS=20
identifier namespaces are not correct. GMPLS identifier namespaces do =
meet ASON=20
requirements for namespace separation of the transport plane and control =
plane=20
(Section 5.2 and 5.3/Evaluation). Perhaps you are confusing OSPF and =
GMPLS OSPF?=20
As you also identified in your liaison that the key area needing review =
was the=20
support of independence of functional component to physical location, =
this=20
appears to be a key area of misunderstanding on GMPLS. We recommend =
reviewing=20
RFC3945 (GMPLS Architecture) to understand that the key architecture =
difference=20
between GMPLS and MPLS is the decoupling of the transport plane and =
control=20
plane. Additionally, RFC4394, RFC4397, and RFC4258, provide a mapping to =
ITU=20
terminology which may be helpful reading.<o:p></o:p></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">We request an additional round of =
communication of this=20
document to the IETF before approval to allow us to work with you to =
produce=20
convergence between OIF and IETF work which, we believe, will be in the =
best=20
interests of the industry.<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">Best regards,<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt"><ns0:PersonName =
w:endInsDate=3D"2006-07-21T10:10:00Z"=20
w:endInsAuthor=3D"Unknown" w:insDate=3D"2006-07-21T10:10:00Z"=20
w:insAuthor=3D"Unknown">Adrian Farrel</ns0:PersonName> and Deborah=20
Brungard,<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">CCAMP =
co-chairs<o:p></o:p></SPAN></FONT></P></DIV></DIV><PRE>=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=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
</PRE></BODY></HTML>

------_=_NextPart_001_01C6AF55.877A60BC--

Envelope-to: ccamp-data@psg.com
Delivery-date: Sun, 23 Jul 2006 15:28:54 +0000
Message-ID: <06a101c6ae6c$5a6f6a70$0a23fea9@your029b8cecfe>
Reply-To: "Adrian Farrel" <adrian@olddog.co.uk>
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: "Mack-Crane, T. Benjamin" <Ben.Mack-Crane@tellabs.com>
Cc: <ccamp@ops.ietf.org>, "Brungard, Deborah A, ALABS" <dbrungard@att.com>
Subject: Re: Working Group Last Call on draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt
Date: Sun, 23 Jul 2006 16:19:25 +0100
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Hi Ben,

Thanks. These questions give us something to chew on.

>> You appear to be making two comments in this paragraph.
>> 1. The problem statement for the I-D is not sufficiently clear.
>
> I did not make this comment, AFAIK.

It doesn't matter.

I read...
> Unfortunately I had sufficient difficulty understanding the
> problem statement that I did not immediately question the
> need for the object (hoping that clarification of the problem
> would shed light on this).
...as an issue with the problem statement.

I'm glad that the general problem statement is clear, and we only need to 
focus on the specifics of Link Capabilities.

>> 2. The requirements for (and use of) the Link Capabilities
>>    object are not clear.
>... snip ...
>>
>> With regard to the purpose and use of the Link Capabilities
>> object, this is driven mainly by the material in section 4.3.
>... snip ...
>> What don't you understand? What are your questions?
>
> OK, here is section 4.3 with some questions:

Excellent. Thanks.

>   It is useful for the ingress node of an LSP to know the link
>  capabilities of the link between the network and the egress node.
>
> Do the ingress and egress nodes terminate the LSP to be setup?

Yes, indeed. Rooted in RFC3031, section 3.15.

> How is the "link between the network and the egress node"
> determined?

Good question. Clearly if there is only one such link, we are done. In the 
case of a "dual-homed" egress, the Link Capability object may report on more 
than one link. This is, perhaps not abundantly clear, but it is covered by 
the final paragraph of section 5.3.

   This object MAY also be used to exchange more than one bundled link
   capability. In this case, the following ordering MUST be followed:
   one identifier subobject (Type 1, 2 or 4) MUST be inserted before any
   capability subobject (Type 64 or 65) to which it refers.

>   This information may allow the ingress node to tailor its LSP request
>   to fit those capabilities and to better utilize network resources
>   with regard to those capabilities.
>
> Generally an LSP setup request is generated by a network operator, who
> has a particular purpose in mind.  What leeway does the ingress LSR have
> to modify this request?

I think that this is the difference between LSPs under the parentage of a 
Call, and LSPs directly controlled by the operator.
When an operator requests an LSP directly, you are quite right that there is 
no scope for the LSR (i.e. the connection controller) to vary the request 
for the LSP.
However, when an operator requests a service, the service is converted into 
one or more LSP requests. A good example of this might be VCAT.
So, when an operator requests a service and a Call is used to coordinate the 
end points, the Call Controller has some leeway about what Connections 
(LSPs) it instantiates to satisfy the call.

> Generally networks work best when there are uniform means of
> providing connectivity between clients of the network.  What
> kinds of "tailoring" are envisioned?

I think that the VCAT example is the best. The ingress may have the ability 
to generate a whole pile of signals, but the egress may only have the 
ability to terminate a limited set of signals.
You might regard this as choosing between sub-layers, I suppose.

>  In particular, this may be used to achieve end-to-end spectral
>  routing attribute negotiation for signal quality negotiation (such as
>  BER) in photonic environments where network edges are signal
>  regeneration capable. Similarly, it may be used to provide end-to-end
>  spatial routing attribute negotiation in multi-area routing
>  environments, in particular, when TE links have been bundled based on
>  technology specific attributes.
>
>What is "end-to-end spectral routing attribute negotiation"?

It is a completely ridiculous and over-florid way of saying "end-to-end 
lambda negotiation for use in transparent optical networks".

>What is "end-to-end spatial routing attribute negotiation"?

Similarly poor choice of words for "end-to-end port negotiation for use in 
fiber switching networks".

Thanks for flagging these.

>  Call setup may provide a suitable mechanism to exchange information
>   for this purpose, although several other possibilities exist.
>
> Just because a mechanism can be defined does not mean that it should be.
> Why is it necessary to define this mechanism, and add complexity to call
> control, if another mechanism is required to do the same thing in cases
> where call control is not used?

Hmmm.
Well that is a good question.

I guess the answer is:
Because the Call control mechanism a good one where this type of information 
(i.e. access connectivity information such as access addressing) is often 
exchanged.
Maybe more important are:
- this mechanism is one that several implementers want to /  have
  implemented.
- no-one raised any concerns about this mechanism during a
  couple of years of discussion of this process and during WG
  last call.
It is possible that this is not the best way of achieving this (although it 
is my favourite), but if other mechanisms exist then (as Yakov fondly says) 
the market will decide which is the best mechanism.

Cheers,
Adrian

Envelope-to: ccamp-data@psg.com
Delivery-date: Fri, 21 Jul 2006 18:24:05 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: Working Group Last Call on draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt
Date: Fri, 21 Jul 2006 13:23:01 -0500
Message-ID: <A1A52203CA93634BA1748887B9993AEA02FC537A@USNVEX1.tellabs-west.tellabsinc.net>
Thread-Topic: Working Group Last Call on draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt
Thread-Index: AcasLkkeL4/zR11yQP+yraHCqSnNPwArnDTA
From: "Mack-Crane, T. Benjamin" <Ben.Mack-Crane@tellabs.com>
To: "Adrian Farrel" <adrian@olddog.co.uk>
Cc: <ccamp@ops.ietf.org>, "Brungard, Deborah A, ALABS" <dbrungard@att.com>
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="us-ascii"

Hi Adrian,

Some questions below...

Regards,
Ben

> -----Original Message-----
> From: Adrian Farrel [mailto:adrian@olddog.co.uk]
> Sent: Thursday, July 20, 2006 1:55 PM
> To: Mack-Crane, T. Benjamin
> Cc: ccamp@ops.ietf.org; Brungard, Deborah A, ALABS
> Subject: Re: Working Group Last Call on
draft-ietf-ccamp-gmpls-rsvp-te-
> call-00.txt
>=20
> Hi Ben,
>=20
.=2E. snip ...
>=20
> You appear to be making two comments in this paragraph.
> 1. The problem statement for the I-D is not sufficiently clear.

I did not make this comment, AFAIK.

> 2. The requirements for (and use of) the Link Capabilities
>    object are not clear.
.=2E. snip ...
>=20
> With regard to the purpose and use of the Link Capabilities object,
this
> is
> driven mainly by the material in section 4.3.=20
.=2E. snip ...
> What don't you understand? What are your questions?

OK, here is section 4.3 with some questions:

   It is useful for the ingress node of an LSP to know the link
   capabilities of the link between the network and the egress node.

Do the ingress and egress nodes terminate the LSP to be setup?

How is the "link between the network and the egress node" determined?

   This information may allow the ingress node to tailor its LSP request
   to fit those capabilities and to better utilize network resources
   with regard to those capabilities.

Generally an LSP setup request is generated by a network operator, who
has a particular purpose in mind.  What leeway does the ingress LSR have
to modify this request?

Generally networks work best when there are uniform means of providing
connectivity between clients of the network.  What kinds of "tailoring"
are envisioned?

   In particular, this may be used to achieve end-to-end spectral
   routing attribute negotiation for signal quality negotiation (such as
   BER) in photonic environments where network edges are signal
   regeneration capable. Similarly, it may be used to provide end-to-end
   spatial routing attribute negotiation in multi-area routing
   environments, in particular, when TE links have been bundled based on
   technology specific attributes.

What is "end-to-end spectral routing attribute negotiation"?
What is "end-to-end spatial routing attribute negotiation"?

  Call setup may provide a suitable mechanism to exchange information
  for this purpose, although several other possibilities exist.

Just because a mechanism can be defined does not mean that it should be.
Why is it necessary to define this mechanism, and add complexity to call
control, if another mechanism is required to do the same thing in cases
where call control is not used?
=20
>=20
> Thanks,
> Adrian
>=20
>=20
>=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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

Envelope-to: ccamp-data@psg.com
Delivery-date: Fri, 21 Jul 2006 16:48:02 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6ACE5.450A8AB5"
Subject: RE: Proposed response to OIF on OSPF ENNI
Date: Fri, 21 Jul 2006 12:46:56 -0400
Message-ID: <0901D1988E815341A0103206A834DA07F1A0FB@mdmxm02.ciena.com>
Thread-Topic: Proposed response to OIF on OSPF ENNI
Thread-Index: Acas0Ha/aYxFikOBS5m873SVRoVJxgAACLxQAAG2L0A=
From: "Ong, Lyndon" <Lyong@Ciena.com>
To: "Brungard, Deborah A, ALABS" <dbrungard@att.com>, <ccamp@ops.ietf.org>
Cc: "Adrian Farrel" <adrian@olddog.co.uk>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6ACE5.450A8AB5
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Deborah,
=20
Just to provide some historical background, the draft text that was
liaised to CCAMP=20
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.
=20
That being said, any specific comments will certainly be looked over
carefully.
=20
I'll have more detailed comments in a future message.
=20
Thanks,
=20
Lyndon

________________________________

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

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

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

=20

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

=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

------_=_NextPart_001_01C6ACE5.450A8AB5
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns:o =3D "urn:schemas-microsoft-com:office:office" xmlns:st1 =
=3D=20
"urn:schemas-microsoft-com:office:smarttags"><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.2912" name=3DGENERATOR></HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D463560715-21072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Hi Deborah,</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D463560715-21072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D463560715-21072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Just to provide some historical background, the =
draft text=20
that was liaised to CCAMP </FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D463560715-21072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>was actually designed to align more closely to =
the ASON=20
evaluation results than</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D463560715-21072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>previous documents</FONT></SPAN><SPAN=20
class=3D463560715-21072006><FONT face=3DArial color=3D#0000ff =
size=3D2>.&nbsp; However,=20
I think it is more in "ASON-speak" than =
"GMPLS-speak"</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D463560715-21072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>since our starting point was G.7715 and =
G.7715.1, and maybe=20
that is leading to some</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D463560715-21072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>greater impression of misalignment than there =
really=20
is.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D463560715-21072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D463560715-21072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>That being said, any specific comments will =
certainly be=20
looked over carefully.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D463560715-21072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D463560715-21072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>I'll have more detailed comments in a future=20
message.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D463560715-21072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D463560715-21072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Thanks,</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D463560715-21072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D463560715-21072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Lyndon</FONT></SPAN></DIV><BR>
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
<HR tabIndex=3D-1>
<FONT face=3DTahoma size=3D2><B>From:</B> owner-ccamp@ops.ietf.org=20
[mailto:owner-ccamp@ops.ietf.org] <B>On Behalf Of </B>Brungard, Deborah =
A,=20
ALABS<BR><B>Sent:</B> Friday, July 21, 2006 7:38 AM<BR><B>To:</B>=20
ccamp@ops.ietf.org<BR><B>Cc:</B> Adrian Farrel<BR><B>Subject:</B> =
Proposed=20
response to OIF on OSPF ENNI<BR></FONT><BR></DIV>
<DIV></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D845551814-21072006>Hi,</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial><FONT size=3D2><FONT =
color=3D#0000ff><FONT=20
face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D845551814-21072006></SPAN></FONT></FONT></FONT></FONT>&nbsp;</DIV=
>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial><FONT =
color=3D#0000ff><FONT size=3D2><SPAN=20
class=3D845551814-21072006>We had a communication from OIF on their OSPF =
ENNI=20
specification. </SPAN>You can see the original files on =
</FONT></FONT></FONT><A=20
href=3D"http://www.olddog.co.uk/ccamp.htm"><U><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>http://www.olddog.co.uk/ccamp.htm</FONT></U></A><FONT =
face=3DArial><FONT=20
color=3D#0000ff><FONT size=3D2>.<SPAN class=3D845551814-21072006> Having =
assembled=20
comments from several people and our discussions in Montreal, we have =
put=20
together the following response.</SPAN></FONT></FONT></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial><FONT =
color=3D#0000ff><FONT size=3D2><SPAN=20
class=3D845551814-21072006></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
<DIV dir=3Dltr><SPAN class=3D845551814-21072006><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>Please comment on the list in the next =
week.</FONT></SPAN></DIV>
<DIV dir=3Dltr><SPAN class=3D845551814-21072006><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr><SPAN class=3D845551814-21072006><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>Thanks,</FONT></SPAN></DIV>
<DIV dir=3Dltr><SPAN class=3D845551814-21072006><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>Adrian and Deborah</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff=20
size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT face=3D"Times =
New Roman"=20
size=3D3><SPAN class=3D427551414-21072006>=3D =3D =3D =3D =3D =3D =3D =
=3D =3D =3D</SPAN></FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT face=3D"Times =
New Roman"=20
size=3D3>Dear Jim,</FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><o:p><FONT =
face=3D"Times New Roman"=20
size=3D3>&nbsp;</FONT></o:p></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT face=3D"Times =
New Roman"=20
size=3D3>We thank you for sending us the OIF ENNI document in response =
to our=20
request. While we appreciate the document being provided for =
information, it is=20
concerning that this document has not been previously shared with CCAMP =
or the=20
OSPF WG considering the document contains significant modifications to =
the=20
operation of OSPF and reflects OIF work over the last several years. =
CCAMP has=20
been working on GMPLS ASON for several years and our Design Teams =
include OIF=20
participants. Even though a reply was not requested, we are replying, as =
we=20
strongly recommend that the document not be published for public =
information in=20
its current form.<SPAN class=3D463560715-21072006><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>&nbsp;</FONT></SPAN></FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><o:p><FONT =
face=3D"Times New Roman"=20
size=3D3>&nbsp;</FONT></o:p></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT face=3D"Times =
New Roman"=20
size=3D3>Of most concern to CCAMP is that it is not aligned with RFC =
4258=20
(Requirements for Generalized Multi-Protocol Label Switching (GMPLS) =
Routing for=20
the Automatically Switched Optical Network (ASON)) or the =
to-be-published:=20
</FONT><A=20
href=3D"ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpls-ason-rou=
ting-eval-03.txt"><FONT=20
face=3D"Times New Roman"=20
size=3D3>ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpls-ason-ro=
uting-eval-03.txt</FONT></A><FONT=20
face=3D"Times New Roman" size=3D3>. Considering notable OIF participants =
are authors=20
of both these IETF documents (and the same participants are contributors =
and the=20
Editor for the OIF document), the non-alignment is perplexing. =
Considering the=20
IETF document is ready for publication, we suggest in the interests of =
time,=20
that you align your document with the IETF document. If any questions on =
the=20
interpretation of the IETF&#8217;s work, we recommend that you either =
utilize the=20
CCAMP mail exploder or send a communication.</FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><o:p><FONT =
face=3D"Times New Roman"=20
size=3D3>&nbsp;</FONT></o:p></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT face=3D"Times =
New Roman"=20
size=3D3>Specific comments include:</FONT></P>
<P class=3DMsoNormal=20
style=3D"MARGIN: 0in 0in 0pt 0.25in; TEXT-INDENT: -0.25in; mso-list: l0 =
level1 lfo1; tab-stops: list .25in"><SPAN=20
style=3D"mso-fareast-font-family: 'Times New Roman'"><SPAN=20
style=3D"mso-list: Ignore"><FONT face=3D"Times New Roman"><FONT=20
size=3D3>1.</FONT><SPAN=20
style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></FONT></SPAN></SPAN><FONT face=3D"Times New Roman" size=3D3>What =
is the=20
intent of this document? Will it be published as an Implementation =
Agreement=20
(IA)?<BR>The title indicates it will be an Implementation Agreement on =
GMPLS=20
OSPF extensions, but the main body of the document is a list of issues =
with=20
GMPLS OSPF. Further, your communication to us stated the document was=20
requirements on and use of OSPF-TE at the ENNI. These three views seem =
to be=20
inconsistent.</FONT></P>
<P class=3DMsoNormal=20
style=3D"MARGIN: 0in 0in 0pt 0.25in; TEXT-INDENT: -0.25in; mso-list: l0 =
level1 lfo1; tab-stops: list .25in"><FONT=20
face=3D"Times New Roman"><I><SPAN=20
style=3D"mso-fareast-font-family: 'Times New Roman'; =
mso-bidi-font-weight: bold"><SPAN=20
style=3D"mso-list: Ignore"><FONT size=3D3>2.</FONT><SPAN=20
style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></SPAN></SPAN></I><FONT size=3D3>The list of changes from the =
previous=20
version (listed under the Table of Contents) includes &#8220;<I><SPAN=20
style=3D"mso-bidi-font-weight: bold">removed &#8220;intra-carrier&#8221; =

limitation<SPAN=20
style=3D"mso-bidi-font-weight: bold; mso-bidi-font-style: italic"><FONT=20
size=3D3>&#8221; and the inclusion of =
Figure 1 showing the=20
OSPF ENNI for use between vendor domains and between carrier domains. =
GMPLS=20
OSPF-TE already supports inter-vendor operations. The IETF&#8217;s =
GMPLS ASON=20
routing focus has been on the use of a link-state based protocol to =
support a=20
hierarchical routing architecture (G.7715.1) within a carrier&#8217;s =
domain.=20
Requirements for using a link state protocol as an inter-domain protocol =
between=20
carriers are significantly different. We strongly disagree if you intend =
to=20
publish this document as an inter-carrier OSPF ENNI Implementation =
Agreement=20
claiming alignment with IETF RFCs without review (or agreement) by any =
of the=20
IETF Working Groups.<o:p></o:p>
<FONT=20
face=3D"Times New Roman"><SPAN=20
style=3D"mso-fareast-font-family: 'Times New Roman'"><SPAN=20
style=3D"mso-list: Ignore">3.<SPAN=20
style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
Section 4.1/Table 1 and the =
statement under=20
the table identifying issues with GMPLS identifier namespaces are not =
correct.=20
GMPLS identifier namespaces do meet ASON requirements for namespace =
separation=20
of the transport plane and control plane (Section 5.2 and =
5.3/Evaluation).=20
Perhaps you are confusing OSPF and GMPLS OSPF? As you also identified in =
your=20
liaison that the key area needing review was the support of independence =
of=20
functional component to physical location, this appears to be a key area =
of=20
misunderstanding on GMPLS. We recommend reviewing RFC3945 (GMPLS =
Architecture)=20
to understand that the key architecture difference between GMPLS and =
MPLS is the=20
decoupling of the transport plane and control plane. Additionally, =
RFC4394,=20
RFC4397, and RFC4258, provide a mapping to ITU terminology which may be =
helpful=20
reading.
<o:p>&nbsp;</o:p>
We request an additional round of communication of this =
document to the=20
IETF before approval to allow us to work with you to produce convergence =
between=20
OIF and IETF work which, we believe, will be in the best interests of =
the=20
industry.
<o:p>&nbsp;</o:p>
Best regards,
<FONT=20
face=3D"Times New Roman"><st1:PersonName w:st=3D"on">Adrian =
Farrel</st1:PersonName>=20
and Deborah Brungard,
CCAMP co-chairs</DIV></BODY></HTML>

------_=_NextPart_001_01C6ACE5.450A8AB5--

Envelope-to: ccamp-data@psg.com
Delivery-date: Fri, 21 Jul 2006 16:31:36 +0000
Message-ID: <44C10124.2030901@cisco.com>
Date: Fri, 21 Jul 2006 12:30:28 -0400
From: Acee Lindem <acee@cisco.com>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: "Sadler, Jonathan B." <Jonathan.Sadler@tellabs.com>
CC: Adrian Farrel <adrian@olddog.co.uk>, ccamp@ops.ietf.org
Subject: Re: OSPF ASON Routing Solution
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: a=rsa-sha1; q=dns; l=4320; t=1153499430; x=1154363430; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acee@cisco.com; z=From:Acee=20Lindem=20<acee@cisco.com> |Subject:Re=3A=20OSPF=20ASON=20Routing=20Solution; X=v=3Dcisco.com=3B=20h=3DJEaT/PJZXmelX6ToU0domypvAVA=3D; b=Ev8b8DgZPU2StzSdhKTNZsSTNbLf+7JPInMomhBcP1O63n2LU8Hmv76wNwTBUJBvyj9x2lsf E3/NDCz8Igk9Vp2gL/SqDDyIWiHOkpjJn3AD7RnlHB/b2Zno5kvjhWWm;
Authentication-Results: sj-dkim-5.cisco.com; header.From=acee@cisco.com; dkim=pass ( sig from cisco.com verified; );

Hi Jonathan,

Sadler, Jonathan B. wrote:
> Hi Acee,
>
> I agree that the hierarchy used by ASON can be implemented by specifying
> how redistribution (i.e. import/export) is done between parent/child
> Routing Areas.  In fact, that's captured appendix I of G.7715.
>
> What I am unclear on is what you mean by "OSPF instances".  Since the
> import/export is done between ASON areas, this can also be done between
> OSPF areas. 
NO. OSPF areas are part of a single OSPF routing domain with very 
precise protocol
specification of the duties of an OSPF router connecting to multiple 
areas (an ABR or
Area Border Router). This document doesn't even come close to specify 
what needs to be
done to support an area hierarchy other the existing backbone with a 
single layer
of non-backbone areas.

Furthermore, if OSPF is  to undertake an alternate area hierarchy as a 
requirement than
that work MUST be done in the OSPF WG.
> If you mean "OSPF instance" in the context of a single OSPF
> area, then we are in complete agreement.
>   
An OSPF instance can have multiple areas. However, I believe the GMPLS TE
extensions have only been standardized for a single area.

Thanks,
Acee

>
> Looking forward to productively moving this work forward,
>
> Jonathan Sadler
>
> -----Original Message-----
> From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On
> Behalf Of Acee Lindem
> Sent: Thursday, July 20, 2006 4:40 PM
> To: Adrian Farrel
> Cc: ccamp@ops.ietf.org
> Subject: Re: OSPF ASON Routing Solution
>
> Hi Adrian, Dimitri, et al,
>
> No objection on my part. However, I wanted to make a clarification that
> may or may not be obvious to everyone. In Montreal, Dimitri
> and I sat down and discussed my comments on the hierarchical
> dissemination of ASON routing information between RAs (Routing Areas
> in ASON parlance).
>
> Today OSPF does not support an area hierarchy other than the
> backbone and non-backbone areas. This specification for ASON  should
> not be considered a partial specification of support in OSPF for a new
> area hierarchy (specific requirements are stated in the CCAMP
> document references). Rather, it should be conceptually viewed as rules
> for importing and exporting GMPLS TE data between separate
> OSPF instances  (one instance per ASON RA). This was the motivation
> for my comment on restating the inter-RA advertisement rules in term of
> import/export rather than flooding.
>
> Thanks,
> Acee 
>
> Adrian Farrel wrote:
>   
>> Just a refresh in case you were travelling.
>>
>> I am seeking objections to this draft becoming a WG document.
>>
>> Adrian
>> ----- Original Message ----- From: "Adrian Farrel"
>>     
> <adrian@olddog.co.uk>
>   
>> To: <ccamp@ops.ietf.org>
>> Sent: Wednesday, July 12, 2006 8:10 PM
>> Subject: OSPF ASON Routing Solution
>>
>>
>>     
>>> Hi,
>>> On Monday in CCAMP we discussed 
>>> draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt the solutions 
>>> draft for OSPF in ASON routing.
>>>
>>> There is agreement from the OSPF WG chair that we are not treading on
>>>       
>
>   
>>> toes, and the meeting seemed to say that this was pretty stable.
>>>
>>> So a this is a quick poll to see if anyone objects to this becoming a
>>>       
>
>   
>>> WG draft.
>>> NB, this is a charter item and we have an obligation to work on this 
>>> for the ITU-T.
>>>
>>> Thanks,
>>> Adrian
>>>
>>> PS Note that a solution does not have to be 100% perfect to become a 
>>> WG draft.
>>>
>>>
>>>
>>>
>>>
>>>       
>>     
> ============================================================
> 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
> ============================================================
>
>   

Envelope-to: ccamp-data@psg.com
Delivery-date: Fri, 21 Jul 2006 15:37:06 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6ACDB.7D97F0B5"
Subject: RE: Proposed response to OIF on OSPF ENNI
Date: Fri, 21 Jul 2006 10:34:08 -0500
Message-ID: <A1A52203CA93634BA1748887B9993AEA02FC52A6@USNVEX1.tellabs-west.tellabsinc.net>
Thread-Topic: Proposed response to OIF on OSPF ENNI
Thread-Index: Acas0Ha/aYxFikOBS5m873SVRoVJxgAACLxQAAHPZJA=
From: "Sadler, Jonathan B." <Jonathan.Sadler@tellabs.com>
To: "Brungard, Deborah A, ALABS" <dbrungard@att.com>, <ccamp@ops.ietf.org>
Cc: "Adrian Farrel" <adrian@olddog.co.uk>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6ACDB.7D97F0B5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="us-ascii"

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

------_=_NextPart_001_01C6ACDB.7D97F0B5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset="us-ascii"

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:p=3D"urn:schemas-microsoft-com:office:powerpoint" xmlns:oa=3D"urn:sch=
emas-microsoft-com:office:activation" xmlns:st1=3D"urn:schemas-microsoft-co=
m:office:smarttags" xmlns=3D"http://www.w3.org/TR/REC-html40"
xmlns:ns0=3D"urn:schemas-microsoft-com:office:smarttags">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]--><o:SmartTagType
 namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" name=3D"City"
 downloadurl=3D"http://www.5iamas-microsoft-com:office:smarttags"/>
<o:SmartTagType namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"place" downloadurl=3D"http://www.5iantlavalamp.com/"/>
<o:SmartTagType namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"PersonName" downloadurl=3D"http://www.microsoft.com"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"MS Mincho";
	panose-1:2 2 6 9 4 2 5 8 3 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:"\@MS Mincho";
	panose-1:2 2 6 9 4 2 5 8 3 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:blue;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dblue>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Hi Deborah and Adrian,<o:p></o:p></spa=
n></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

I haven&#8217;t seen much discussion of
the OIF E-NNI Routing document on the CCAMP list. &nbsp;Can you tell me what
parts of the document are &#8220;significant modifications to the operation=
 of
OSPF&#8221;?<o:p></o:p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Thanks,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><st1:PersonName w:st=3D"on"><font size=3D2 color=3Dnavy
 face=3DArial><span style=3D'font-size:10.0pt;font-family:Arial;color:navy'=
>Jonathan
 Sadler</span></font></st1:PersonName><font size=3D2 color=3Dnavy face=3DAr=
ial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p></o:p></span><=
/font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font siz=
e=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span style=3D'font-si=
ze:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'>
owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] <b><span
style=3D'font-weight:bold'>On Behalf Of </span></b>Brungard, Deborah A, ALA=
BS<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Friday, July 21, 2006 =
9:38
AM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> ccamp@ops.ietf.org<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> Adrian Farrel<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> Proposed response t=
o OIF
on OSPF ENNI</span></font><o:p></o:p></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Hi,</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

We had a communication from OIF on the=
ir
OSPF ENNI specification. You can see the original files on <a
href=3D"http://www.olddog.co.uk/ccamp.htm">http://www.olddog.co.uk/ccamp.=
htm</a>. Having assembled comments from several people and our discuss=
ions
in <st1:City w:st=3D"on"><st1:place w:st=3D"on">Montreal</st1:place></st1:C=
ity>, we
have put together the following response.<o:p></o:p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Please comment on the list in the next
week.</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Thanks,</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Adrian and Deborah</span></font><o:p><=
/o:p></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>=3D =3D =3D =3D =3D =3D =3D =3D =3D =3D<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>Dear Jim,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

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.<o:p></o:p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

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: <a
href=3D"ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpls-ason-routi=
ng-eval-03.txt">ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpls-as=
on-routing-eval-03.txt</a>.
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&#8217;s work, we recommend that you either utilize the CCAMP mail expl=
oder
or send a communication.<o:p></o:p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>Specific comments include:<o:p></o:p></span></font></p>

1.<=
font
size=3D1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </s=
pan>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></o:p>

<p class=3DMsoNormal style=3D'margin-left:.25in;text-indent:-.25in'><i><font
size=3D3 face=3D"Times New Roman"><span style=3D'font-size:12.0pt;font-styl=
e:italic'>2.</span></font></i><i><font
size=3D1><span style=3D'font-size:7.0pt;font-style:italic'>&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;
</span></font></i>The list of changes from the previous version (listed und=
er
the Table of Contents) includes &#8220;<i><span style=3D'font-style:italic'=
>removed
&#8220;intra-carrier&#8221; limitation</span></i>&#8221; 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. <b=
r>
The IETF&#8217;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&#8217;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.<i><span style=3D'font-style:i=
talic'><o:p></o:p></span></i></p>

3.<=
font
size=3D1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </s=
pan>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.<o:p></o:p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>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.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>Best regards,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'><ns0:PersonName w:insAuthor=3D"Unknown" w:insDate=3D"2006-07-21T10:=
10:00Z"
 w:endInsAuthor=3D"Unknown" w:endInsDate=3D"2006-07-21T10:10:00Z">Adrian Fa=
rrel</ns0:PersonName>
and Deborah Brungard,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>CCAMP co-chairs<o:p></o:p></span></font></p>

</div>

</div>

<pre>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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
</pre></body>

</html>

------_=_NextPart_001_01C6ACDB.7D97F0B5--

Envelope-to: ccamp-data@psg.com
Delivery-date: Fri, 21 Jul 2006 15:29:33 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: OSPF ASON Routing Solution
Date: Fri, 21 Jul 2006 10:25:26 -0500
Message-ID: <A1A52203CA93634BA1748887B9993AEA02FC5293@USNVEX1.tellabs-west.tellabsinc.net>
Thread-Topic: OSPF ASON Routing Solution
Thread-Index: AcasRUYftVWmib9TS1qiq18qIdF3FQAk0jxQAABS3YA=
From: "Sadler, Jonathan B." <Jonathan.Sadler@tellabs.com>
To: "Acee Lindem" <acee@cisco.com>, "Adrian Farrel" <adrian@olddog.co.uk>
Cc: <ccamp@ops.ietf.org>
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="us-ascii"

Hi Acee,

I agree that the hierarchy used by ASON can be implemented by specifying
how redistribution (i.e. import/export) is done between parent/child
Routing Areas.  In fact, that's captured appendix I of G.7715.

What I am unclear on is what you mean by "OSPF instances".  Since the
import/export is done between ASON areas, this can also be done between
OSPF areas.  If you mean "OSPF instance" in the context of a single OSPF
area, then we are in complete agreement.

Looking forward to productively moving this work forward,

Jonathan Sadler

-----Original Message-----
From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On
Behalf Of Acee Lindem
Sent: Thursday, July 20, 2006 4:40 PM
To: Adrian Farrel
Cc: ccamp@ops.ietf.org
Subject: Re: OSPF ASON Routing Solution

Hi Adrian, Dimitri, et al,

No objection on my part. However, I wanted to make a clarification that
may or may not be obvious to everyone. In Montreal, Dimitri
and I sat down and discussed my comments on the hierarchical
dissemination of ASON routing information between RAs (Routing Areas
in ASON parlance).

Today OSPF does not support an area hierarchy other than the
backbone and non-backbone areas. This specification for ASON  should
not be considered a partial specification of support in OSPF for a new
area hierarchy (specific requirements are stated in the CCAMP
document references). Rather, it should be conceptually viewed as rules
for importing and exporting GMPLS TE data between separate
OSPF instances  (one instance per ASON RA). This was the motivation
for my comment on restating the inter-RA advertisement rules in term of
import/export rather than flooding.

Thanks,
Acee=20

Adrian Farrel wrote:
> Just a refresh in case you were travelling.
>
> I am seeking objections to this draft becoming a WG document.
>
> Adrian
> ----- Original Message ----- From: "Adrian Farrel"
<adrian@olddog.co.uk>
> To: <ccamp@ops.ietf.org>
> Sent: Wednesday, July 12, 2006 8:10 PM
> Subject: OSPF ASON Routing Solution
>
>
>> Hi,
>> On Monday in CCAMP we discussed=20
>> draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt the solutions=20
>> draft for OSPF in ASON routing.
>>
>> There is agreement from the OSPF WG chair that we are not treading on

>> toes, and the meeting seemed to say that this was pretty stable.
>>
>> So a this is a quick poll to see if anyone objects to this becoming a

>> WG draft.
>> NB, this is a charter item and we have an obligation to work on this=20
>> for the ITU-T.
>>
>> Thanks,
>> Adrian
>>
>> PS Note that a solution does not have to be 100% perfect to become a=20
>> WG draft.
>>
>>
>>
>>
>>
>
>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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

Envelope-to: ccamp-data@psg.com
Delivery-date: Fri, 21 Jul 2006 15:02:18 +0000
Message-ID: <00c301c6acd6$9db37340$6501a8c0@movaz.com>
From: "Igor Bryskin" <ibryskin@movaz.com>
To: <Dimitri.Papadimitriou@alcatel.be>
Cc: "Acee Lindem" <acee@cisco.com>, "Adrian Farrel" <adrian@olddog.co.uk>, <ccamp@ops.ietf.org>, <owner-ccamp@ops.ietf.org>
Subject: Re: OSPF ASON Routing Solution
Date: Fri, 21 Jul 2006 11:01:30 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

See  in-line.
Igor

----- Original Message ----- 
From: <Dimitri.Papadimitriou@alcatel.be>
To: "Igor Bryskin" <ibryskin@movaz.com>
Cc: "Acee Lindem" <acee@cisco.com>; "Adrian Farrel" <adrian@olddog.co.uk>;
<ccamp@ops.ietf.org>; <owner-ccamp@ops.ietf.org>
Sent: Friday, July 21, 2006 10:36 AM
Subject: Re: OSPF ASON Routing Solution

> igor -
>
>
> i don't think that someone claimed that OSPF-TE is a superset of OSPF or
> whatsover the former (as other applications) just build on existing OSPF
> RFCs (and mechanisms)
>
> note that RFC 2370 states "The information contained in Opaque LSAs may be
> used directly by OSPF

IB>> I aggree that IFF OSPF uses Opaque LSAs for its *own* purposes, that
whatever comes out of such use *is* an extension to OSPF

 or indirectly by some application
> wishing to distribute information throughout the OSPF domain."

IB>> And I claim that such application is not an extension to OSPF, rather,
it is exactly what is stated above - an application using OSPF opaque LSAs

reason why
> GR, Router capabilities and TE like applications can make use of opaque
> LSAs (that you restrict to TE only btw); hence your assertion "RFC2370
> does not provide a way for extending OSPF" is not correct
>
> this said your digression falls imho outside the scope of the present poll
> (if you want to re-discuss GMPLS/OSPF-TE vs OSPF i suggest you start from
> the beginning not from the middle and probably direct your concern at the
> owning WG)

I disagree with that. I have joined this discussion when Adrian asked Acee
whether he as a chair of OSPF WG had any objections wrt ASON OSPF document,
and my point is why OSPF WG should care about this solution one way or the
other.

Igor
>
> ps: all this remembers me the discussion we had 3 years ago in Vienna (but
> was on BGP at that time) and we all know where and how such discussions
> end
>
>
> -d.
>
>
>
>
>
>
> "Igor Bryskin" <ibryskin@movaz.com>
> 21/07/2006 16:04
>
>         To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
>         cc:     "Acee Lindem" <acee@cisco.com>, "Adrian Farrel"
> <adrian@olddog.co.uk>, <ccamp@ops.ietf.org>, <owner-ccamp@ops.ietf.org>
>         Subject:        Re: OSPF ASON Routing Solution
>
>
> Dimitri,
>
> Please, see in line.
>
> Igor
>
> ----- Original Message ----- 
> From: <Dimitri.Papadimitriou@alcatel.be>
> To: "Igor Bryskin" <ibryskin@movaz.com>
> Cc: "Acee Lindem" <acee@cisco.com>; "Adrian Farrel" <adrian@olddog.co.uk>;
> <ccamp@ops.ietf.org>; <owner-ccamp@ops.ietf.org>
> Sent: Thursday, July 20, 2006 8:05 PM
> Subject: Re: OSPF ASON Routing Solution
>
>
> > the comment of acee will be addressed - stated already in previous
> e-mail
> > b/f IETF 66 meeting -
> >
> > as ASON RC(PC) are OSPF engines defined in RFC 2328, routing info
> exchange
> > makes use of RFC 2370 mechanism (which afaik is an intrinsic part of
> > OSPF), etc., information encoding (in top-level TLVs) are defined in RFC
> > 3630 and co. whereas all these are under OSPF WG resp. ... this leads me
> > to the question if not extensions to OSPF - extensions of which protocol
> ?
>
> RFC2370 does not provide a way for extending OSPF, rather, it exposes OSPF
> advertising, flooding and synchronization mechanisms to be used by other
> (non-OSPF) applications. OSPF-TE, ASON OSPF, L1VPN OSPF. mesh membership,
> node capability discovery, etc. are such applications. To answer your
> question OSPF-TE is not an extension to OSPF, rather, it is a separate
> protocol.
>
> Let me prove you this point. Consider RSVP (RFC2205) and RSVP-TE. The
> latter
> *is* an extension of the former, because it understands and uses all basic
> elements, objects (e.g. SESSION, SENDER_TEMPLATE, etc.) and *in addition*
> it
> introduces new elements/objects (e.g. SESSION_ATTRIBUTES, LABEL, etc.).
> You
> can say that RSVP-TE is a superset of RSVP. likewise, GMPLS RSVP is a
> superset of RSVP-TE.
> Let us now consider OSPF and OSPF-TE. The latter neither understands nor
> uses basic OSPF LSAs type 1,2,3,4,5. Rather it understands only opaque
> LSAs
> (type 10) with semantics specifically designed for the TE application.
> These
> semantics are not understood by OSPF. You surely can not claim that
> OSPF-TE
> is a superset of OSPF, hence OSPF-TE is not an extension to OSPF.
> Furthermore, TE routing areas do not have to match IP routing areas and
> may
> have completely different area hierarchies. ASON OSPF (I forgot the name
> of
> the author) is a shining proof to that.
>
> >
> > the main point is that RFC 2370 stating "The information contained in
> > Opaque LSAs may be used directly by OSPF or indirectly by some
> application
> > wishing to distribute information throughout the OSPF domain." puts your
> > comment in the old battle field bucket since Opaque LSAs have been
> applied
> > since many years to (OSPF-)TE, and GR applications ... hence, are you
> also
> > objecting to these and suggest to have a specific and dedicated protocol
> > mechanism per application
>
> I can see how OSPF can use opaque LSAs for experimantation purposes and
> for
> extending itself, but this is not what,say, OSPF-TE is about.
>
> >
> > ps: i forgot the name of the author of OSPF ext. for L1VPN
>
> If you are talking about L1VPN-OSPF, this is not OSPF ext for L1VPN,
> rather,
> OSPF based L1VPN auto-discovery solution
>
> Igor
>
> >
> >
> >
> >
> > "Igor Bryskin" <ibryskin@movaz.com>
> > Sent by: owner-ccamp@ops.ietf.org
> > 21/07/2006 00:05
> >
> >         To:     "Acee Lindem" <acee@cisco.com>, "Adrian Farrel"
> > <adrian@olddog.co.uk>
> >         cc:     <ccamp@ops.ietf.org>
> >         Subject:        Re: OSPF ASON Routing Solution
> >
> >
> > Hi Acee,
> >
> > I agree with your comment 100%. OSPF IGP developed and maintained in the
> > OSPF WG  and
> > ASON OSPF have just one thing in common - they share the same transport
> ,
> > but, otherwise, have 0 in common. In particular, I believe ASON OSPF
> > should
> > not be considered as an extension to OSPF
> > and should not be objected or supported by OSPF WG.
> >
> > Igor
> >
> > ----- Original Message ----- 
> > From: "Acee Lindem" <acee@cisco.com>
> > To: "Adrian Farrel" <adrian@olddog.co.uk>
> > Cc: <ccamp@ops.ietf.org>
> > Sent: Thursday, July 20, 2006 5:40 PM
> > Subject: Re: OSPF ASON Routing Solution
> >
> >
> > > Hi Adrian, Dimitri, et al,
> > >
> > > No objection on my part. However, I wanted to make a clarification
> that
> > > may or may not be obvious to everyone. In Montreal, Dimitri
> > > and I sat down and discussed my comments on the hierarchical
> > > dissemination of ASON routing information between RAs (Routing Areas
> > > in ASON parlance).
> > >
> > > Today OSPF does not support an area hierarchy other than the
> > > backbone and non-backbone areas. This specification for ASON  should
> > > not be considered a partial specification of support in OSPF for a new
> > > area hierarchy (specific requirements are stated in the CCAMP
> > > document references). Rather, it should be conceptually viewed as
> rules
> > > for importing and exporting GMPLS TE data between separate
> > > OSPF instances  (one instance per ASON RA). This was the motivation
> > > for my comment on restating the inter-RA advertisement rules in term
> of
> > > import/export rather than flooding.
> > >
> > > Thanks,
> > > Acee
> > >
> > > Adrian Farrel wrote:
> > > > Just a refresh in case you were travelling.
> > > >
> > > > I am seeking objections to this draft becoming a WG document.
> > > >
> > > > Adrian
> > > > ----- Original Message ----- From: "Adrian Farrel"
> > <adrian@olddog.co.uk>
> > > > To: <ccamp@ops.ietf.org>
> > > > Sent: Wednesday, July 12, 2006 8:10 PM
> > > > Subject: OSPF ASON Routing Solution
> > > >
> > > >
> > > >> Hi,
> > > >> On Monday in CCAMP we discussed
> > > >> draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt the solutions
> > > >> draft for OSPF in ASON routing.
> > > >>
> > > >> There is agreement from the OSPF WG chair that we are not treading
> on
> > > >> toes, and the meeting seemed to say that this was pretty stable.
> > > >>
> > > >> So a this is a quick poll to see if anyone objects to this becoming
> a
> > > >> WG draft.
> > > >> NB, this is a charter item and we have an obligation to work on
> this
> > > >> for the ITU-T.
> > > >>
> > > >> Thanks,
> > > >> Adrian
> > > >>
> > > >> PS Note that a solution does not have to be 100% perfect to become
> a
> > > >> WG draft.
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >
> > > >
> > >
> >
> >
> >
> >
>
>
>

Envelope-to: ccamp-data@psg.com
Delivery-date: Fri, 21 Jul 2006 14:37:39 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6ACD3.33A1ED98"
Subject: Proposed response to OIF on OSPF ENNI
Date: Fri, 21 Jul 2006 09:37:32 -0500
Message-ID: <449B2580D802A443A923DABF3EAB82AF0C72B4C3@OCCLUST04EVS1.ugd.att.com>
Thread-Topic: Proposed response to OIF on OSPF ENNI
Thread-Index: Acas0Ha/aYxFikOBS5m873SVRoVJxgAACLxQ
From: "Brungard, Deborah A, ALABS" <dbrungard@att.com>
To: <ccamp@ops.ietf.org>
Cc: "Adrian Farrel" <adrian@olddog.co.uk>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6ACD3.33A1ED98
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

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

=20

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

=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

------_=_NextPart_001_01C6ACD3.33A1ED98
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns:o =3D "urn:schemas-microsoft-com:office:office" xmlns:st1 =
=3D=20
"urn:schemas-microsoft-com:office:smarttags"><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.2914" name=3DGENERATOR></HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D845551814-21072006>Hi,</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial><FONT size=3D2><FONT =
color=3D#0000ff><FONT=20
face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D845551814-21072006></SPAN></FONT></FONT></FONT></FONT>&nbsp;</DIV=
>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial><FONT =
color=3D#0000ff><FONT size=3D2><SPAN=20
class=3D845551814-21072006>We had a communication from OIF on their OSPF =
ENNI=20
specification. </SPAN>You can see the original files on =
</FONT></FONT></FONT><A=20
href=3D"http://www.olddog.co.uk/ccamp.htm"><U><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>http://www.olddog.co.uk/ccamp.htm</FONT></U></A><FONT =
face=3DArial><FONT=20
color=3D#0000ff><FONT size=3D2>.<SPAN class=3D845551814-21072006> Having =
assembled=20
comments from several people and our discussions in Montreal, we have =
put=20
together the following response.</SPAN></FONT></FONT></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial><FONT =
color=3D#0000ff><FONT size=3D2><SPAN=20
class=3D845551814-21072006></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
<DIV dir=3Dltr><SPAN class=3D845551814-21072006><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>Please comment on the list in the next =
week.</FONT></SPAN></DIV>
<DIV dir=3Dltr><SPAN class=3D845551814-21072006><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr><SPAN class=3D845551814-21072006><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>Thanks,</FONT></SPAN></DIV>
<DIV dir=3Dltr><SPAN class=3D845551814-21072006><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>Adrian and Deborah</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff=20
size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT face=3D"Times =
New Roman"=20
size=3D3><SPAN class=3D427551414-21072006>=3D =3D =3D =3D =3D =3D =3D =
=3D =3D =3D</SPAN></FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT face=3D"Times =
New Roman"=20
size=3D3>Dear Jim,</FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><o:p><FONT =
face=3D"Times New Roman"=20
size=3D3>&nbsp;</FONT></o:p></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT face=3D"Times =
New Roman"=20
size=3D3>We thank you for sending us the OIF ENNI document in response =
to our=20
request. While we appreciate the document being provided for =
information, it is=20
concerning that this document has not been previously shared with CCAMP =
or the=20
OSPF WG considering the document contains significant modifications to =
the=20
operation of OSPF and reflects OIF work over the last several years. =
CCAMP has=20
been working on GMPLS ASON for several years and our Design Teams =
include OIF=20
participants. Even though a reply was not requested, we are replying, as =
we=20
strongly recommend that the document not be published for public =
information in=20
its current form.</FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><o:p><FONT =
face=3D"Times New Roman"=20
size=3D3>&nbsp;</FONT></o:p></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT face=3D"Times =
New Roman"=20
size=3D3>Of most concern to CCAMP is that it is not aligned with RFC =
4258=20
(Requirements for Generalized Multi-Protocol Label Switching (GMPLS) =
Routing for=20
the Automatically Switched Optical Network (ASON)) or the =
to-be-published:=20
</FONT><A=20
href=3D"ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpls-ason-rou=
ting-eval-03.txt"><FONT=20
face=3D"Times New Roman"=20
size=3D3>ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpls-ason-ro=
uting-eval-03.txt</FONT></A><FONT=20
face=3D"Times New Roman" size=3D3>. Considering notable OIF participants =
are authors=20
of both these IETF documents (and the same participants are contributors =
and the=20
Editor for the OIF document), the non-alignment is perplexing. =
Considering the=20
IETF document is ready for publication, we suggest in the interests of =
time,=20
that you align your document with the IETF document. If any questions on =
the=20
interpretation of the IETF&#8217;s work, we recommend that you either =
utilize the=20
CCAMP mail exploder or send a communication.</FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><o:p><FONT =
face=3D"Times New Roman"=20
size=3D3>&nbsp;</FONT></o:p></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT face=3D"Times =
New Roman"=20
size=3D3>Specific comments include:</FONT></P>
<P class=3DMsoNormal=20
style=3D"MARGIN: 0in 0in 0pt 0.25in; TEXT-INDENT: -0.25in; mso-list: l0 =
level1 lfo1; tab-stops: list .25in"><SPAN=20
style=3D"mso-fareast-font-family: 'Times New Roman'"><SPAN=20
style=3D"mso-list: Ignore"><FONT face=3D"Times New Roman"><FONT=20
size=3D3>1.</FONT><SPAN=20
style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></FONT></SPAN></SPAN><FONT face=3D"Times New Roman" size=3D3>What =
is the=20
intent of this document? Will it be published as an Implementation =
Agreement=20
(IA)?<BR>The title indicates it will be an Implementation Agreement on =
GMPLS=20
OSPF extensions, but the main body of the document is a list of issues =
with=20
GMPLS OSPF. Further, your communication to us stated the document was=20
requirements on and use of OSPF-TE at the ENNI. These three views seem =
to be=20
inconsistent.</FONT></P>
<P class=3DMsoNormal=20
style=3D"MARGIN: 0in 0in 0pt 0.25in; TEXT-INDENT: -0.25in; mso-list: l0 =
level1 lfo1; tab-stops: list .25in"><FONT=20
face=3D"Times New Roman"><I><SPAN=20
style=3D"mso-fareast-font-family: 'Times New Roman'; =
mso-bidi-font-weight: bold"><SPAN=20
style=3D"mso-list: Ignore"><FONT size=3D3>2.</FONT><SPAN=20
style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></SPAN></SPAN></I><FONT size=3D3>The list of changes from the =
previous=20
version (listed under the Table of Contents) includes &#8220;<I><SPAN=20
style=3D"mso-bidi-font-weight: bold">removed &#8220;intra-carrier&#8221; =

limitation<SPAN=20
style=3D"mso-bidi-font-weight: bold; mso-bidi-font-style: italic"><FONT=20
size=3D3>&#8221; and the inclusion of =
Figure 1 showing the=20
OSPF ENNI for use between vendor domains and between carrier domains. =
GMPLS=20
OSPF-TE already supports inter-vendor operations. The IETF&#8217;s =
GMPLS ASON=20
routing focus has been on the use of a link-state based protocol to =
support a=20
hierarchical routing architecture (G.7715.1) within a carrier&#8217;s =
domain.=20
Requirements for using a link state protocol as an inter-domain protocol =
between=20
carriers are significantly different. We strongly disagree if you intend =
to=20
publish this document as an inter-carrier OSPF ENNI Implementation =
Agreement=20
claiming alignment with IETF RFCs without review (or agreement) by any =
of the=20
IETF Working Groups.<o:p></o:p>
<FONT=20
face=3D"Times New Roman"><SPAN=20
style=3D"mso-fareast-font-family: 'Times New Roman'"><SPAN=20
style=3D"mso-list: Ignore">3.<SPAN=20
style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
Section 4.1/Table 1 and the =
statement under=20
the table identifying issues with GMPLS identifier namespaces are not =
correct.=20
GMPLS identifier namespaces do meet ASON requirements for namespace =
separation=20
of the transport plane and control plane (Section 5.2 and =
5.3/Evaluation).=20
Perhaps you are confusing OSPF and GMPLS OSPF? As you also identified in =
your=20
liaison that the key area needing review was the support of independence =
of=20
functional component to physical location, this appears to be a key area =
of=20
misunderstanding on GMPLS. We recommend reviewing RFC3945 (GMPLS =
Architecture)=20
to understand that the key architecture difference between GMPLS and =
MPLS is the=20
decoupling of the transport plane and control plane. Additionally, =
RFC4394,=20
RFC4397, and RFC4258, provide a mapping to ITU terminology which may be =
helpful=20
reading.
<o:p>&nbsp;</o:p>
We request an additional round of communication of this =
document to the=20
IETF before approval to allow us to work with you to produce convergence =
between=20
OIF and IETF work which, we believe, will be in the best interests of =
the=20
industry.
<o:p>&nbsp;</o:p>
Best regards,
<FONT=20
face=3D"Times New Roman"><st1:PersonName w:st=3D"on">Adrian =
Farrel</st1:PersonName>=20
and Deborah Brungard,
CCAMP co-chairs</DIV></BODY></HTML>

------_=_NextPart_001_01C6ACD3.33A1ED98--

Envelope-to: ccamp-data@psg.com
Delivery-date: Fri, 21 Jul 2006 14:37:22 +0000
To: "Igor Bryskin" <ibryskin@movaz.com>
Cc: "Acee Lindem" <acee@cisco.com>, "Adrian Farrel" <adrian@olddog.co.uk>, ccamp@ops.ietf.org, owner-ccamp@ops.ietf.org
Subject: Re: OSPF ASON Routing Solution
MIME-Version: 1.0
Message-ID: <OF38CCA21C.3EB8986C-ONC12571B2.004D971C-C12571B2.00504866@netfr.alcatel.fr>
From: Dimitri.Papadimitriou@alcatel.be
Date: Fri, 21 Jul 2006 16:36:38 +0200
Content-Type: text/plain; charset="US-ASCII"

igor - 

i don't think that someone claimed that OSPF-TE is a superset of OSPF or 
whatsover the former (as other applications) just build on existing OSPF 
RFCs (and mechanisms) 

note that RFC 2370 states "The information contained in Opaque LSAs may be 
used directly by OSPF or indirectly by some application
wishing to distribute information throughout the OSPF domain." reason why 
GR, Router capabilities and TE like applications can make use of opaque 
LSAs (that you restrict to TE only btw); hence your assertion "RFC2370 
does not provide a way for extending OSPF" is not correct 

this said your digression falls imho outside the scope of the present poll 
(if you want to re-discuss GMPLS/OSPF-TE vs OSPF i suggest you start from 
the beginning not from the middle and probably direct your concern at the 
owning WG) 

ps: all this remembers me the discussion we had 3 years ago in Vienna (but 
was on BGP at that time) and we all know where and how such discussions 
end 

-d.

"Igor Bryskin" <ibryskin@movaz.com>
21/07/2006 16:04

        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     "Acee Lindem" <acee@cisco.com>, "Adrian Farrel" 
<adrian@olddog.co.uk>, <ccamp@ops.ietf.org>, <owner-ccamp@ops.ietf.org>
        Subject:        Re: OSPF ASON Routing Solution

Dimitri,

Please, see in line.

Igor

----- Original Message ----- 
From: <Dimitri.Papadimitriou@alcatel.be>
To: "Igor Bryskin" <ibryskin@movaz.com>
Cc: "Acee Lindem" <acee@cisco.com>; "Adrian Farrel" <adrian@olddog.co.uk>;
<ccamp@ops.ietf.org>; <owner-ccamp@ops.ietf.org>
Sent: Thursday, July 20, 2006 8:05 PM
Subject: Re: OSPF ASON Routing Solution

> the comment of acee will be addressed - stated already in previous 
e-mail
> b/f IETF 66 meeting -
>
> as ASON RC(PC) are OSPF engines defined in RFC 2328, routing info 
exchange
> makes use of RFC 2370 mechanism (which afaik is an intrinsic part of
> OSPF), etc., information encoding (in top-level TLVs) are defined in RFC
> 3630 and co. whereas all these are under OSPF WG resp. ... this leads me
> to the question if not extensions to OSPF - extensions of which protocol 
?

RFC2370 does not provide a way for extending OSPF, rather, it exposes OSPF
advertising, flooding and synchronization mechanisms to be used by other
(non-OSPF) applications. OSPF-TE, ASON OSPF, L1VPN OSPF. mesh membership,
node capability discovery, etc. are such applications. To answer your
question OSPF-TE is not an extension to OSPF, rather, it is a separate
protocol.

Let me prove you this point. Consider RSVP (RFC2205) and RSVP-TE. The 
latter
*is* an extension of the former, because it understands and uses all basic
elements, objects (e.g. SESSION, SENDER_TEMPLATE, etc.) and *in addition* 
it
introduces new elements/objects (e.g. SESSION_ATTRIBUTES, LABEL, etc.). 
You
can say that RSVP-TE is a superset of RSVP. likewise, GMPLS RSVP is a
superset of RSVP-TE.
Let us now consider OSPF and OSPF-TE. The latter neither understands nor
uses basic OSPF LSAs type 1,2,3,4,5. Rather it understands only opaque 
LSAs
(type 10) with semantics specifically designed for the TE application. 
These
semantics are not understood by OSPF. You surely can not claim that 
OSPF-TE
is a superset of OSPF, hence OSPF-TE is not an extension to OSPF.
Furthermore, TE routing areas do not have to match IP routing areas and 
may
have completely different area hierarchies. ASON OSPF (I forgot the name 
of
the author) is a shining proof to that.

>
> the main point is that RFC 2370 stating "The information contained in
> Opaque LSAs may be used directly by OSPF or indirectly by some 
application
> wishing to distribute information throughout the OSPF domain." puts your
> comment in the old battle field bucket since Opaque LSAs have been 
applied
> since many years to (OSPF-)TE, and GR applications ... hence, are you 
also
> objecting to these and suggest to have a specific and dedicated protocol
> mechanism per application

I can see how OSPF can use opaque LSAs for experimantation purposes and 
for
extending itself, but this is not what,say, OSPF-TE is about.

>
> ps: i forgot the name of the author of OSPF ext. for L1VPN

If you are talking about L1VPN-OSPF, this is not OSPF ext for L1VPN, 
rather,
OSPF based L1VPN auto-discovery solution

Igor

>
>
>
>
> "Igor Bryskin" <ibryskin@movaz.com>
> Sent by: owner-ccamp@ops.ietf.org
> 21/07/2006 00:05
>
>         To:     "Acee Lindem" <acee@cisco.com>, "Adrian Farrel"
> <adrian@olddog.co.uk>
>         cc:     <ccamp@ops.ietf.org>
>         Subject:        Re: OSPF ASON Routing Solution
>
>
> Hi Acee,
>
> I agree with your comment 100%. OSPF IGP developed and maintained in the
> OSPF WG  and
> ASON OSPF have just one thing in common - they share the same transport 
,
> but, otherwise, have 0 in common. In particular, I believe ASON OSPF
> should
> not be considered as an extension to OSPF
> and should not be objected or supported by OSPF WG.
>
> Igor
>
> ----- Original Message ----- 
> From: "Acee Lindem" <acee@cisco.com>
> To: "Adrian Farrel" <adrian@olddog.co.uk>
> Cc: <ccamp@ops.ietf.org>
> Sent: Thursday, July 20, 2006 5:40 PM
> Subject: Re: OSPF ASON Routing Solution
>
>
> > Hi Adrian, Dimitri, et al,
> >
> > No objection on my part. However, I wanted to make a clarification 
that
> > may or may not be obvious to everyone. In Montreal, Dimitri
> > and I sat down and discussed my comments on the hierarchical
> > dissemination of ASON routing information between RAs (Routing Areas
> > in ASON parlance).
> >
> > Today OSPF does not support an area hierarchy other than the
> > backbone and non-backbone areas. This specification for ASON  should
> > not be considered a partial specification of support in OSPF for a new
> > area hierarchy (specific requirements are stated in the CCAMP
> > document references). Rather, it should be conceptually viewed as 
rules
> > for importing and exporting GMPLS TE data between separate
> > OSPF instances  (one instance per ASON RA). This was the motivation
> > for my comment on restating the inter-RA advertisement rules in term 
of
> > import/export rather than flooding.
> >
> > Thanks,
> > Acee
> >
> > Adrian Farrel wrote:
> > > Just a refresh in case you were travelling.
> > >
> > > I am seeking objections to this draft becoming a WG document.
> > >
> > > Adrian
> > > ----- Original Message ----- From: "Adrian Farrel"
> <adrian@olddog.co.uk>
> > > To: <ccamp@ops.ietf.org>
> > > Sent: Wednesday, July 12, 2006 8:10 PM
> > > Subject: OSPF ASON Routing Solution
> > >
> > >
> > >> Hi,
> > >> On Monday in CCAMP we discussed
> > >> draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt the solutions
> > >> draft for OSPF in ASON routing.
> > >>
> > >> There is agreement from the OSPF WG chair that we are not treading 
on
> > >> toes, and the meeting seemed to say that this was pretty stable.
> > >>
> > >> So a this is a quick poll to see if anyone objects to this becoming 
a
> > >> WG draft.
> > >> NB, this is a charter item and we have an obligation to work on 
this
> > >> for the ITU-T.
> > >>
> > >> Thanks,
> > >> Adrian
> > >>
> > >> PS Note that a solution does not have to be 100% perfect to become 
a
> > >> WG draft.
> > >>
> > >>
> > >>
> > >>
> > >>
> > >
> > >
> >
>
>
>
>

Envelope-to: ccamp-data@psg.com
Delivery-date: Fri, 21 Jul 2006 14:10:20 +0000
Message-ID: <008b01c6accf$62f1f670$6501a8c0@movaz.com>
From: "Igor Bryskin" <ibryskin@movaz.com>
To: "Acee Lindem" <acee@cisco.com>
Cc: "Adrian Farrel" <adrian@olddog.co.uk>, <ccamp@ops.ietf.org>
Subject: Re: OSPF ASON Routing Solution
Date: Fri, 21 Jul 2006 10:09:39 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Acee,

I obviously interpreted your comment the way I wanted to :=) - in a broader
way that you meant. I apologize for that. Please, see my response to
Dimitri.

Igor

----- Original Message ----- 
From: "Acee Lindem" <acee@cisco.com>
To: "Igor Bryskin" <ibryskin@movaz.com>
Cc: "Adrian Farrel" <adrian@olddog.co.uk>; <ccamp@ops.ietf.org>
Sent: Thursday, July 20, 2006 9:44 PM
Subject: Re: OSPF ASON Routing Solution

> Hi Igor,
>
> Igor Bryskin wrote:
> > Hi Acee,
> >
> > I agree with your comment 100%. OSPF IGP developed and maintained in the
> > OSPF WG  and
> > ASON OSPF have just one thing in common - they share the same transport
,
> > but, otherwise, have 0 in common. In particular, I believe ASON OSPF
should
> > not be considered as an extension to OSPF
> > and should not be objected or supported by OSPF WG.
> >
> I don't believe I said that (at least that's not what I meant). The OSPF
> ASON extensions
> build on the existing OSPFv2 (RFC 2328), opaque LSA (RFC 2370), OSPF TE
> (RFC 3630),
> and GMPLS (RFC 4203) specificatoins. What  I said was that  the ASON
> extension for
> leaking routing information vertically within the RA hierarchy should
> not be construed to imply
> a new OSPF area hierarchy. Rather, an RC supporting RAs at multiple
> levels should
> view these as separate OSPF instances with leaking between levels
> described by
> import/export rules.
>
> Thanks,
> Acee
>
> > Igor
> >
> > ----- Original Message ----- 
> > From: "Acee Lindem" <acee@cisco.com>
> > To: "Adrian Farrel" <adrian@olddog.co.uk>
> > Cc: <ccamp@ops.ietf.org>
> > Sent: Thursday, July 20, 2006 5:40 PM
> > Subject: Re: OSPF ASON Routing Solution
> >
> >
> >
> >> Hi Adrian, Dimitri, et al,
> >>
> >> No objection on my part. However, I wanted to make a clarification that
> >> may or may not be obvious to everyone. In Montreal, Dimitri
> >> and I sat down and discussed my comments on the hierarchical
> >> dissemination of ASON routing information between RAs (Routing Areas
> >> in ASON parlance).
> >>
> >> Today OSPF does not support an area hierarchy other than the
> >> backbone and non-backbone areas. This specification for ASON  should
> >> not be considered a partial specification of support in OSPF for a new
> >> area hierarchy (specific requirements are stated in the CCAMP
> >> document references). Rather, it should be conceptually viewed as rules
> >> for importing and exporting GMPLS TE data between separate
> >> OSPF instances  (one instance per ASON RA). This was the motivation
> >> for my comment on restating the inter-RA advertisement rules in term of
> >> import/export rather than flooding.
> >>
> >> Thanks,
> >> Acee
> >>
> >> Adrian Farrel wrote:
> >>
> >>> Just a refresh in case you were travelling.
> >>>
> >>> I am seeking objections to this draft becoming a WG document.
> >>>
> >>> Adrian
> >>> ----- Original Message ----- From: "Adrian Farrel"
<adrian@olddog.co.uk>
> >>> To: <ccamp@ops.ietf.org>
> >>> Sent: Wednesday, July 12, 2006 8:10 PM
> >>> Subject: OSPF ASON Routing Solution
> >>>
> >>>
> >>>
> >>>> Hi,
> >>>> On Monday in CCAMP we discussed
> >>>> draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt the solutions
> >>>> draft for OSPF in ASON routing.
> >>>>
> >>>> There is agreement from the OSPF WG chair that we are not treading on
> >>>> toes, and the meeting seemed to say that this was pretty stable.
> >>>>
> >>>> So a this is a quick poll to see if anyone objects to this becoming a
> >>>> WG draft.
> >>>> NB, this is a charter item and we have an obligation to work on this
> >>>> for the ITU-T.
> >>>>
> >>>> Thanks,
> >>>> Adrian
> >>>>
> >>>> PS Note that a solution does not have to be 100% perfect to become a
> >>>> WG draft.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >
> >
>

Envelope-to: ccamp-data@psg.com
Delivery-date: Fri, 21 Jul 2006 14:06:38 +0000
Message-ID: <007c01c6acce$b8f6cba0$6501a8c0@movaz.com>
From: "Igor Bryskin" <ibryskin@movaz.com>
To: <Dimitri.Papadimitriou@alcatel.be>
Cc: "Acee Lindem" <acee@cisco.com>, "Adrian Farrel" <adrian@olddog.co.uk>, <ccamp@ops.ietf.org>, <owner-ccamp@ops.ietf.org>
Subject: Re: OSPF ASON Routing Solution
Date: Fri, 21 Jul 2006 10:04:56 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Dimitri,

Please, see in line.

Igor

----- Original Message ----- 
From: <Dimitri.Papadimitriou@alcatel.be>
To: "Igor Bryskin" <ibryskin@movaz.com>
Cc: "Acee Lindem" <acee@cisco.com>; "Adrian Farrel" <adrian@olddog.co.uk>;
<ccamp@ops.ietf.org>; <owner-ccamp@ops.ietf.org>
Sent: Thursday, July 20, 2006 8:05 PM
Subject: Re: OSPF ASON Routing Solution

> the comment of acee will be addressed - stated already in previous e-mail
> b/f IETF 66 meeting -
>
> as ASON RC(PC) are OSPF engines defined in RFC 2328, routing info exchange
> makes use of RFC 2370 mechanism (which afaik is an intrinsic part of
> OSPF), etc., information encoding (in top-level TLVs) are defined in RFC
> 3630 and co. whereas all these are under OSPF WG resp. ... this leads me
> to the question if not extensions to OSPF - extensions of which protocol ?

RFC2370 does not provide a way for extending OSPF, rather, it exposes OSPF
advertising, flooding and synchronization mechanisms to be used by other
(non-OSPF) applications. OSPF-TE, ASON OSPF, L1VPN OSPF. mesh membership,
node capability discovery, etc. are such applications. To answer your
question OSPF-TE is not an extension to OSPF, rather, it is a separate
protocol.

Let me prove you this point. Consider RSVP (RFC2205) and RSVP-TE. The latter
*is* an extension of the former, because it understands and uses all basic
elements, objects (e.g. SESSION, SENDER_TEMPLATE, etc.) and *in addition* it
introduces new elements/objects (e.g. SESSION_ATTRIBUTES, LABEL, etc.). You
can say that RSVP-TE is a superset of RSVP. likewise, GMPLS RSVP is a
superset of RSVP-TE.
Let us now consider OSPF and OSPF-TE. The latter neither understands nor
uses basic OSPF LSAs type 1,2,3,4,5. Rather it understands only opaque LSAs
(type 10) with semantics specifically designed for the TE application. These
semantics are not understood by OSPF. You surely can not claim that OSPF-TE
is a superset of OSPF, hence OSPF-TE is not an extension to OSPF.
Furthermore, TE routing areas do not have to match IP routing areas and may
have completely different area hierarchies. ASON OSPF (I forgot the name of
the author) is a shining proof to that.

>
> the main point is that RFC 2370 stating "The information contained in
> Opaque LSAs may be used directly by OSPF or indirectly by some application
> wishing to distribute information throughout the OSPF domain." puts your
> comment in the old battle field bucket since Opaque LSAs have been applied
> since many years to (OSPF-)TE, and GR applications ... hence, are you also
> objecting to these and suggest to have a specific and dedicated protocol
> mechanism per application

I can see how OSPF can use opaque LSAs for experimantation purposes and for
extending itself, but this is not what,say, OSPF-TE is about.

>
> ps: i forgot the name of the author of OSPF ext. for L1VPN

If you are talking about L1VPN-OSPF, this is not OSPF ext for L1VPN, rather,
OSPF based L1VPN auto-discovery solution

Igor

>
>
>
>
> "Igor Bryskin" <ibryskin@movaz.com>
> Sent by: owner-ccamp@ops.ietf.org
> 21/07/2006 00:05
>
>         To:     "Acee Lindem" <acee@cisco.com>, "Adrian Farrel"
> <adrian@olddog.co.uk>
>         cc:     <ccamp@ops.ietf.org>
>         Subject:        Re: OSPF ASON Routing Solution
>
>
> Hi Acee,
>
> I agree with your comment 100%. OSPF IGP developed and maintained in the
> OSPF WG  and
> ASON OSPF have just one thing in common - they share the same transport ,
> but, otherwise, have 0 in common. In particular, I believe ASON OSPF
> should
> not be considered as an extension to OSPF
> and should not be objected or supported by OSPF WG.
>
> Igor
>
> ----- Original Message ----- 
> From: "Acee Lindem" <acee@cisco.com>
> To: "Adrian Farrel" <adrian@olddog.co.uk>
> Cc: <ccamp@ops.ietf.org>
> Sent: Thursday, July 20, 2006 5:40 PM
> Subject: Re: OSPF ASON Routing Solution
>
>
> > Hi Adrian, Dimitri, et al,
> >
> > No objection on my part. However, I wanted to make a clarification that
> > may or may not be obvious to everyone. In Montreal, Dimitri
> > and I sat down and discussed my comments on the hierarchical
> > dissemination of ASON routing information between RAs (Routing Areas
> > in ASON parlance).
> >
> > Today OSPF does not support an area hierarchy other than the
> > backbone and non-backbone areas. This specification for ASON  should
> > not be considered a partial specification of support in OSPF for a new
> > area hierarchy (specific requirements are stated in the CCAMP
> > document references). Rather, it should be conceptually viewed as rules
> > for importing and exporting GMPLS TE data between separate
> > OSPF instances  (one instance per ASON RA). This was the motivation
> > for my comment on restating the inter-RA advertisement rules in term of
> > import/export rather than flooding.
> >
> > Thanks,
> > Acee
> >
> > Adrian Farrel wrote:
> > > Just a refresh in case you were travelling.
> > >
> > > I am seeking objections to this draft becoming a WG document.
> > >
> > > Adrian
> > > ----- Original Message ----- From: "Adrian Farrel"
> <adrian@olddog.co.uk>
> > > To: <ccamp@ops.ietf.org>
> > > Sent: Wednesday, July 12, 2006 8:10 PM
> > > Subject: OSPF ASON Routing Solution
> > >
> > >
> > >> Hi,
> > >> On Monday in CCAMP we discussed
> > >> draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt the solutions
> > >> draft for OSPF in ASON routing.
> > >>
> > >> There is agreement from the OSPF WG chair that we are not treading on
> > >> toes, and the meeting seemed to say that this was pretty stable.
> > >>
> > >> So a this is a quick poll to see if anyone objects to this becoming a
> > >> WG draft.
> > >> NB, this is a charter item and we have an obligation to work on this
> > >> for the ITU-T.
> > >>
> > >> Thanks,
> > >> Adrian
> > >>
> > >> PS Note that a solution does not have to be 100% perfect to become a
> > >> WG draft.
> > >>
> > >>
> > >>
> > >>
> > >>
> > >
> > >
> >
>
>
>
>

Envelope-to: ccamp-data@psg.com
Delivery-date: Fri, 21 Jul 2006 01:45:13 +0000
Message-ID: <44C0316C.4050901@cisco.com>
Date: Thu, 20 Jul 2006 21:44:12 -0400
From: Acee Lindem <acee@cisco.com>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: Igor Bryskin <ibryskin@movaz.com>
CC: Adrian Farrel <adrian@olddog.co.uk>, ccamp@ops.ietf.org
Subject: Re: OSPF ASON Routing Solution
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: a=rsa-sha1; q=dns; l=3289; t=1153446254; x=1154310254; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acee@cisco.com; z=From:Acee=20Lindem=20<acee@cisco.com> |Subject:Re=3A=20OSPF=20ASON=20Routing=20Solution |To:Igor=20Bryskin=20<ibryskin@movaz.com>; X=v=3Dcisco.com=3B=20h=3DJEaT/PJZXmelX6ToU0domypvAVA=3D; b=FtKbU4qOuQnSnjXYIri9rAzhBXkfEHV66WuZG3whWbrAvozox6u8iAAvqYPv3t63yRhPXU0T LOVFofNwsxr7hJJLNa2ATmun77SzfWt+iRREhQ69w4wjGCCVejTN82+b;
Authentication-Results: rtp-dkim-1.cisco.com; header.From=acee@cisco.com; dkim=pass ( sig from cisco.com verified; );

Hi Igor,

Igor Bryskin wrote:
> Hi Acee,
>
> I agree with your comment 100%. OSPF IGP developed and maintained in the
> OSPF WG  and
> ASON OSPF have just one thing in common - they share the same transport ,
> but, otherwise, have 0 in common. In particular, I believe ASON OSPF should
> not be considered as an extension to OSPF
> and should not be objected or supported by OSPF WG.
>   
I don't believe I said that (at least that's not what I meant). The OSPF 
ASON extensions
build on the existing OSPFv2 (RFC 2328), opaque LSA (RFC 2370), OSPF TE 
(RFC 3630),
and GMPLS (RFC 4203) specificatoins. What  I said was that  the ASON 
extension for
leaking routing information vertically within the RA hierarchy should 
not be construed to imply
a new OSPF area hierarchy. Rather, an RC supporting RAs at multiple 
levels should
view these as separate OSPF instances with leaking between levels 
described by
import/export rules.

Thanks,
Acee

> Igor
>
> ----- Original Message ----- 
> From: "Acee Lindem" <acee@cisco.com>
> To: "Adrian Farrel" <adrian@olddog.co.uk>
> Cc: <ccamp@ops.ietf.org>
> Sent: Thursday, July 20, 2006 5:40 PM
> Subject: Re: OSPF ASON Routing Solution
>
>
>   
>> Hi Adrian, Dimitri, et al,
>>
>> No objection on my part. However, I wanted to make a clarification that
>> may or may not be obvious to everyone. In Montreal, Dimitri
>> and I sat down and discussed my comments on the hierarchical
>> dissemination of ASON routing information between RAs (Routing Areas
>> in ASON parlance).
>>
>> Today OSPF does not support an area hierarchy other than the
>> backbone and non-backbone areas. This specification for ASON  should
>> not be considered a partial specification of support in OSPF for a new
>> area hierarchy (specific requirements are stated in the CCAMP
>> document references). Rather, it should be conceptually viewed as rules
>> for importing and exporting GMPLS TE data between separate
>> OSPF instances  (one instance per ASON RA). This was the motivation
>> for my comment on restating the inter-RA advertisement rules in term of
>> import/export rather than flooding.
>>
>> Thanks,
>> Acee
>>
>> Adrian Farrel wrote:
>>     
>>> Just a refresh in case you were travelling.
>>>
>>> I am seeking objections to this draft becoming a WG document.
>>>
>>> Adrian
>>> ----- Original Message ----- From: "Adrian Farrel" <adrian@olddog.co.uk>
>>> To: <ccamp@ops.ietf.org>
>>> Sent: Wednesday, July 12, 2006 8:10 PM
>>> Subject: OSPF ASON Routing Solution
>>>
>>>
>>>       
>>>> Hi,
>>>> On Monday in CCAMP we discussed
>>>> draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt the solutions
>>>> draft for OSPF in ASON routing.
>>>>
>>>> There is agreement from the OSPF WG chair that we are not treading on
>>>> toes, and the meeting seemed to say that this was pretty stable.
>>>>
>>>> So a this is a quick poll to see if anyone objects to this becoming a
>>>> WG draft.
>>>> NB, this is a charter item and we have an obligation to work on this
>>>> for the ITU-T.
>>>>
>>>> Thanks,
>>>> Adrian
>>>>
>>>> PS Note that a solution does not have to be 100% perfect to become a
>>>> WG draft.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>         
>>>       
>
>   

Envelope-to: ccamp-data@psg.com
Delivery-date: Fri, 21 Jul 2006 00:07:06 +0000
To: "Igor Bryskin" <ibryskin@movaz.com>
Cc: "Acee Lindem" <acee@cisco.com>, "Adrian Farrel" <adrian@olddog.co.uk>, ccamp@ops.ietf.org, owner-ccamp@ops.ietf.org
Subject: Re: OSPF ASON Routing Solution
MIME-Version: 1.0
Message-ID: <OF2ED0BF43.4B84184A-ONC12571B1.007CF377-C12571B2.00008D41@netfr.alcatel.fr>
From: Dimitri.Papadimitriou@alcatel.be
Date: Fri, 21 Jul 2006 02:05:45 +0200
Content-Type: text/plain; charset="US-ASCII"

the comment of acee will be addressed - stated already in previous e-mail 
b/f IETF 66 meeting -

as ASON RC(PC) are OSPF engines defined in RFC 2328, routing info exchange 
makes use of RFC 2370 mechanism (which afaik is an intrinsic part of 
OSPF), etc., information encoding (in top-level TLVs) are defined in RFC 
3630 and co. whereas all these are under OSPF WG resp. ... this leads me 
to the question if not extensions to OSPF - extensions of which protocol ?

the main point is that RFC 2370 stating "The information contained in 
Opaque LSAs may be used directly by OSPF or indirectly by some application 
wishing to distribute information throughout the OSPF domain." puts your 
comment in the old battle field bucket since Opaque LSAs have been applied 
since many years to (OSPF-)TE, and GR applications ... hence, are you also 
objecting to these and suggest to have a specific and dedicated protocol 
mechanism per application 

ps: i forgot the name of the author of OSPF ext. for L1VPN

"Igor Bryskin" <ibryskin@movaz.com>
Sent by: owner-ccamp@ops.ietf.org
21/07/2006 00:05

        To:     "Acee Lindem" <acee@cisco.com>, "Adrian Farrel" 
<adrian@olddog.co.uk>
        cc:     <ccamp@ops.ietf.org>
        Subject:        Re: OSPF ASON Routing Solution

Hi Acee,

I agree with your comment 100%. OSPF IGP developed and maintained in the
OSPF WG  and
ASON OSPF have just one thing in common - they share the same transport ,
but, otherwise, have 0 in common. In particular, I believe ASON OSPF 
should
not be considered as an extension to OSPF
and should not be objected or supported by OSPF WG.

Igor

----- Original Message ----- 
From: "Acee Lindem" <acee@cisco.com>
To: "Adrian Farrel" <adrian@olddog.co.uk>
Cc: <ccamp@ops.ietf.org>
Sent: Thursday, July 20, 2006 5:40 PM
Subject: Re: OSPF ASON Routing Solution

> Hi Adrian, Dimitri, et al,
>
> No objection on my part. However, I wanted to make a clarification that
> may or may not be obvious to everyone. In Montreal, Dimitri
> and I sat down and discussed my comments on the hierarchical
> dissemination of ASON routing information between RAs (Routing Areas
> in ASON parlance).
>
> Today OSPF does not support an area hierarchy other than the
> backbone and non-backbone areas. This specification for ASON  should
> not be considered a partial specification of support in OSPF for a new
> area hierarchy (specific requirements are stated in the CCAMP
> document references). Rather, it should be conceptually viewed as rules
> for importing and exporting GMPLS TE data between separate
> OSPF instances  (one instance per ASON RA). This was the motivation
> for my comment on restating the inter-RA advertisement rules in term of
> import/export rather than flooding.
>
> Thanks,
> Acee
>
> Adrian Farrel wrote:
> > Just a refresh in case you were travelling.
> >
> > I am seeking objections to this draft becoming a WG document.
> >
> > Adrian
> > ----- Original Message ----- From: "Adrian Farrel" 
<adrian@olddog.co.uk>
> > To: <ccamp@ops.ietf.org>
> > Sent: Wednesday, July 12, 2006 8:10 PM
> > Subject: OSPF ASON Routing Solution
> >
> >
> >> Hi,
> >> On Monday in CCAMP we discussed
> >> draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt the solutions
> >> draft for OSPF in ASON routing.
> >>
> >> There is agreement from the OSPF WG chair that we are not treading on
> >> toes, and the meeting seemed to say that this was pretty stable.
> >>
> >> So a this is a quick poll to see if anyone objects to this becoming a
> >> WG draft.
> >> NB, this is a charter item and we have an obligation to work on this
> >> for the ITU-T.
> >>
> >> Thanks,
> >> Adrian
> >>
> >> PS Note that a solution does not have to be 100% perfect to become a
> >> WG draft.
> >>
> >>
> >>
> >>
> >>
> >
> >
>

Envelope-to: ccamp-data@psg.com
Delivery-date: Thu, 20 Jul 2006 23:01:10 +0000
Message-ID: <044401c6ac2e$3c366a30$0a23fea9@your029b8cecfe>
Reply-To: "Adrian Farrel" <adrian@olddog.co.uk>
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: "Mack-Crane, T. Benjamin" <Ben.Mack-Crane@tellabs.com>
Cc: <ccamp@ops.ietf.org>, "Brungard, Deborah A, ALABS" <dbrungard@att.com>
Subject: Re: Working Group Last Call on draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt
Date: Thu, 20 Jul 2006 19:55:29 +0100
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Hi Ben,

>>>>> 3)  The network models being used in section 4.3 and section 7 are
>>>>> not clear.  In particular the relationships between the call
>>>>> controllers, network boundaries, ingress/egress nodes, and
>>>>> ingress/egress links are not clear.  Figures would be very helpful
>>>>> here.
>>>>
>>>> Figures are always helpful, and usually (but not always) better
>>>> than words.
>>>>
>>>> In order to be sure to clarify the network models that you are
>>>> finding confusing, it would be helpful if you asked specific
>>>> questions or proposed text.
>>>
>>> It is not clear how the form of initiation of a call affects the
>>> information available about the egress link. In part this may be
>>> affected by whether the ingress node is inside or outside the
>>> network (IGP) boundary.  It would seem that the situation at
>>> the egress would have something to do with this as well.  It
>>> is unclear where the egress trail termination point is expected
>>> to be, e.g. inside or outside the network boundary, and, if
>>> inside, at the near or far side of the egress node's matrix.
>>
>> You have latched on to an important point. The information
>> about the egress link might not be generally available within
>> the TED particularly when the egress node is outside the TE
>> domain (although we should observe some of the recent
>> discussions about OSPF and BGP extensions for advertising
>> PE-CE link TE capabilities).
>>
>> And, in fact, this is an important purpose of the Call, and why the
>> Link Capability object exists. The Link Capability object may be
>>used when the tail-end is within or outside the the TE domain, and
>>so we support the egress (and correspondingly the ingress) being
>> inside or outside the TE domain. This follows quite naturally from
>> RFC 4208.
>>
>> We could add a statement that the ingress and egress may be inside or
>> outside the TE domain if this will make you more comfortable.
>
> It is, I think, obvious that the ingress and egress may be inside
> or outside a TE domain.  What is not so obvious is the need
> for the Link Capability object, i.e. exactly what problem it is
> solving.  On reading the draft, this was not at all clear to me.
> Unfortunately I had sufficient difficulty understanding the
> problem statement that I did not immediately question the
> need for the object (hoping that clarification of the problem
> would shed light on this).  However, if the policy in
> CCAMP is that revising the text is not necessary as
> long as the intended meaning is clear to the authors... then
> perhaps there is nothing to be added (or subtracted;-) at
> this point.

Thank you for your courteous and professional comments.

You appear to be making two comments in this paragraph.
1. The problem statement for the I-D is not sufficiently clear.
2. The requirements for (and use of) the Link Capabilities
   object are not clear.

As I said before, it remains a very hard conversation if you simply say "I 
don't understand". I can try to rephrase the text for you, but this does not 
necessarily get us any closer. Asking specific questions is a much more 
efficient way of establishing what is missing from the draft and allowing us 
to rephrase it as necessary. Alternatively we may discover that someone's 
understanding (yours or ours) is misplaced, and we can act accordingly.

With respect to the problem statement for the I-D. We can break it down into 
pieces.

- Definition of a call.
   I hope the definition provided in Section 1 is clear.
   It borrows heavily from the phraseology used within the ITU-T,
   and cites ASON as an example.
   Section 4 goes into even more detail and is (hopefully) complete.
- Requirements to support calls.
   This is a little harder to pin down. What we assumed was
   that if the definition of a call could stand on its own, then
   it could be taken for granted that there was a need to support
   calls. Perhaps this is a mistake, do you think we need to add
   further description of why calls should be supported in
   GMPLS?
- What the document does.
   This is, I think, quite clear. The first sentence of the Introduction
   says it all...
   This document defines protocol procedures and extensions to
   support Calls within Generalized MPLS (GMPLS).

We should also try to examine the detailed requirements listed in section 3. 
The requirements here are stated as bald facts without supporting evidence. 
In my opinion, this is usual in this type of document, but I wonder if this 
is the cause of some of your concern. Are there some requirements listed 
here that leave you wondering why they are requirements?

With regard to the purpose and use of the Link Capabilities object, this is 
driven mainly by the material in section 4.3. The requirement is, as the 
text says, to allow the ingress of a connection to know information about 
the final link that the connection will traverse, so that it can tune the 
connection request to have a better chance of success and to make best use 
of the network and link resources.

As you'll see from reading the section, the Call may be a mechanism for 
exchanging information about the final link, but it is not the only 
mechanism, and in some scenarios the Call does not need to carry the 
information because it is already available. Thus, the Link Capability 
object, introduced in section 4.3, is available for use during Call setup, 
but is not mandatory.

Now, I realise that all I have done here is restate and rephrase the text in 
the I-D in an attempt to help clarify things to you. Perhaps we can now take 
this process forward by understanding more clearly what it is you want 
clarified so that we can work on the text. But I repeat that simply saying 
that you have difficulty understanding the problem statement won't get us 
anywhere. What don't you understand? What are your questions?

Thanks,
Adrian

Envelope-to: ccamp-data@psg.com
Delivery-date: Thu, 20 Jul 2006 22:07:00 +0000
Message-ID: <01b701c6ac48$aa3dd6c0$7d1810ac@movaz.com>
From: "Igor Bryskin" <ibryskin@movaz.com>
To: "Acee Lindem" <acee@cisco.com>, "Adrian Farrel" <adrian@olddog.co.uk>
Cc: <ccamp@ops.ietf.org>
Subject: Re: OSPF ASON Routing Solution
Date: Thu, 20 Jul 2006 18:05:51 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi Acee,

I agree with your comment 100%. OSPF IGP developed and maintained in the
OSPF WG  and
ASON OSPF have just one thing in common - they share the same transport ,
but, otherwise, have 0 in common. In particular, I believe ASON OSPF should
not be considered as an extension to OSPF
and should not be objected or supported by OSPF WG.

Igor

----- Original Message ----- 
From: "Acee Lindem" <acee@cisco.com>
To: "Adrian Farrel" <adrian@olddog.co.uk>
Cc: <ccamp@ops.ietf.org>
Sent: Thursday, July 20, 2006 5:40 PM
Subject: Re: OSPF ASON Routing Solution

> Hi Adrian, Dimitri, et al,
>
> No objection on my part. However, I wanted to make a clarification that
> may or may not be obvious to everyone. In Montreal, Dimitri
> and I sat down and discussed my comments on the hierarchical
> dissemination of ASON routing information between RAs (Routing Areas
> in ASON parlance).
>
> Today OSPF does not support an area hierarchy other than the
> backbone and non-backbone areas. This specification for ASON  should
> not be considered a partial specification of support in OSPF for a new
> area hierarchy (specific requirements are stated in the CCAMP
> document references). Rather, it should be conceptually viewed as rules
> for importing and exporting GMPLS TE data between separate
> OSPF instances  (one instance per ASON RA). This was the motivation
> for my comment on restating the inter-RA advertisement rules in term of
> import/export rather than flooding.
>
> Thanks,
> Acee
>
> Adrian Farrel wrote:
> > Just a refresh in case you were travelling.
> >
> > I am seeking objections to this draft becoming a WG document.
> >
> > Adrian
> > ----- Original Message ----- From: "Adrian Farrel" <adrian@olddog.co.uk>
> > To: <ccamp@ops.ietf.org>
> > Sent: Wednesday, July 12, 2006 8:10 PM
> > Subject: OSPF ASON Routing Solution
> >
> >
> >> Hi,
> >> On Monday in CCAMP we discussed
> >> draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt the solutions
> >> draft for OSPF in ASON routing.
> >>
> >> There is agreement from the OSPF WG chair that we are not treading on
> >> toes, and the meeting seemed to say that this was pretty stable.
> >>
> >> So a this is a quick poll to see if anyone objects to this becoming a
> >> WG draft.
> >> NB, this is a charter item and we have an obligation to work on this
> >> for the ITU-T.
> >>
> >> Thanks,
> >> Adrian
> >>
> >> PS Note that a solution does not have to be 100% perfect to become a
> >> WG draft.
> >>
> >>
> >>
> >>
> >>
> >
> >
>

Envelope-to: ccamp-data@psg.com
Delivery-date: Thu, 20 Jul 2006 21:41:23 +0000
Message-ID: <44BFF848.3010502@cisco.com>
Date: Thu, 20 Jul 2006 17:40:24 -0400
From: Acee Lindem <acee@cisco.com>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: Adrian Farrel <adrian@olddog.co.uk>
CC: ccamp@ops.ietf.org
Subject: Re: OSPF ASON Routing Solution
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: a=rsa-sha1; q=dns; l=1888; t=1153431625; x=1154295625; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acee@cisco.com; z=From:Acee=20Lindem=20<acee@cisco.com> |Subject:Re=3A=20OSPF=20ASON=20Routing=20Solution |To:Adrian=20Farrel=20<adrian@olddog.co.uk>; X=v=3Dcisco.com=3B=20h=3DJEaT/PJZXmelX6ToU0domypvAVA=3D; b=pyZniifxsidgqWYrTkmjme/jh0C4QbPKt2WD16V/v5OusJMBuapUG+QTqMAqxd7bIIqPzGGa y6oQGHbCDeN3zuVWLmbFvXMcPjXYWjBkLee5i5jN6WQ5HuhZqxRQ0Xao;
Authentication-Results: rtp-dkim-2.cisco.com; header.From=acee@cisco.com; dkim=pass ( sig from cisco.com verified; );

Hi Adrian, Dimitri, et al,

No objection on my part. However, I wanted to make a clarification that
may or may not be obvious to everyone. In Montreal, Dimitri
and I sat down and discussed my comments on the hierarchical
dissemination of ASON routing information between RAs (Routing Areas
in ASON parlance).

Today OSPF does not support an area hierarchy other than the
backbone and non-backbone areas. This specification for ASON  should
not be considered a partial specification of support in OSPF for a new
area hierarchy (specific requirements are stated in the CCAMP
document references). Rather, it should be conceptually viewed as rules
for importing and exporting GMPLS TE data between separate
OSPF instances  (one instance per ASON RA). This was the motivation
for my comment on restating the inter-RA advertisement rules in term of
import/export rather than flooding.

Thanks,
Acee 

Adrian Farrel wrote:
> Just a refresh in case you were travelling.
>
> I am seeking objections to this draft becoming a WG document.
>
> Adrian
> ----- Original Message ----- From: "Adrian Farrel" <adrian@olddog.co.uk>
> To: <ccamp@ops.ietf.org>
> Sent: Wednesday, July 12, 2006 8:10 PM
> Subject: OSPF ASON Routing Solution
>
>
>> Hi,
>> On Monday in CCAMP we discussed 
>> draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt the solutions 
>> draft for OSPF in ASON routing.
>>
>> There is agreement from the OSPF WG chair that we are not treading on 
>> toes, and the meeting seemed to say that this was pretty stable.
>>
>> So a this is a quick poll to see if anyone objects to this becoming a 
>> WG draft.
>> NB, this is a charter item and we have an obligation to work on this 
>> for the ITU-T.
>>
>> Thanks,
>> Adrian
>>
>> PS Note that a solution does not have to be 100% perfect to become a 
>> WG draft.
>>
>>
>>
>>
>>
>
>

Envelope-to: ccamp-data@psg.com
Delivery-date: Thu, 20 Jul 2006 18:58:39 +0000
Message-ID: <044401c6ac2e$3c366a30$0a23fea9@your029b8cecfe>
Reply-To: "Adrian Farrel" <adrian@olddog.co.uk>
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: "Mack-Crane, T. Benjamin" <Ben.Mack-Crane@tellabs.com>
Cc: <ccamp@ops.ietf.org>, "Brungard, Deborah A, ALABS" <dbrungard@att.com>
Subject: Re: Working Group Last Call on draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt
Date: Thu, 20 Jul 2006 19:55:29 +0100
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Hi Ben,

>>>>> 3)  The network models being used in section 4.3 and section 7 are
>>>>> not clear.  In particular the relationships between the call
>>>>> controllers, network boundaries, ingress/egress nodes, and
>>>>> ingress/egress links are not clear.  Figures would be very helpful
>>>>> here.
>>>>
>>>> Figures are always helpful, and usually (but not always) better
>>>> than words.
>>>>
>>>> In order to be sure to clarify the network models that you are
>>>> finding confusing, it would be helpful if you asked specific
>>>> questions or proposed text.
>>>
>>> It is not clear how the form of initiation of a call affects the
>>> information available about the egress link. In part this may be
>>> affected by whether the ingress node is inside or outside the
>>> network (IGP) boundary.  It would seem that the situation at
>>> the egress would have something to do with this as well.  It
>>> is unclear where the egress trail termination point is expected
>>> to be, e.g. inside or outside the network boundary, and, if
>>> inside, at the near or far side of the egress node's matrix.
>>
>> You have latched on to an important point. The information
>> about the egress link might not be generally available within
>> the TED particularly when the egress node is outside the TE
>> domain (although we should observe some of the recent
>> discussions about OSPF and BGP extensions for advertising
>> PE-CE link TE capabilities).
>>
>> And, in fact, this is an important purpose of the Call, and why the
>> Link Capability object exists. The Link Capability object may be
>>used when the tail-end is within or outside the the TE domain, and
>>so we support the egress (and correspondingly the ingress) being
>> inside or outside the TE domain. This follows quite naturally from
>> RFC 4208.
>>
>> We could add a statement that the ingress and egress may be inside or
>> outside the TE domain if this will make you more comfortable.
>
> It is, I think, obvious that the ingress and egress may be inside
> or outside a TE domain.  What is not so obvious is the need
> for the Link Capability object, i.e. exactly what problem it is
> solving.  On reading the draft, this was not at all clear to me.
> Unfortunately I had sufficient difficulty understanding the
> problem statement that I did not immediately question the
> need for the object (hoping that clarification of the problem
> would shed light on this).  However, if the policy in
> CCAMP is that revising the text is not necessary as
> long as the intended meaning is clear to the authors... then
> perhaps there is nothing to be added (or subtracted;-) at
> this point.

Thank you for your courteous and professional comments.

You appear to be making two comments in this paragraph.
1. The problem statement for the I-D is not sufficiently clear.
2. The requirements for (and use of) the Link Capabilities
   object are not clear.

As I said before, it remains a very hard conversation if you simply say "I 
don't understand". I can try to rephrase the text for you, but this does not 
necessarily get us any closer. Asking specific questions is a much more 
efficient way of establishing what is missing from the draft and allowing us 
to rephrase it as necessary. Alternatively we may discover that someone's 
understanding (yours or ours) is misplaced, and we can act accordingly.

With respect to the problem statement for the I-D. We can break it down into 
pieces.

- Definition of a call.
   I hope the definition provided in Section 1 is clear.
   It borrows heavily from the phraseology used within the ITU-T,
   and cites ASON as an example.
   Section 4 goes into even more detail and is (hopefully) complete.
- Requirements to support calls.
   This is a little harder to pin down. What we assumed was
   that if the definition of a call could stand on its own, then
   it could be taken for granted that there was a need to support
   calls. Perhaps this is a mistake, do you think we need to add
   further description of why calls should be supported in
   GMPLS?
- What the document does.
   This is, I think, quite clear. The first sentence of the Introduction
   says it all...
   This document defines protocol procedures and extensions to
   support Calls within Generalized MPLS (GMPLS).

We should also try to examine the detailed requirements listed in section 3. 
The requirements here are stated as bald facts without supporting evidence. 
In my opinion, this is usual in this type of document, but I wonder if this 
is the cause of some of your concern. Are there some requirements listed 
here that leave you wondering why they are requirements?

With regard to the purpose and use of the Link Capabilities object, this is 
driven mainly by the material in section 4.3. The requirement is, as the 
text says, to allow the ingress of a connection to know information about 
the final link that the connection will traverse, so that it can tune the 
connection request to have a better chance of success and to make best use 
of the network and link resources.

As you'll see from reading the section, the Call may be a mechanism for 
exchanging information about the final link, but it is not the only 
mechanism, and in some scenarios the Call does not need to carry the 
information because it is already available. Thus, the Link Capability 
object, introduced in section 4.3, is available for use during Call setup, 
but is not mandatory.

Now, I realise that all I have done here is restate and rephrase the text in 
the I-D in an attempt to help clarify things to you. Perhaps we can now take 
this process forward by understanding more clearly what it is you want 
clarified so that we can work on the text. But I repeat that simply saying 
that you have difficulty understanding the problem statement won't get us 
anywhere. What don't you understand? What are your questions?

Thanks,
Adrian

Envelope-to: ccamp-data@psg.com
Delivery-date: Thu, 20 Jul 2006 15:28:07 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: FW: [mpls] Use of reserved bits in Session object
Date: Thu, 20 Jul 2006 11:26:15 -0400
Message-ID: <0901D1988E815341A0103206A834DA07F1A021@mdmxm02.ciena.com>
Thread-Topic: [mpls] Use of reserved bits in Session object
Thread-Index: Acal+c/Ftwt3w2nnQ7m1l+hsE7EZawGEw9rAAADrPnA=
From: "Ong, Lyndon" <Lyong@Ciena.com>
To: <ccamp@ops.ietf.org>

Hi Folks,

Just wanted to raise this issue in case some people might not be
also on the MPLS list.  This is a check to see if the use of the
Session Object subfield for short call id causes anyone problems.

Cheers,

Lyndon

-----Original Message-----
From: Ong, Lyndon [mailto:Lyong@Ciena.com]=20
Sent: Thursday, July 20, 2006 8:03 AM
To: Adrian Farrel; mpls@lists.ietf.org
Subject: RE: [mpls] Use of reserved bits in Session object

Hi Folks,

Just to further bring this to people's attention - RFC 3209 says that
the bits in this subfield of the Session object "MUST be zero", rather
than simply saying that the subfield is "Reserved".

Not being familiar with how this text originated, I'd like to understand
if this was done for a specific reason (e.g., to maintain some kind of
compatibility with RFC 2205) or whether it was stated that way ("MUST be
zero" vs. "Reserved") with nothing further implied.

Thanks,

Lyndon

-----Original Message-----
From: Adrian Farrel [mailto:adrian@olddog.co.uk]
Sent: Wednesday, July 12, 2006 12:57 PM
To: mpls@lists.ietf.org
Subject: [mpls] Use of reserved bits in Session object

Hi,

Just a heads up that draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt makes
use of the reserved bits in the Session object in order to convey a Call
ID.

We believe that this does not cause a backward compatiblity problem
since the bits were formerly reserved.

Note that RFC3209 says that these bits MUST be set to zero on
transmission.

Any questions or opinions would be welcomed.

Adrian and Dimitri=20

_______________________________________________
mpls mailing list
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls

_______________________________________________
mpls mailing list
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls

Envelope-to: ccamp-data@psg.com
Delivery-date: Thu, 20 Jul 2006 13:09:44 +0000
To: Jeroen van der Ham <vdham@science.uva.nl>
Cc: ccamp@ops.ietf.org, dpapadimitriou@psg.com
Subject: Re: Questions regarding draft-ietf-ccamp-gmpls-mln-reqs-01
MIME-Version: 1.0
Message-ID: <OFD12F7FBD.F0E03539-ONC12571B1.0047F79D-C12571B1.00482F17@netfr.alcatel.fr>
From: Dimitri.Papadimitriou@alcatel.be
Date: Thu, 20 Jul 2006 15:08:21 +0200
Content-Type: text/plain; charset="US-ASCII"

hi jeroen

Jeroen van der Ham wrote:
> Hello Dimitri,
> 
> Thank you for your answers, it made some things much clearer.
> I do have some additional comments though, find them inline.
> 
> Dimitri.Papadimitriou@alcatel.be wrote:
> 
>> - I believe that the draft often uses the term ISCD often where ISC is
>> meant. If I understand it correctly, different ISCDs can be announced
>> for a given interface at different times, for example because the
>> available bandwidth is changing.
>>
>>
>> [dp] ISC refers to the switching capability, while with the inclusion 
>> of Max LSP Bw the ISCD describes capacity associated to one or more 
>> network layers
> 
> Yes, I understand that. But given your statement about ISCDs below, I do 

> not see how you can use the term ISCD at the end of section 1 where you 
> categorise MLNs based on the ISCDs.

by applying the above classification

> In particular, I don't see how an LSR may support just one ISCD. Since 
> the available bandwidth will vary over time, it can not just support one 

> single ISCD.

read ISCD per i/f and LSR can describe its interface with a single ISCD 
(such TLV does describe the Min/Max LSP bandwidth that even if varying 
over time only one sub-TLV ISCD can describe that interface) 

>> - I find the example in section 4.2.1 to be very briefly explained, it
>> could do with a better explanation of what is going on.
>>
>> One improvement would be to state explicitly which three(!) ways are
>> possible for setting up an PSC LSP across this device:
>> 1) Terminating on interface #b
>> 2) Terminating on interface #a
>> 3) Going through the device towards a neighboring PSC node.
>>
>>
>> [dp] it is two from the node perspective itself (TDM->PSC) or PSC 
>> directly
> 
> 
> Okay, but the example really should state the two ways. Just saying that 

> there are two ways may work in a textbook, but here you are describing 
> something completely new.

ok 

> Anyway, I'm looking forward to the next version.
> 
> Jeroen.
> 
> 
> .
> 

Envelope-to: ccamp-data@psg.com
Delivery-date: Thu, 20 Jul 2006 08:42:26 +0000
Message-ID: <44BF41CE.4080803@alcatel.de>
Date: Thu, 20 Jul 2006 10:41:50 +0200
From: Gert Grammel <Gert.Grammel@alcatel.de>
Organization: Alcatel OND
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910
MIME-Version: 1.0
CC: ccamp@ops.ietf.org
Subject: Re: OSPF ASON Routing Solution
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Adrian,

I am supporting this draft becoming a WG document.

Gert

Adrian Farrel wrote:

> Just a refresh in case you were travelling.
>
> I am seeking objections to this draft becoming a WG document.
>
> Adrian
> ----- Original Message ----- From: "Adrian Farrel" <adrian@olddog.co.uk>
> To: <ccamp@ops.ietf.org>
> Sent: Wednesday, July 12, 2006 8:10 PM
> Subject: OSPF ASON Routing Solution
>
>
>> Hi,
>> On Monday in CCAMP we discussed 
>> draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt the solutions 
>> draft for OSPF in ASON routing.
>>
>> There is agreement from the OSPF WG chair that we are not treading on 
>> toes, and the meeting seemed to say that this was pretty stable.
>>
>> So a this is a quick poll to see if anyone objects to this becoming a 
>> WG draft.
>> NB, this is a charter item and we have an obligation to work on this 
>> for the ITU-T.
>>
>> Thanks,
>> Adrian
>>
>> PS Note that a solution does not have to be 100% perfect to become a 
>> WG draft.
>>
>>
>>
>>
>>
>
>
>

Envelope-to: ccamp-data@psg.com
Delivery-date: Thu, 20 Jul 2006 06:56:51 +0000
Message-ID: <44BF28DE.5050200@science.uva.nl>
Date: Thu, 20 Jul 2006 08:55:26 +0200
From: Jeroen van der Ham <vdham@science.uva.nl>
User-Agent: Thunderbird 1.5.0.4 (Macintosh/20060530)
MIME-Version: 1.0
To:  Dimitri.Papadimitriou@alcatel.be
CC:  ccamp@ops.ietf.org,  dpapadimitriou@psg.com
Subject: Re: Questions regarding draft-ietf-ccamp-gmpls-mln-reqs-01
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hello Dimitri,

Thank you for your answers, it made some things much clearer.
I do have some additional comments though, find them inline.

Dimitri.Papadimitriou@alcatel.be wrote:
> - I believe that the draft often uses the term ISCD often where ISC is
> meant. If I understand it correctly, different ISCDs can be announced
> for a given interface at different times, for example because the
> available bandwidth is changing.
> 
> 
> [dp] ISC refers to the switching capability, while with the inclusion of 
> Max LSP Bw the ISCD describes capacity associated to one or more network 
> layers

Yes, I understand that. But given your statement about ISCDs below, I do 
not see how you can use the term ISCD at the end of section 1 where you 
categorise MLNs based on the ISCDs.
In particular, I don't see how an LSR may support just one ISCD. Since 
the available bandwidth will vary over time, it can not just support one 
single ISCD.

> - I find the example in section 4.2.1 to be very briefly explained, it
> could do with a better explanation of what is going on.
> 
> One improvement would be to state explicitly which three(!) ways are
> possible for setting up an PSC LSP across this device:
> 1) Terminating on interface #b
> 2) Terminating on interface #a
> 3) Going through the device towards a neighboring PSC node.
> 
> 
> [dp] it is two from the node perspective itself (TDM->PSC) or PSC directly

Okay, but the example really should state the two ways. Just saying that 
there are two ways may work in a textbook, but here you are describing 
something completely new.

Anyway, I'm looking forward to the next version.

Jeroen.

Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 19 Jul 2006 22:51:09 +0000
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
Cc: ccamp@ops.ietf.org
From: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-ccamp-inter-domain-framework-05.txt 
Message-Id: <E1G3Krh-0000hC-Rf@stiedprstage1.ietf.org>
Date: Wed, 19 Jul 2006 18:50:01 -0400

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

	Title		: A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering
	Author(s)	: A. Farrel, et al.
	Filename	: draft-ietf-ccamp-inter-domain-framework-05.txt
	Pages		: 21
	Date		: 2006-7-19

This document provides a framework for establishing and controlling
   Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS)
   Traffic Engineered (TE) Label Switched Paths (LSPs) in multi-domain
   networks.

   For the purposes of this document, a domain is considered to be any
   collection of network elements within a common sphere of address
   management or path computational responsibility. Examples of such
   domains include Interior Gateway Protocol (IGP) areas and Autonomous
   Systems (ASs).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-framework-05.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ccamp-inter-domain-framework-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-inter-domain-framework-05.txt".

NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2006-7-19150840.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-inter-domain-framework-05.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-inter-domain-framework-05.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2006-7-19150840.I-D@ietf.org>

--OtherAccess--

--NextPart--

Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 19 Jul 2006 20:00:27 +0000
From: "Rajiv Papneja" <rpapneja@isocore.com>
To: "'Adrian Farrel'" <adrian@olddog.co.uk>
Cc: <ccamp@ops.ietf.org>
Subject: RE: OSPF ASON Routing Solution
Date: Wed, 19 Jul 2006 15:59:47 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: Acal57RxxVrrlcz1SiynNykiFJth6QFheEvg
Message-Id: <E1G3ID3-0007l0-5b@psg.com>

Adrian,

I support this draft becoming a WG document.

/R

> -----Original Message-----
> From: Adrian Farrel [mailto:adrian@olddog.co.uk]
> Sent: Wednesday, July 12, 2006 3:10 PM
> To: ccamp@ops.ietf.org
> Subject: OSPF ASON Routing Solution
> 
> Hi,
> On Monday in CCAMP we discussed
> draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt the solutions draft for
> OSPF in ASON routing.
> 
> There is agreement from the OSPF WG chair that we are not treading on
toes,
> and the meeting seemed to say that this was pretty stable.
> 
> So a this is a quick poll to see if anyone objects to this becoming a WG
> draft.
> NB, this is a charter item and we have an obligation to work on this for
> the
> ITU-T.
> 
> Thanks,
> Adrian
> 
> PS Note that a solution does not have to be 100% perfect to become a WG
> draft.
> 
> 
> 
> 

Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 19 Jul 2006 19:18:39 +0000
Message-ID: <015501c6ab67$fe7501a0$7d1810ac@movaz.com>
From: "Igor Bryskin" <ibryskin@movaz.com>
To: "Adrian Farrel" <adrian@olddog.co.uk>
Cc: <ccamp@ops.ietf.org>
Subject: Re: OSPF ASON Routing Solution
Date: Wed, 19 Jul 2006 15:17:36 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

I am interested in this work and support becoming it a WG document.

Igor

> Adrian Farrel wrote:
> > Just a refresh in case you were travelling.
> >
> > I am seeking objections to this draft becoming a WG document.
> >
> > Adrian
> > ----- Original Message ----- From: "Adrian Farrel" <adrian@olddog.co.uk>
> > To: <ccamp@ops.ietf.org>
> > Sent: Wednesday, July 12, 2006 8:10 PM
> > Subject: OSPF ASON Routing Solution
> >
> >
> >> Hi,
> >> On Monday in CCAMP we discussed
> >> draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt the solutions
> >> draft for OSPF in ASON routing.
> >>
> >> There is agreement from the OSPF WG chair that we are not treading on
> >> toes, and the meeting seemed to say that this was pretty stable.
> >>
> >> So a this is a quick poll to see if anyone objects to this becoming a
> >> WG draft.
> >> NB, this is a charter item and we have an obligation to work on this
> >> for the ITU-T.
> >>
> >> Thanks,
> >> Adrian
> >>
> >> PS Note that a solution does not have to be 100% perfect to become a
> >> WG draft.
> >>
> >>
> >>
> >>
> >>
> >
> >
> >
>

Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 19 Jul 2006 18:52:03 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: OSPF ASON Routing Solution
Date: Wed, 19 Jul 2006 14:50:39 -0400
Message-ID: <0901D1988E815341A0103206A834DA07F19F70@mdmxm02.ciena.com>
Thread-Topic: OSPF ASON Routing Solution
Thread-Index: AcarXYHCRIFV4e2oSimwcSurSlmwHgABqpyA
From: "Ong, Lyndon" <Lyong@Ciena.com>
To: "Richard Rabbat" <richard@us.fujitsu.com>, "Adrian Farrel" <adrian@olddog.co.uk>
Cc: <ccamp@ops.ietf.org>

Support this being WG as well (no objections).

Cheers,
Lyndon=20

-----Original Message-----
From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On
Behalf Of Richard Rabbat
Sent: Wednesday, July 19, 2006 10:58 AM
To: Adrian Farrel
Cc: ccamp@ops.ietf.org
Subject: Re: OSPF ASON Routing Solution

bien au contraire. fully support this becoming a WG document.
Richard.

Adrian Farrel wrote:
> Just a refresh in case you were travelling.
>
> I am seeking objections to this draft becoming a WG document.
>
> Adrian
> ----- Original Message ----- From: "Adrian Farrel"=20
> <adrian@olddog.co.uk>
> To: <ccamp@ops.ietf.org>
> Sent: Wednesday, July 12, 2006 8:10 PM
> Subject: OSPF ASON Routing Solution
>
>
>> Hi,
>> On Monday in CCAMP we discussed
>> draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt the solutions=20
>> draft for OSPF in ASON routing.
>>
>> There is agreement from the OSPF WG chair that we are not treading on

>> toes, and the meeting seemed to say that this was pretty stable.
>>
>> So a this is a quick poll to see if anyone objects to this becoming a

>> WG draft.
>> NB, this is a charter item and we have an obligation to work on this=20
>> for the ITU-T.
>>
>> Thanks,
>> Adrian
>>
>> PS Note that a solution does not have to be 100% perfect to become a=20
>> WG draft.
>>
>>
>>
>>
>>
>
>
>

Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 19 Jul 2006 18:42:34 +0000
To: Jeroen van der Ham <vdham@science.uva.nl>
Cc: ccamp@ops.ietf.org, dpapadimitriou@psg.com
Subject: Re: Questions regarding draft-ietf-ccamp-gmpls-mln-reqs-01
MIME-Version: 1.0
Message-ID: <OFF73BF2C8.FBD973EB-ONC12571B0.006066D7-C12571B0.0066C3F8@netfr.alcatel.fr>
From: Dimitri.Papadimitriou@alcatel.be
Date: Wed, 19 Jul 2006 20:42:23 +0200
Content-Type: text/plain; charset="US-ASCII"

hi jeroen - 

first thanks for commenting - reviews are needed -

see in-line:

Jeroen van der Ham <vdham@science.uva.nl>
Sent by: owner-ccamp@ops.ietf.org
19/07/2006 17:12

        To:     ccamp@ops.ietf.org
        cc: 
        Subject:        Questions regarding 
draft-ietf-ccamp-gmpls-mln-reqs-01

Hello,

I am trying to understand the text in
draft-ietf-ccamp-gmpls-mln-reqs-01, but some things are not completely
clear to me, I hope someone can explain them:

- I believe that the draft often uses the term ISCD often where ISC is
meant. If I understand it correctly, different ISCDs can be announced
for a given interface at different times, for example because the
available bandwidth is changing.

[dp] ISC refers to the switching capability, while with the inclusion of 
Max LSP Bw the ISCD describes capacity associated to one or more network 
layers

- At the end of the first paragraph in Section 3.3 it states:

> [...] in carrier's networks that are based on multiple layers,
> switching technologies, or ISCDs.

I think that this statement should not mention ISCDs at all, because it
makes no sense in that context. Especially if you also read the
following statement at the end of the third paragraph in section 4.3:

> The ISCD does not "identify" network layers, it uniquely characterizes
> information associated to one or more network layers.

[dp] will update in the next release

- I find the example in section 4.2.1 to be very briefly explained, it
could do with a better explanation of what is going on.

One improvement would be to state explicitly which three(!) ways are
possible for setting up an PSC LSP across this device:
1) Terminating on interface #b
2) Terminating on interface #a
3) Going through the device towards a neighboring PSC node.

[dp] it is two from the node perspective itself (TDM->PSC) or PSC directly

It would also help to explain that the existance of possibility 1 is the
sole reason that the device is a hybrid device. And that possibility 1
is also the reason why the PSC is advertised on Link2.

[dp] issues are related to the association between switching capabilities 
(due to the node capabilities) the exercise consisting in not 
introducing/precluding a node state but keep link state only; the text 
from previous release has been condensed and the issue becomes difficult 
to parse; will provide more details in the next release

Other minor corrections:
Section 1 mixes the notation of VC-x and VCx
Section 4.2.1 has swtching, where it should switching

[dp] ok

Jeroen.

Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 19 Jul 2006 18:37:51 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: Working Group Last Call on draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt
Date: Wed, 19 Jul 2006 13:37:14 -0500
Message-ID: <A1A52203CA93634BA1748887B9993AEA02F60BCF@USNVEX1.tellabs-west.tellabsinc.net>
Thread-Topic: Working Group Last Call on draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt
Thread-Index: AcarQJPcZAvtf5NXT4SQ6gNRFiKxcQAH/Wgg
From: "Mack-Crane, T. Benjamin" <Ben.Mack-Crane@tellabs.com>
To: "Adrian Farrel" <adrian@olddog.co.uk>
Cc: <ccamp@ops.ietf.org>, "Brungard, Deborah A, ALABS" <dbrungard@att.com>
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="us-ascii"

Hi Adrian,

See in-line.

Regards,
Ben

> -----Original Message-----
> From: Adrian Farrel [mailto:adrian@olddog.co.uk]
> Sent: Wednesday, July 19, 2006 8:26 AM
> To: Mack-Crane, T. Benjamin
> Cc: ccamp@ops.ietf.org; Brungard, Deborah A, ALABS
> Subject: Re: Working Group Last Call on
draft-ietf-ccamp-gmpls-rsvp-te-
> call-00.txt
>=20
> Ben,
>=20
> Sorry for the delay while travelling, etc.
>=20
> > Hi Adrian,
> >
> > There were also these comments which have not been fully addressed
> > afaik:
> >
> >>> 3)  The network models being used in section 4.3 and section 7 are
> >>> not clear.  In particular the relationships between the call
> >>> controllers, network boundaries, ingress/egress nodes, and
> >>> ingress/egress links are not clear.  Figures would be very helpful
> >>here.
> >>
> >> Figures are always helpful, and usually (but not always) better
than
> >> words.
> >>
> >> In order to be sure to clarify the network models that you are
finding
> >> confusing, it would be helpful if you asked specific questions or
> >> roposed text.
> >
> > It is not clear how the form of initiation of a call affects the
> > information available about the egress link. In part this may be
> > affected by whether the ingress node is inside or outside the
network
> > (IGP) boundary.  It would seem that the situation at the egress
would
> > have something to do with this as well.  It is unclear where the
egress
> > trail termination point is expected to be, e.g. inside or outside
the
> > network boundary, and, if inside, at the near or far side of the
egress
> > node's matrix.
>=20
> You have latched on to an important point. The information about the
> egress
> link might not be generally available within the TED particularly when
the
> egress node is outside the TE domain (although we should observe some
of
> the
> recent discussions about OSPF and BGP extensions for advertising PE-CE
> link
> TE capabilities).
>=20
> And, in fact, this is an important purpose of the Call, and why the
Link
> Capability object exists. The Link Capability object may be used
> when the tail-end is within or outside the the TE domain, and so we
> support
> the egress (and correspondingly the ingress) being inside or outside
the
> TE
> domain. This follows quite naturally from RFC 4208.
>=20
> We could add a statement that the ingress and egress may be inside or
> outside the TE domain if this will make you more comfortable.

It is, I think, obvious that the ingress and egress may be inside or
outside a TE domain.  What is not so obvious is the need for the Link
Capability object, i.e. exactly what problem it is solving.  On reading
the draft, this was not at all clear to me.  Unfortunately I had
sufficient difficulty understanding the problem statement that I did not
immediately question the need for the object (hoping that clarification
of the problem would shed light on this).  However, if the policy in
CCAMP is that revising the text is not necessary as long as the intended
meaning is clear to the authors... then perhaps there is nothing to be
added (or subtracted;-) at this point.

>=20
> >> >5)       The call control mechanism defined appears to support
> >> > only IPv4 or IPv6 addressed endpoints from a single address
> >> > space.  Is this correct?
> >>
> >>  I don't think so.
> >
> > I would be interested to know how to correctly understand the draft.
> > That is, what addressing other than IPv4/6 is supported, and how
> > multiple address spaces are supported.
>=20
> Hmmm. Perhaps an issue of punctuation in your original question?
>=20
> Yes: we only support IPv4 or IPv6 addresses.
> No: we don't require the use of a single address space, as discussed
in
> RFC
> 4208.

OK, thanks for clarifying.

>=20
> Hope that answers for you.
>=20
> Regards,
> Adrian
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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

Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 19 Jul 2006 18:08:44 +0000
Message-ID: <44BE74FF.2050002@us.fujitsu.com>
Date: Wed, 19 Jul 2006 11:07:59 -0700
From: Richard Rabbat <richard@us.fujitsu.com>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: Lucy Yong <lucyyong@huawei.com>
CC: "'Huub van Helvoort'" <hhelvoort@chello.nl>, "'Ong, Lyndon'" <Lyong@Ciena.com>, ccamp@ops.ietf.org, Richard Rabbat <richard@us.fujitsu.com>
Subject: Re: association object
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Lucy,

If you mean the value of the association id, we specifically left it out 
of the responsibility of the gmpls suite of protocols. An NMS or other 
outside entity is perfectly capable of making the assignment. 
In my mind this assignment should be centralized; otherwise, multiple 
independent sources may decide to use the same id.

Richard.

Lucy Yong wrote:
> Huub,
>
> Thank you fro the answer. The value I mentioned is for VCG group ID.
>
> Regards,
> Lucy
>
> -----Original Message-----
> From: Huub van Helvoort [mailto:hhelvoort@chello.nl] 
> Sent: Wednesday, July 19, 2006 7:38 AM
> To: Lucy Yong; 'Ong, Lyndon'; richard@us.fujitsu.com; ccamp@ops.ietf.org
> Subject: Re: RE: association object
>
> Dear Lucy,
>
> You wrote:
>
>   
>> Thank you for the explanation. Thus, this association is only significant
>>     
> at
>   
>> the destination, is that right?
>>     
>
> Yes, intermediate nodes do not have to be aware of the association between
> the LSPs in a VCG.
>
>   
>>  Is VCG group value generated by the source?
>>     
>
> I am not sure what you mean by value.
> Is it the identifier for a specific VCG, or
> is it the size (number of LSPs) of the VCG?
>
> Cheers, Huub.
>  
>   
>>   _____  
>>
>> From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf
>> Of Ong, Lyndon
>> Sent: Tuesday, July 18, 2006 12:26 PM
>> To: Lucy Yong; richard@us.fujitsu.com; ccamp@ops.ietf.org
>> Subject: RE: association object
>>
>> Hi Lucy,
>>
>> The association object is used to associate components of a VCG that are
>> already diversely routed in the draft, I would think diverse routing is
>>     
> more
>   
>> a 
>> feature of path computation than the signaling to set up the component.
>>
>> What the association object does is allow you to tell what LSPs arriving
>>     
> at
>   
>> the destination are part of the same VCG.
>>
>> Cheers,
>>
>> Lyndon
>>
>>   _____  
>>
>> From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf
>> Of Lucy Yong
>> Sent: Tuesday, July 18, 2006 7:16 AM
>> To: richard@us.fujitsu.com; ccamp@ops.ietf.org
>> Subject: association object
>>
>> Richard,
>>
>> It was nice to meet you in IETF meeting. I have a question about
>>     
> association
>   
>> object used to associate the diversely routed LSPs. 
>>
>> If a LSP is established first, say LSP1, then another LSP (say LSP2) needs
>> to be established and be diversely routed from LSP1, how association
>>     
> object
>   
>> is applied in this case? It is easy to use in the latter LSP request,
>> however, how does LSP1 know that it needs to diverse from LSP2.
>>
>> What is the relationship between this association object and diversity
>> object in GMPLS.
>>
>> Best Regards,
>>
>> Lucy
>>
>>     
>
>
>
>
>   

Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 19 Jul 2006 17:58:56 +0000
Message-ID: <44BE72C4.6050004@us.fujitsu.com>
Date: Wed, 19 Jul 2006 10:58:28 -0700
From: Richard Rabbat <richard@us.fujitsu.com>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: Adrian Farrel <adrian@olddog.co.uk>
CC: ccamp@ops.ietf.org
Subject: Re: OSPF ASON Routing Solution
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

bien au contraire. fully support this becoming a WG document.
Richard.

Adrian Farrel wrote:
> Just a refresh in case you were travelling.
>
> I am seeking objections to this draft becoming a WG document.
>
> Adrian
> ----- Original Message ----- From: "Adrian Farrel" <adrian@olddog.co.uk>
> To: <ccamp@ops.ietf.org>
> Sent: Wednesday, July 12, 2006 8:10 PM
> Subject: OSPF ASON Routing Solution
>
>
>> Hi,
>> On Monday in CCAMP we discussed 
>> draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt the solutions 
>> draft for OSPF in ASON routing.
>>
>> There is agreement from the OSPF WG chair that we are not treading on 
>> toes, and the meeting seemed to say that this was pretty stable.
>>
>> So a this is a quick poll to see if anyone objects to this becoming a 
>> WG draft.
>> NB, this is a charter item and we have an obligation to work on this 
>> for the ITU-T.
>>
>> Thanks,
>> Adrian
>>
>> PS Note that a solution does not have to be 100% perfect to become a 
>> WG draft.
>>
>>
>>
>>
>>
>
>
>

Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 19 Jul 2006 17:55:02 +0000
Subject: Re: OSPF ASON Routing Solution
To: "Adrian Farrel" <adrian@olddog.co.uk>
Cc: ccamp@ops.ietf.org, owner-ccamp@ops.ietf.org
Message-ID: <OF46100B38.E08FA08D-ONC12571B0.00622D8D-C12571B0.0062515C@netfr.alcatel.fr>
From: Emmanuel.Desmet@alcatel.be
Date: Wed, 19 Jul 2006 19:53:53 +0200
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

Adrian,

I am all in favour of making this a WG I-D,

@+ mannu

                      "Adrian Farrel"                                                                                                
                      <adrian@olddog.c         To:      <ccamp@ops.ietf.org>                                                         
                      o.uk>                    cc:                                                                                   
                      Sent by:                 Subject: Re: OSPF ASON Routing Solution                                               
                      owner-ccamp@ops.                                                                                               
                      ietf.org                                                                                                       

                      19/07/2006 15:27                                                                                               
                      Please respond                                                                                                 
                      to "Adrian                                                                                                     
                      Farrel"                                                                                                        

Just a refresh in case you were travelling.

I am seeking objections to this draft becoming a WG document.

Adrian
----- Original Message -----
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: <ccamp@ops.ietf.org>
Sent: Wednesday, July 12, 2006 8:10 PM
Subject: OSPF ASON Routing Solution

> Hi,
> On Monday in CCAMP we discussed
> draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt the solutions draft
for
> OSPF in ASON routing.
>
> There is agreement from the OSPF WG chair that we are not treading on
> toes, and the meeting seemed to say that this was pretty stable.
>
> So a this is a quick poll to see if anyone objects to this becoming a WG
> draft.
> NB, this is a charter item and we have an obligation to work on this for
> the ITU-T.
>
> Thanks,
> Adrian
>
> PS Note that a solution does not have to be 100% perfect to become a WG
> draft.
>
>
>
>
>

Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 19 Jul 2006 15:13:17 +0000
Message-ID: <44BE4BDB.8050304@science.uva.nl>
Date: Wed, 19 Jul 2006 17:12:27 +0200
From: Jeroen van der Ham <vdham@science.uva.nl>
User-Agent: Thunderbird 1.5.0.4 (Macintosh/20060530)
MIME-Version: 1.0
To:  ccamp@ops.ietf.org
Subject: Questions regarding draft-ietf-ccamp-gmpls-mln-reqs-01
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hello,

I am trying to understand the text in
draft-ietf-ccamp-gmpls-mln-reqs-01, but some things are not completely
clear to me, I hope someone can explain them:

- I believe that the draft often uses the term ISCD often where ISC is
meant. If I understand it correctly, different ISCDs can be announced
for a given interface at different times, for example because the
available bandwidth is changing.

- At the end of the first paragraph in Section 3.3 it states:

> [...] in carrier's networks that are based on multiple layers,
> switching technologies, or ISCDs.

I think that this statement should not mention ISCDs at all, because it
makes no sense in that context. Especially if you also read the
following statement at the end of the third paragraph in section 4.3:

> The ISCD does not "identify" network layers, it uniquely characterizes
> information associated to one or more network layers.

- I find the example in section 4.2.1 to be very briefly explained, it
could do with a better explanation of what is going on.
One improvement would be to state explicitly which three(!) ways are
possible for setting up an PSC LSP across this device:
1) Terminating on interface #b
2) Terminating on interface #a
3) Going through the device towards a neighboring PSC node.

It would also help to explain that the existance of possibility 1 is the
sole reason that the device is a hybrid device. And that possibility 1
is also the reason why the PSC is advertised on Link2.

Other minor corrections:
Section 1 mixes the notation of VC-x and VCx
Section 4.2.1 has swtching, where it should switching

Jeroen.

Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 19 Jul 2006 14:36:27 +0000
Message-ID: <00c501c6ab40$7ebf7110$0a23fea9@your029b8cecfe>
Reply-To: "Adrian Farrel" <adrian@olddog.co.uk>
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: "Mack-Crane, T. Benjamin" <Ben.Mack-Crane@tellabs.com>
Cc: <ccamp@ops.ietf.org>, "Brungard, Deborah A, ALABS" <dbrungard@att.com>
Subject: Re: Working Group Last Call on draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt
Date: Wed, 19 Jul 2006 14:26:02 +0100
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response
Content-Transfer-Encoding: 7bit

Ben,

Sorry for the delay while travelling, etc.

> Hi Adrian,
>
> There were also these comments which have not been fully addressed
> afaik:
>
>>> 3)  The network models being used in section 4.3 and section 7 are
>>> not clear.  In particular the relationships between the call
>>> controllers, network boundaries, ingress/egress nodes, and
>>> ingress/egress links are not clear.  Figures would be very helpful
>>here.
>>
>> Figures are always helpful, and usually (but not always) better than
>> words.
>>
>> In order to be sure to clarify the network models that you are finding
>> confusing, it would be helpful if you asked specific questions or
>> roposed text.
>
> It is not clear how the form of initiation of a call affects the
> information available about the egress link. In part this may be
> affected by whether the ingress node is inside or outside the network
> (IGP) boundary.  It would seem that the situation at the egress would
> have something to do with this as well.  It is unclear where the egress
> trail termination point is expected to be, e.g. inside or outside the
> network boundary, and, if inside, at the near or far side of the egress
> node's matrix.

You have latched on to an important point. The information about the egress 
link might not be generally available within the TED particularly when the 
egress node is outside the TE domain (although we should observe some of the 
recent discussions about OSPF and BGP extensions for advertising PE-CE link 
TE capabilities).

And, in fact, this is an important purpose of the Call, and why the Link 
Capability object exists. The Link Capability object may be used
when the tail-end is within or outside the the TE domain, and so we support 
the egress (and correspondingly the ingress) being inside or outside the TE 
domain. This follows quite naturally from RFC 4208.

We could add a statement that the ingress and egress may be inside or 
outside the TE domain if this will make you more comfortable.

>> >5)       The call control mechanism defined appears to support
>> > only IPv4 or IPv6 addressed endpoints from a single address
>> > space.  Is this correct?
>>
>>  I don't think so.
>
> I would be interested to know how to correctly understand the draft.
> That is, what addressing other than IPv4/6 is supported, and how
> multiple address spaces are supported.

Hmmm. Perhaps an issue of punctuation in your original question?

Yes: we only support IPv4 or IPv6 addresses.
No: we don't require the use of a single address space, as discussed in RFC 
4208.

Hope that answers for you.

Regards,
Adrian 

Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 19 Jul 2006 14:36:19 +0000
Message-ID: <00c601c6ab40$7f534ca0$0a23fea9@your029b8cecfe>
Reply-To: "Adrian Farrel" <adrian@olddog.co.uk>
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: <ccamp@ops.ietf.org>
Subject: Re: OSPF ASON Routing Solution
Date: Wed, 19 Jul 2006 14:27:17 +0100
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response
Content-Transfer-Encoding: 7bit

Just a refresh in case you were travelling.

I am seeking objections to this draft becoming a WG document.

Adrian
----- Original Message ----- 
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: <ccamp@ops.ietf.org>
Sent: Wednesday, July 12, 2006 8:10 PM
Subject: OSPF ASON Routing Solution

> Hi,
> On Monday in CCAMP we discussed 
> draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt the solutions draft for 
> OSPF in ASON routing.
>
> There is agreement from the OSPF WG chair that we are not treading on 
> toes, and the meeting seemed to say that this was pretty stable.
>
> So a this is a quick poll to see if anyone objects to this becoming a WG 
> draft.
> NB, this is a charter item and we have an obligation to work on this for 
> the ITU-T.
>
> Thanks,
> Adrian
>
> PS Note that a solution does not have to be 100% perfect to become a WG 
> draft.
>
>
>
>
> 

Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 19 Jul 2006 14:08:11 +0000
Date: Wed, 19 Jul 2006 09:06:43 -0500
From: Lucy Yong <lucyyong@huawei.com>
Subject: RE: RE: association object
To: 'Huub van Helvoort' <hhelvoort@chello.nl>, "'Ong, Lyndon'" <Lyong@Ciena.com>, richard@us.fujitsu.com, ccamp@ops.ietf.org
Message-id: <00e301c6ab3c$90f635c0$a5087c0a@china.huawei.com>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Thread-index: AcarMKYXJmBYgdZXQrqHiH7zRwKupAAC78Iw

Huub,

Thank you fro the answer. The value I mentioned is for VCG group ID.

Regards,
Lucy

-----Original Message-----
From: Huub van Helvoort [mailto:hhelvoort@chello.nl] 
Sent: Wednesday, July 19, 2006 7:38 AM
To: Lucy Yong; 'Ong, Lyndon'; richard@us.fujitsu.com; ccamp@ops.ietf.org
Subject: Re: RE: association object

Dear Lucy,

You wrote:

> Thank you for the explanation. Thus, this association is only significant
at
> the destination, is that right?

Yes, intermediate nodes do not have to be aware of the association between
the LSPs in a VCG.

>  Is VCG group value generated by the source?

I am not sure what you mean by value.
Is it the identifier for a specific VCG, or
is it the size (number of LSPs) of the VCG?

Cheers, Huub.

>   _____  
> 
> From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf
> Of Ong, Lyndon
> Sent: Tuesday, July 18, 2006 12:26 PM
> To: Lucy Yong; richard@us.fujitsu.com; ccamp@ops.ietf.org
> Subject: RE: association object
> 
> Hi Lucy,
> 
> The association object is used to associate components of a VCG that are
> already diversely routed in the draft, I would think diverse routing is
more
> a 
> feature of path computation than the signaling to set up the component.
> 
> What the association object does is allow you to tell what LSPs arriving
at
> the destination are part of the same VCG.
> 
> Cheers,
> 
> Lyndon
> 
>   _____  
> 
> From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf
> Of Lucy Yong
> Sent: Tuesday, July 18, 2006 7:16 AM
> To: richard@us.fujitsu.com; ccamp@ops.ietf.org
> Subject: association object
> 
> Richard,
> 
> It was nice to meet you in IETF meeting. I have a question about
association
> object used to associate the diversely routed LSPs. 
> 
> If a LSP is established first, say LSP1, then another LSP (say LSP2) needs
> to be established and be diversely routed from LSP1, how association
object
> is applied in this case? It is easy to use in the latter LSP request,
> however, how does LSP1 know that it needs to diverse from LSP2.
> 
> What is the relationship between this association object and diversity
> object in GMPLS.
> 
> Best Regards,
> 
> Lucy
> 

Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 19 Jul 2006 12:39:41 +0000
From: Huub van Helvoort <hhelvoort@chello.nl>
To: Lucy Yong <lucyyong@huawei.com>,"'Ong, Lyndon'" <Lyong@Ciena.com>,<richard@us.fujitsu.com>,<ccamp@ops.ietf.org>
Subject: Re: RE: association object
Date: Wed, 19 Jul 2006 14:37:57 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Message-Id: <20060719123757.SFPK1836.amsfep12-int.chello.nl@localhost>

Dear Lucy,

You wrote:

> Thank you for the explanation. Thus, this association is only significant at
> the destination, is that right?

Yes, intermediate nodes do not have to be aware of the association between
the LSPs in a VCG.

>  Is VCG group value generated by the source?

I am not sure what you mean by value.
Is it the identifier for a specific VCG, or
is it the size (number of LSPs) of the VCG?

Cheers, Huub.

>   _____  
> 
> From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf
> Of Ong, Lyndon
> Sent: Tuesday, July 18, 2006 12:26 PM
> To: Lucy Yong; richard@us.fujitsu.com; ccamp@ops.ietf.org
> Subject: RE: association object
> 
> Hi Lucy,
> 
> The association object is used to associate components of a VCG that are
> already diversely routed in the draft, I would think diverse routing is more
> a 
> feature of path computation than the signaling to set up the component.
> 
> What the association object does is allow you to tell what LSPs arriving at
> the destination are part of the same VCG.
> 
> Cheers,
> 
> Lyndon
> 
>   _____  
> 
> From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf
> Of Lucy Yong
> Sent: Tuesday, July 18, 2006 7:16 AM
> To: richard@us.fujitsu.com; ccamp@ops.ietf.org
> Subject: association object
> 
> Richard,
> 
> It was nice to meet you in IETF meeting. I have a question about association
> object used to associate the diversely routed LSPs. 
> 
> If a LSP is established first, say LSP1, then another LSP (say LSP2) needs
> to be established and be diversely routed from LSP1, how association object
> is applied in this case? It is easy to use in the latter LSP request,
> however, how does LSP1 know that it needs to diverse from LSP2.
> 
> What is the relationship between this association object and diversity
> object in GMPLS.
> 
> Best Regards,
> 
> Lucy
> 

Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 18 Jul 2006 20:35:32 +0000
Message-ID: <44BD45E2.3080104@psg.com>
Date: Tue, 18 Jul 2006 22:34:42 +0200
From: dimitri papadimitriou <dpapadimitriou@psg.com>
Reply-To:  dpapadimitriou@psg.com,  dimitri.papadimitriou@alcatel.be
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728
MIME-Version: 1.0
To: "Dean Cheng (dcheng)" <dcheng@cisco.com>
CC:  ccamp@ops.ietf.org
Subject: Re: Some comments on draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

dean

thanks for commenting - see in-line

Dean Cheng (dcheng) wrote:

> Dimitri,
>  
> I've some comments now as follows:
>  
> 1) The third paragraph of section 6.1, it says, "....However, an
>     additional restriction MUST be applied such that the RC 
>     selection process takes into account that an upper level may
>     be adjacent to one or more lower levels."
>
>     It would be good to clarify the words "one or more lower levels"
>     here. From the sentence after that, it actually means one or 
>     more areas at the lower levels.

ok

> 2) In section 6.1, it says that the D bit is used together with the
>    "Associated Area ID" sub-tlv, as "an additional restriction". In
>     the same section, it does not mention the use of that sub-tlv
>     along with U bit.
>  
>    But in section 6.2.1 and 6.2.2, it explicitly says that the
> "Associated
>    Area ID" sub-tlv is included when re-originating the opaque LSA 
>    downward or upward. 
>  
>    It would require clarification and consistency here.

i will split this section 6.1 into two parts and refer to section 6.2 
for the case addressed by that section

> 3) In section 6.1 (Discovery and Selection), it describes a method
>     for "selecting" the RC that performs the upward/downward
> dissemination
>     of routing information. 
>  
>     What happens if RC1 is currently the RC that doing the upward
> advertising
>     but RC2 just becomes active with U-bit set and a higher Router ID ? 
>  
>     I guess the same handling as OSPF DR's election can be used for
>     stability purpose, and also for consistency, and if so, needs to be
> stated 
>     in this section. 

indeed hysteresis mechanism is needed in such condition

> And for that matter, the word "selection" vs.
> "election" does not really make much difference.
>  
> 4) In section 7.2, it is also useful to add that the number of levels be
> under
>     policy control.

ok

> 5) It would be useful to add an interoperability section, which
> describes how
>     an traditional OSPF node/network interoperates (if need to) with an
> OSPF 
>     node/network with extensions as described in this ID. E.g., a
> reachable
>     address (prefix) is advertised by an ABR normally but with this ID,
> can also
>     be advertised through hierarchy.

i guess you mean a GMPLS LSR not implementing these extensions ?

thanks,
- dimitri.

> Thanks
> Dean 
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>   
>  
>  
>  
>  
>  
>  
>  
>   
> 

Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 18 Jul 2006 18:45:28 +0000
Date: Tue, 18 Jul 2006 13:44:25 -0500
From: Lucy Yong <lucyyong@huawei.com>
Subject: RE: association object
To: "'Ong, Lyndon'" <Lyong@Ciena.com>, richard@us.fujitsu.com, ccamp@ops.ietf.org
Message-id: <00b501c6aa9a$321acae0$a5087c0a@china.huawei.com>
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_SlT/fxYiFLN1R7mHlVaUDA)"
Thread-index: AcaqdMAu71h2jF0ESMCbA6g/yiG4pQAGe8HgAAKhZyA=

This is a multi-part message in MIME format.

--Boundary_(ID_SlT/fxYiFLN1R7mHlVaUDA)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT

Hi Lyndon,

Thank you for the explanation. Thus, this association is only significant at
the destination, is that right? Is VCG group value generated by the source?

Best Regards,

Lucy

  _____  

From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf
Of Ong, Lyndon
Sent: Tuesday, July 18, 2006 12:26 PM
To: Lucy Yong; richard@us.fujitsu.com; ccamp@ops.ietf.org
Subject: RE: association object

Hi Lucy,

The association object is used to associate components of a VCG that are

already diversely routed in the draft, I would think diverse routing is more
a 

feature of path computation than the signaling to set up the component.

What the association object does is allow you to tell what LSPs arriving at

the destination are part of the same VCG.

Cheers,

Lyndon

  _____  

From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf
Of Lucy Yong
Sent: Tuesday, July 18, 2006 7:16 AM
To: richard@us.fujitsu.com; ccamp@ops.ietf.org
Subject: association object

Richard,

It was nice to meet you in IETF meeting. I have a question about association
object used to associate the diversely routed LSPs. 

If a LSP is established first, say LSP1, then another LSP (say LSP2) needs
to be established and be diversely routed from LSP1, how association object
is applied in this case? It is easy to use in the latter LSP request,
however, how does LSP1 know that it needs to diverse from LSP2.

What is the relationship between this association object and diversity
object in GMPLS.

Best Regards,

Lucy

--Boundary_(ID_SlT/fxYiFLN1R7mHlVaUDA)
Content-type: text/html; charset=us-ascii
Content-transfer-encoding: 7BIT

<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:st1="urn:schemas-microsoft-com:office:smarttags" xmlns="http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]--><o:SmartTagType
 namespaceuri="urn:schemas-microsoft-com:office:smarttags" name="PersonName"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Courier;
	panose-1:2 7 4 9 2 2 5 2 4 4;}
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal;
	font-family:Courier;
	color:windowtext;
	font-weight:normal;
	font-style:normal;
	text-decoration:none none;}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:Courier;
	color:blue;
	font-weight:normal;
	font-style:normal;
	text-decoration:none none;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=EN-US link=blue vlink=purple>

<div class=Section1>

<p class=MsoNormal><font size=2 color=blue face=Courier><span style='font-size:
10.0pt;font-family:Courier;color:blue'>Hi Lyndon,<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=blue face=Courier><span style='font-size:
10.0pt;font-family:Courier;color:blue'><o:p>&nbsp;</o:p></span></font></p>

Thank you for the explanation. Thus, this
association is only significant at the destination, is that right? Is VCG group
value generated by the source?<o:p></o:p>

<p class=MsoNormal><font size=2 color=blue face=Courier><span style='font-size:
10.0pt;font-family:Courier;color:blue'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color=blue face=Courier><span style='font-size:
10.0pt;font-family:Courier;color:blue'>Best Regards,<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=blue face=Courier><span style='font-size:
10.0pt;font-family:Courier;color:blue'>Lucy<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=blue face=Courier><span style='font-size:
10.0pt;font-family:Courier;color:blue'><o:p>&nbsp;</o:p></span></font></p>

<div>

<div class=MsoNormal align=center style='text-align:center'><font size=3
face="Times New Roman"><span style='font-size:12.0pt'>

<hr size=2 width="100%" align=center tabindex=-1>

</span></font></div>

<p class=MsoNormal><b><font size=2 face=Tahoma><span style='font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font size=2
face=Tahoma><span style='font-size:10.0pt;font-family:Tahoma'>
owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] <b><span
style='font-weight:bold'>On Behalf Of </span></b>Ong, Lyndon<br>
<b><span style='font-weight:bold'>Sent:</span></b> Tuesday, July 18, 2006 12:26
PM<br>
<b><span style='font-weight:bold'>To:</span></b> <st1:PersonName w:st="on">Lucy
 Yong</st1:PersonName>; richard@us.fujitsu.com; ccamp@ops.ietf.org<br>
<b><span style='font-weight:bold'>Subject:</span></b> RE: association object</span></font><o:p></o:p></p>

</div>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color=blue face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:blue'>Hi Lucy,</span></font><o:p></o:p></p>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=blue face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:blue'>The association object is used to
associate components of a VCG that are</span></font><o:p></o:p></p>

<p class=MsoNormal><font size=2 color=blue face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:blue'>already diversely routed in the draft, I
would think diverse routing is more a </span></font><o:p></o:p></p>

<p class=MsoNormal><font size=2 color=blue face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:blue'>feature of path computation than the signaling
to set up the component.</span></font><o:p></o:p></p>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=blue face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:blue'>What the association object does is allow
you to tell what LSPs arriving at</span></font><o:p></o:p></p>

<p class=MsoNormal><font size=2 color=blue face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:blue'>the destination are part of the same VCG.</span></font><o:p></o:p></p>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=blue face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:blue'>Cheers,</span></font><o:p></o:p></p>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=blue face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:blue'>Lyndon</span></font><o:p></o:p></p>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<div class=MsoNormal align=center style='text-align:center'><font size=3
face="Times New Roman"><span style='font-size:12.0pt'>

<hr size=2 width="100%" align=center tabIndex=-1>

</span></font></div>

<p class=MsoNormal style='margin-bottom:12.0pt'><b><font size=2 face=Tahoma><span
style='font-size:10.0pt;font-family:Tahoma;font-weight:bold'>From:</span></font></b><font
size=2 face=Tahoma><span style='font-size:10.0pt;font-family:Tahoma'>
owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] <b><span
style='font-weight:bold'>On Behalf Of </span></b><st1:PersonName w:st="on">Lucy
 Yong</st1:PersonName><br>
<b><span style='font-weight:bold'>Sent:</span></b> Tuesday, July 18, 2006 7:16
AM<br>
<b><span style='font-weight:bold'>To:</span></b> richard@us.fujitsu.com;
ccamp@ops.ietf.org<br>
<b><span style='font-weight:bold'>Subject:</span></b> association object</span></font><o:p></o:p></p>

<p class=MsoNormal><font size=2 face=Courier><span style='font-size:10.0pt;
font-family:Courier'>Richard,<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 face=Courier><span style='font-size:10.0pt;
font-family:Courier'><o:p>&nbsp;</o:p></span></font></p>

It was nice to meet you in IETF meeting. I have a question
about association object used to associate the diversely routed LSPs. <o:p></o:p>

<p class=MsoNormal><font size=2 face=Courier><span style='font-size:10.0pt;
font-family:Courier'><o:p>&nbsp;</o:p></span></font></p>

If a LSP is established first, say LSP1, then another LSP
(say LSP2) needs to be established and be diversely routed from LSP1, how
association object is applied in this case? It is easy to use in the latter LSP
request, however, how does LSP1 know that it needs to diverse from LSP2.<o:p></o:p>

<p class=MsoNormal><font size=2 face=Courier><span style='font-size:10.0pt;
font-family:Courier'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 face=Courier><span style='font-size:10.0pt;
font-family:Courier'>What is the relationship between this association object
and diversity object in GMPLS.<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 face=Courier><span style='font-size:10.0pt;
font-family:Courier'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 face=Courier><span style='font-size:10.0pt;
font-family:Courier'>Best Regards,<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 face=Courier><span style='font-size:10.0pt;
font-family:Courier'>Lucy<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 face=Courier><span style='font-size:10.0pt;
font-family:Courier'>&nbsp;&nbsp;<o:p></o:p></span></font></p>

</div>

</body>

</html>

--Boundary_(ID_SlT/fxYiFLN1R7mHlVaUDA)--

Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 18 Jul 2006 18:07:44 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6AA94.FC1F4A82"
Subject: Some comments on draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt
Date: Tue, 18 Jul 2006 11:07:09 -0700
Message-ID: <70BC84B185C3EE448EDB7AB8956D3B0E02027B9D@xmb-sjc-234.amer.cisco.com>
Thread-Topic: Some comments on draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt
Thread-Index: AcaqlPxo/zGHXQwESA+h2k+BWgdRSA==
From: "Dean Cheng \(dcheng\)" <dcheng@cisco.com>
To: "dimitri papadimitriou" <dpapadimitriou@psg.com>
Cc: <ccamp@ops.ietf.org>
DKIM-Signature: a=rsa-sha1; q=dns; l=12595; t=1153246030; x=1154110030; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dcheng@cisco.com; z=From:=22Dean=20Cheng=20\(dcheng\)=22=20<dcheng@cisco.com> |Subject:Some=20comments=20on=20draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.tx t; X=v=3Dcisco.com=3B=20h=3Dcai6wrVC2pg1fEo/asIk2w08toY=3D; b=rOqmc3A/fC5HPdhlM51ZZTA4wYhWNFXqzJhlA0OcDGAyw0tRozvoDCUakGVd7NXLemvFAjRY JsopXZIuUafGDMdFi6OvXklutaLHmc0kb1XdBDYu7MVsKXZIrsyKHkdy;
Authentication-Results: sj-dkim-3.cisco.com; header.From=dcheng@cisco.com; dkim=pass ( 59 extraneous bytes; sig from cisco.com verified; );

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6AA94.FC1F4A82
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Dimitri,
=20
I've some comments now as follows:
=20
1) The third paragraph of section 6.1, it says, "....However, an
    additional restriction MUST be applied such that the RC=20
    selection process takes into account that an upper level may
    be adjacent to one or more lower levels."
=20
    It would be good to clarify the words "one or more lower levels"
    here. From the sentence after that, it actually means one or=20
    more areas at the lower levels.
=20
2) In section 6.1, it says that the D bit is used together with the
   "Associated Area ID" sub-tlv, as "an additional restriction". In
    the same section, it does not mention the use of that sub-tlv
    along with U bit.
=20
   But in section 6.2.1 and 6.2.2, it explicitly says that the
"Associated
   Area ID" sub-tlv is included when re-originating the opaque LSA=20
   downward or upward.=20
=20
   It would require clarification and consistency here.
=20
3) In section 6.1 (Discovery and Selection), it describes a method
    for "selecting" the RC that performs the upward/downward
dissemination
    of routing information.=20
=20
    What happens if RC1 is currently the RC that doing the upward
advertising
    but RC2 just becomes active with U-bit set and a higher Router ID ?=20
=20
    I guess the same handling as OSPF DR's election can be used for
    stability purpose, and also for consistency, and if so, needs to be
stated=20
    in this section. And for that matter, the word "selection" vs.
"election"
    does not really make much difference.
=20
4) In section 7.2, it is also useful to add that the number of levels be
under
    policy control.
=20
5) It would be useful to add an interoperability section, which
describes how
    an traditional OSPF node/network interoperates (if need to) with an
OSPF=20
    node/network with extensions as described in this ID. E.g., a
reachable
    address (prefix) is advertised by an ABR normally but with this ID,
can also
    be advertised through hierarchy.
=20
Thanks
Dean=20
=20
=20
=20
=20
=20
=20
=20
=20
=20
=20
=20
=20
=20
=20
=20
=20
=20
 =20
=20
=20
=20
=20
=20
=20
=20
 =20

------_=_NextPart_001_01C6AA94.FC1F4A82
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.2914" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN=20
class=3D048492323-17072006>Dimitri,</DIV>
<DIV><SPAN=20
class=3D048492323-17072006>&nbsp;</DIV>
<DIV>I've =
some comments=20
now as follows:</DIV>
<DIV><SPAN=20
class=3D048492323-17072006>&nbsp;</DIV>
<DIV>1) The =
third=20
paragraph of section 6.1, it says, "....However, an</DIV>
<DIV>&nbsp;&nbsp;&nbsp;=20
additional restriction MUST be applied such that the RC =
</DIV>
<DIV>&nbsp;&nbsp;&nbsp;=20
selection process takes into account that an upper level =
may</DIV>
<DIV>&nbsp;&nbsp;&nbsp;=20
be adjacent to one or more lower levels."</DIV>
<DIV><SPAN=20
class=3D048492323-17072006>&nbsp;</DIV>
<DIV>&nbsp;&nbsp;&nbsp;=20
It would be good to clarify the words "one or more lower=20
levels"</DIV>
<DIV>&nbsp;&nbsp;&nbsp;=20
here. From the sentence after that, it&nbsp;actually means&nbsp;one=20
or=20
</DIV>
<DIV>&nbsp;&nbsp;&nbsp;=20
more areas at the lower levels.</DIV>
<DIV><SPAN=20
class=3D048492323-17072006>&nbsp;</DIV>
<DIV>2) In =
section 6.1,=20
it says that the D bit is used together with the</DIV>
<DIV>&nbsp; =

&nbsp;"Associated Area ID" sub-tlv, as "an additional restriction".=20
In</DIV>
<DIV>&nbsp;&nbsp;&nbsp;=20
the same section, it does not mention the use of that=20
sub-tlv</DIV>
<DIV>&nbsp;&nbsp;&nbsp;=20
along with U bit.</DIV>
<DIV><SPAN=20
class=3D048492323-17072006>&nbsp;</DIV>
<DIV>&nbsp;&nbsp; But in=20
section 6.2.1 and 6.2.2, it explicitly says that the=20
"Associated</DIV>
<DIV>&nbsp;&nbsp; Area=20
ID" sub-tlv is included when re-originating the opaque LSA =
</DIV>
<DIV><SPAN=20
class=3D048492323-17072006>&nbsp;&nbsp;&nbsp;downward or upward.=20
</DIV>
<DIV><SPAN=20
class=3D048492323-17072006>&nbsp;</DIV>
<DIV>&nbsp;&nbsp;&nbsp;It=20
would require clarification and consistency here.</DIV>
<DIV><SPAN=20
class=3D048492323-17072006>&nbsp;</DIV>
<DIV>3) In=20
section&nbsp;6.1 (Discovery and Selection), it describes a=20
method</DIV>
<DIV>&nbsp;&nbsp;&nbsp;=20
for&nbsp;"selecting" the RC that performs the upward/downward=20
dissemination</DIV>
<DIV>&nbsp;&nbsp;&nbsp;=20
of routing information. </DIV>
<DIV><SPAN=20
class=3D048492323-17072006>&nbsp;</DIV>
<DIV><SPAN=20
class=3D048492323-17072006>&nbsp;&nbsp;&nbsp;&nbsp;What&nbsp;happens =
if&nbsp;RC1=20
is currently the RC that doing the upward =
advertising</DIV>
<DIV>&nbsp;&nbsp;&nbsp;=20
but&nbsp;RC2 just becomes active with U-bit set and a higher Router ID ? =

</DIV>
<DIV><SPAN=20
class=3D048492323-17072006>&nbsp;</DIV>
<DIV>&nbsp;&nbsp;&nbsp; I=20
guess the same handling as OSPF DR's&nbsp;election can be used=20
for</DIV>
<DIV>&nbsp;&nbsp;&nbsp;=20
stability purpose, and also for consistency, and if so, needs to be =
stated=20
</DIV>
<DIV>&nbsp;&nbsp;&nbsp;=20
in this section. And for that matter, the word "selection" vs.=20
"election"</DIV>
<DIV>&nbsp;&nbsp;&nbsp;=20
does not really&nbsp;make much difference.</DIV>
<DIV><SPAN=20
class=3D048492323-17072006>&nbsp;</DIV>
<DIV>4) In =
section 7.2,=20
it is also useful to add that the number of levels be =
under</DIV>
<DIV><SPAN=20
class=3D048492323-17072006>&nbsp;&nbsp;&nbsp;&nbsp;policy=20
control.</DIV>
<DIV><SPAN=20
class=3D048492323-17072006>&nbsp;</DIV>
<DIV>5) It =
would be=20
useful to add an interoperability section, which describes=20
how</DIV>
<DIV>&nbsp;&nbsp;&nbsp;=20
an traditional OSPF node/network interoperates (if need to)&nbsp;with an =
OSPF=20
</DIV>
<DIV>&nbsp;&nbsp;&nbsp;=20
node/network <SPAN=20
class=3D048492323-17072006>with extensions as described in this ID. =
E.g., a=20
reachable</DIV>
<DIV>&nbsp;&nbsp;&nbsp;=20
address (prefix) is advertised by an&nbsp;ABR normally but&nbsp;with=20
this&nbsp;ID, can also</DIV>
<DIV>&nbsp;&nbsp;=20
&nbsp;be<SPAN=20
class=3D048492323-17072006>&nbsp;advertised through =
hierarchy.</DIV>
<DIV><SPAN=20
class=3D048492323-17072006>&nbsp;</DIV>
<DIV><SPAN=20
class=3D048492323-17072006>Thanks</DIV>
<DIV><SPAN=20
class=3D048492323-17072006>Dean&nbsp;</DIV>
<DIV><SPAN=20
class=3D048492323-17072006>&nbsp;</DIV>
<DIV><SPAN=20
class=3D048492323-17072006>&nbsp;</DIV>
<DIV><SPAN=20
class=3D048492323-17072006>&nbsp;</DIV>
<DIV><SPAN=20
class=3D048492323-17072006>&nbsp;</DIV>
<DIV><SPAN=20
class=3D048492323-17072006>&nbsp;</DIV>
<DIV><SPAN=20
class=3D048492323-17072006>&nbsp;</DIV>
<DIV><SPAN=20
class=3D048492323-17072006>&nbsp;</DIV>
<DIV><SPAN=20
class=3D048492323-17072006>&nbsp;</DIV>
<DIV><SPAN=20
class=3D048492323-17072006>&nbsp;</DIV>
<DIV><SPAN=20
class=3D048492323-17072006>&nbsp;</DIV>
<DIV><SPAN=20
class=3D048492323-17072006>&nbsp;</DIV>
<DIV><SPAN=20
class=3D048492323-17072006>&nbsp;</DIV>
<DIV><SPAN=20
class=3D048492323-17072006>&nbsp;</DIV>
<DIV><SPAN=20
class=3D048492323-17072006>&nbsp;</DIV>
<DIV><SPAN=20
class=3D048492323-17072006>&nbsp;</DIV>
<DIV><SPAN=20
class=3D048492323-17072006>&nbsp;</DIV>
<DIV><SPAN=20
class=3D048492323-17072006>&nbsp;</DIV>
<DIV><SPAN=20
class=3D048492323-17072006>&nbsp;&nbsp;</DIV>
<DIV><SPAN=20
class=3D048492323-17072006>&nbsp;</DIV>
<DIV><SPAN=20
class=3D048492323-17072006>&nbsp;</DIV>
<DIV><SPAN=20
class=3D048492323-17072006>&nbsp;</DIV>
<DIV><SPAN=20
class=3D048492323-17072006>&nbsp;</DIV>
<DIV><SPAN=20
class=3D048492323-17072006>&nbsp;</DIV>
<DIV><SPAN=20
class=3D048492323-17072006>&nbsp;</DIV>
<DIV><SPAN=20
class=3D048492323-17072006>&nbsp;</DIV>
<DIV><SPAN=20
class=3D048492323-17072006>&nbsp;<SPAN=20
class=3D048492323-17072006>&nbsp;</DIV></BODY></HTML>

------_=_NextPart_001_01C6AA94.FC1F4A82--

Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 18 Jul 2006 17:49:57 +0000
Message-ID: <44BD1F1D.2070004@us.fujitsu.com>
Date: Tue, 18 Jul 2006 10:49:17 -0700
From: Richard Rabbat <richard@us.fujitsu.com>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: Lucy Yong <lucyyong@huawei.com>
CC: ccamp@ops.ietf.org
Subject: Re: association object
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Lucy,
likewise. my comments inline.

Lucy Yong wrote:
>
> Richard,
>
>  
>
> It was nice to meet you in IETF meeting. I have a question about 
> association object used to associate the diversely routed LSPs.
>
>  
>
> If a LSP is established first, say LSP1, then another LSP (say LSP2) 
> needs to be established and be diversely routed from LSP1, how 
> association object is applied in this case? It is easy to use in the 
> latter LSP request, however, how does LSP1 know that it needs to 
> diverse from LSP2.
>
Lyndon covered the diversity issue and the fact that we are not doing 
path computation here, but I would like to add one more comment since 
I've got a similar question.  For LSP1 to be aware of the association, 
one can send a full PATH message with the added association object. this 
is neither a refresh message nor a new path setup message. all nodes 
will process that message and be aware of the new association object and 
hence LSP1 will from then on know about the association.
I hope this helps
Richard.

>  
>
> What is the relationship between this association object and diversity 
> object in GMPLS.
>
>  
>
> Best Regards,
>
> Lucy
>
>   
>

Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 18 Jul 2006 17:28:15 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6AA8F.2E8B883A"
Subject: RE: association object
Date: Tue, 18 Jul 2006 13:25:36 -0400
Message-ID: <0901D1988E815341A0103206A834DA07E7D531@mdmxm02.ciena.com>
Thread-Topic: association object
Thread-Index: AcaqdMAu71h2jF0ESMCbA6g/yiG4pQAGe8Hg
From: "Ong, Lyndon" <Lyong@Ciena.com>
To: "Lucy Yong" <lucyyong@huawei.com>, <richard@us.fujitsu.com>, <ccamp@ops.ietf.org>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6AA8F.2E8B883A
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Lucy,
=20
The association object is used to associate components of a VCG that are
already diversely routed in the draft, I would think diverse routing is
more a=20
feature of path computation than the signaling to set up the component.
=20
What the association object does is allow you to tell what LSPs arriving
at
the destination are part of the same VCG.
=20
Cheers,
=20
Lyndon

________________________________

From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On
Behalf Of Lucy Yong
Sent: Tuesday, July 18, 2006 7:16 AM
To: richard@us.fujitsu.com; ccamp@ops.ietf.org
Subject: association object

Richard,

=20

It was nice to meet you in IETF meeting. I have a question about
association object used to associate the diversely routed LSPs.=20

=20

If a LSP is established first, say LSP1, then another LSP (say LSP2)
needs to be established and be diversely routed from LSP1, how
association object is applied in this case? It is easy to use in the
latter LSP request, however, how does LSP1 know that it needs to diverse
from LSP2.

=20

What is the relationship between this association object and diversity
object in GMPLS.

=20

Best Regards,

Lucy

 =20

------_=_NextPart_001_01C6AA8F.2E8B883A
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:o =3D=20
"urn:schemas-microsoft-com:office:office" xmlns:w =3D=20
"urn:schemas-microsoft-com:office:word"><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.2912" name=3DGENERATOR>
<STYLE>@font-face {
	font-family: Courier;
}
@font-face {
	font-family: SimSun;
}
@font-face {
	font-family: SimSun;
}
@page Section1 {size: 8.5in 11.0in; margin: 1.0in 1.25in 1.0in 1.25in; }
P.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
LI.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
DIV.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline
}
A:visited {
	COLOR: purple; TEXT-DECORATION: underline
}
SPAN.MsoHyperlinkFollowed {
	COLOR: purple; TEXT-DECORATION: underline
}
SPAN.EmailStyle17 {
	FONT-WEIGHT: normal; COLOR: windowtext; FONT-STYLE: normal; =
FONT-FAMILY: Courier; TEXT-DECORATION: none; mso-style-type: =
personal-compose
}
DIV.Section1 {
	page: Section1
}
</STYLE>
</HEAD>
<BODY lang=3DEN-US vLink=3Dpurple link=3Dblue>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D802022217-18072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Hi Lucy,</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D802022217-18072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D802022217-18072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>The association object is used to associate =
components of a=20
VCG that are</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D802022217-18072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>already diversely routed in the draft, I would =
think=20
diverse routing is more a </FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D802022217-18072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>feature of path computation than the signaling =
to set up=20
the component.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D802022217-18072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D802022217-18072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>What the association object does is allow you =
to tell what=20
LSPs arriving at</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D802022217-18072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>the destination are part of the same=20
VCG.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D802022217-18072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D802022217-18072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Cheers,</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D802022217-18072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D802022217-18072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Lyndon</FONT></SPAN></DIV><BR>
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
<HR tabIndex=3D-1>
<FONT face=3DTahoma size=3D2><B>From:</B> owner-ccamp@ops.ietf.org=20
[mailto:owner-ccamp@ops.ietf.org] <B>On Behalf Of </B>Lucy =
Yong<BR><B>Sent:</B>=20
Tuesday, July 18, 2006 7:16 AM<BR><B>To:</B> richard@us.fujitsu.com;=20
ccamp@ops.ietf.org<BR><B>Subject:</B> association =
object<BR></FONT><BR></DIV>
<DIV></DIV>
<DIV class=3DSection1>
<P class=3DMsoNormal><FONT face=3DCourier size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Courier">Richard,<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DCourier size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Courier"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DCourier size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Courier">It was nice to meet you =
in IETF=20
meeting. I have a question about association object used to associate =
the=20
diversely routed LSPs. <o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DCourier size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Courier"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DCourier size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Courier">If a LSP is established =
first, say=20
LSP1, then another LSP (say LSP2) needs to be established and be =
diversely=20
routed from LSP1, how association object is applied in this case? It is =
easy to=20
use in the latter LSP request, however, how does LSP1 know that it needs =
to=20
diverse from LSP2.<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DCourier size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Courier"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DCourier size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Courier">What is the relationship =
between=20
this association object and diversity object in=20
GMPLS.<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DCourier size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Courier"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DCourier size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Courier">Best=20
Regards,<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DCourier size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Courier">Lucy<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DCourier size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Courier">&nbsp;&nbsp;<o:p></o:p></SPAN></FONT></P></DIV></BODY></HTML>

------_=_NextPart_001_01C6AA8F.2E8B883A--

Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 18 Jul 2006 14:18:28 +0000
Date: Tue, 18 Jul 2006 09:16:24 -0500
From: Lucy Yong <lucyyong@huawei.com>
Subject: association object
To: richard@us.fujitsu.com, ccamp@ops.ietf.org
Message-id: <009b01c6aa74$c3a13c90$a5087c0a@china.huawei.com>
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_9mY2g3HeUzEEwZR+zoLINQ)"
Thread-index: AcaqdMAu71h2jF0ESMCbA6g/yiG4pQ==

This is a multi-part message in MIME format.

--Boundary_(ID_9mY2g3HeUzEEwZR+zoLINQ)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT

Richard,

It was nice to meet you in IETF meeting. I have a question about association
object used to associate the diversely routed LSPs. 

If a LSP is established first, say LSP1, then another LSP (say LSP2) needs
to be established and be diversely routed from LSP1, how association object
is applied in this case? It is easy to use in the latter LSP request,
however, how does LSP1 know that it needs to diverse from LSP2.

What is the relationship between this association object and diversity
object in GMPLS.

Best Regards,

Lucy

--Boundary_(ID_9mY2g3HeUzEEwZR+zoLINQ)
Content-type: text/html; charset=us-ascii
Content-transfer-encoding: 7BIT

<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns="http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 11 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Courier;
	panose-1:2 7 4 9 2 2 5 2 4 4;}
@font-face
	{font-family:SimSun;

	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:Courier;
	color:windowtext;
	font-weight:normal;
	font-style:normal;
	text-decoration:none none;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=EN-US link=blue vlink=purple>

<div class=Section1>

<p class=MsoNormal><font size=2 face=Courier><span style='font-size:10.0pt;
font-family:Courier'>Richard,<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 face=Courier><span style='font-size:10.0pt;
font-family:Courier'><o:p>&nbsp;</o:p></span></font></p>

It was nice to meet you in IETF meeting. I have a question
about association object used to associate the diversely routed LSPs. <o:p></o:p>

<p class=MsoNormal><font size=2 face=Courier><span style='font-size:10.0pt;
font-family:Courier'><o:p>&nbsp;</o:p></span></font></p>

If a LSP is established first, say LSP1, then another LSP
(say LSP2) needs to be established and be diversely routed from LSP1, how
association object is applied in this case? It is easy to use in the latter LSP
request, however, how does LSP1 know that it needs to diverse from LSP2.<o:p></o:p>

<p class=MsoNormal><font size=2 face=Courier><span style='font-size:10.0pt;
font-family:Courier'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 face=Courier><span style='font-size:10.0pt;
font-family:Courier'>What is the relationship between this association object
and diversity object in GMPLS.<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 face=Courier><span style='font-size:10.0pt;
font-family:Courier'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 face=Courier><span style='font-size:10.0pt;
font-family:Courier'>Best Regards,<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 face=Courier><span style='font-size:10.0pt;
font-family:Courier'>Lucy<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 face=Courier><span style='font-size:10.0pt;
font-family:Courier'>&nbsp;&nbsp;<o:p></o:p></span></font></p>

</div>

</body>

</html>

--Boundary_(ID_9mY2g3HeUzEEwZR+zoLINQ)--

Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 18 Jul 2006 01:54:56 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: VLAN label range requirement
Date: Mon, 17 Jul 2006 21:53:41 -0400
Message-ID: <29D15BBCA340DA4D8146D38B4924FC7A074831B0@zcarhxm0.corp.nortel.com>
Thread-Topic: VLAN label range requirement
Thread-Index: Acalusf3c+VL76ogRtiZfGdQ6MooRAEUbswA
From: "Stephen Shew" <sdshew@nortel.com>
To: <ccamp@ops.ietf.org>

The size of the range has more to do with the total number of VLANs that
have to be mapped.  In theory, all 1024 could be mapped (between client
and network at the UNI) and also in the other direction.  Further, the
mapping at the egress UNI has to be carried (again for both directions),
so the max size could be 4k.

-----Original Message-----
From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com]=20
Sent: July 12, 2006 09:53
To: Ong, Lyndon
Cc: dimitri.papadimitriou@alcatel.be; Shew, Stephen (CAR:Q840); Adrian
Farrel; ccamp@ops.ietf.org
Subject: Re: VLAN label range requirement

lyndon

- not sure to understand - the information part of the liaison question
was "how large is large" ?

eg. RFC 3946 support VC4-256v did you ever ask the question whether we
have an efficient encoding ?

Ong, Lyndon wrote:

> Sure, I understand.  I think the concern that was expressed at the
last
> OIF
> meeting was whether we might need to define an efficient way of
> describing
> a set consisting of a very large set of labels, since the range of
VLAN
> tags,
> for example, is quite a bit larger than the typical set of labels
> assumed for
> optical switches.  If OIF comes up with=20
> any proposals along those lines, it would then liaise this to CCAMP
for
> its
> consideration.
>=20
> Cheers,
>=20
> Lyndon=20
>=20
> -----Original Message-----
> From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com]=20
> Sent: Wednesday, July 12, 2006 6:33 AM
> To: Ong, Lyndon
> Cc: Stephen Shew; Adrian Farrel; ccamp@ops.ietf.org
> Subject: Re: VLAN label range requirement
>=20
> lyndon -
>=20
> listing a set of labels as part of the response is something already
> covered in GMPLS
>=20
> hence if i well understand the MEF.10 document the information
elements
> that needs to be considered is quite straightforward
>=20
> so do we need this loop back and forth ? why not just produce a 2 page
> doc and close this ?
>=20
> thx,
> - d.
>=20
> Ong, Lyndon wrote:
>=20
>=20
>>That was my interpretation also, not sure if that came through on the=20
>>slides.
>>
>>Lyndon
>>
>>-----Original Message-----
>>From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On=20
>>Behalf Of Stephen Shew
>>Sent: Tuesday, July 11, 2006 8:09 PM
>>To: Adrian Farrel; ccamp@ops.ietf.org
>>Subject: RE: VLAN label range requirement
>>
>>You're welcome.
>>
>>The response from CCAMP on this question is very thorough, and I=20
>>certainly appreciate the thought that went into it.  My interpretation
>=20
>=20
>>of the response is that that CCAMP encourages the OIF to design an=20
>>encoding for the VLAN identifiers, and communicate it back to CCAMP.
>>
>>Stephen
>>
>>-----Original Message-----
>>From: Adrian Farrel [mailto:adrian@olddog.co.uk]
>>Sent: July 11, 2006 18:42
>>To: Shew, Stephen (CAR:Q840); ccamp@ops.ietf.org
>>Subject: Re: VLAN label range requirement
>>
>>Thanks Stephen.
>>
>>What is your opinion of the response to this question that CCAMP=20
>>supplied in its return communication to the OIF?
>>
>>Adrian
>>----- Original Message -----
>>From: "Stephen Shew" <sdshew@nortel.com>
>>To: <ccamp@ops.ietf.org>
>>Sent: Tuesday, July 11, 2006 4:44 PM
>>Subject: VLAN label range requirement
>>
>>
>>In yesterday's meeting, there was a request for more information on=20
>>the VLAN label range requirement.  From the original OIF liaison, the=20
>>description was:
>>"We are investigating label formats to represent a list or range of=20
>>VLAN identifiers, as used in MEF.11 bundling. In the case where a=20
>>large number of non-consecutive VLAN identifiers is used for the same=20
>>connection, we would like to keep the label to a reasonable size."
>>
>>The requirement to send a range of VLAN identifiers in signalling=20
>>arises in the bundling feature in Ethernet services as specified in=20
>>Metro Ethernet Forum (MEF) and ITU-T SG15 documents.  In the MEF, the=20
>>MEF.11 spec "User Network Interface (UNI) Requirements and Framework"=20
>>there is a UNI service attribute called "bundling" that is described=20
>>as "A UNI attribute in which more than one CE-VLAN ID is associated
>=20
> with an EVC."
>=20
>>It is more fully described in MEF.10 "Ethernet Services Attributes=20
>>Phase 1".  Both technical specs may be obtained free at:
>>http://www.metroethernetforum.org/TechSpec.htm
>>
>>Equivalent ITU-T Recs. are G.8011, G8011.1, and G.8011.2.  These are=20
>>available to ITU-T members, or under a "3 free" capability on the=20
>>ITU-T website.
>>
>>Of interest is the MEF Ethernet Link Management Interface (E-LMI)=20
>>defined in MEF.16 that has an encoding for passing VLAN ranges between
>=20
>=20
>>the UNI client and network.  This in a structure called the "CE-VLAN=20
>>ID/EVC Map information element".
>>
>>I hope this provides more clarity to the VLAN label range issue.
>>
>>Stephen Shew
>>Metro Ethernet Networks
>>Nortel
>>sdshew@nortel.com
>>Telephone: +1 613 763 2462 / ESN 393 2462
>>
>>
>>
>>
>>.
>>
>=20
>=20
> .
>=20

Envelope-to: ccamp-data@psg.com
Delivery-date: Mon, 17 Jul 2006 20:52:44 +0000
Reply-To: "CHO, JAI HYUNG" <jaihyung@etri.re.kr>
From: "CHO, JAI HYUNG" <jaihyung@etri.re.kr>
To: "Adrian Farrel" <adrian@olddog.co.uk>, <ccamp@ops.ietf.org>, <gels@rtg.ietf.org>
Cc: 
Bcc: 
thread-index: Acap4EuvXB57YnxxT8yFg5CeeEQr9QAAvkHz
Date: Tue, 18 Jul 2006 05:55:00 +0900
Thread-Topic: Next steps for GMPLS control of Ethernet
Message-ID: <013c01c6a9e3$44b8f440$8310fe81@etri.info>
Subject: RE: Next steps for GMPLS control of Ethernet
Comment: GQ19@|@ZEk=E?,18?x, D38.>n@L4u3]?,18F@, 4c4g
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Class: urn:content-classes:message

This is great and fair decision to everybody. 
I welcome and support this decision. 

Thank you Adrian and Debora. 

Jaihyung 

Dr. Jaihyung Cho 
ETRI, Korea 
phone :       042) 860-5514 
oversea: +82-42-860-5514 
fax:         +82-42-861-5550 

-----?? ???----- 
?? ??: "Adrian Farrel" <adrian@olddog.co.uk> 
?? ??: 2006-07-18 ?? 3:24:34 
?? ??: "ccamp@ops.ietf.org" <ccamp@ops.ietf.org>, "gels@rtg.ietf.org" <gels@rtg.ietf.org> 
??: "Ross Callon" <rcallon@juniper.net>, "Dimitri Papadimitriou" <Dimitri.Papadimitriou@alcatel.be>, "Brungard, Deborah A, ALABS" <dbrungard@att.com>, "fenner@rearch.att.com" <fenner@rearch.att.com>, "Loa Andersson" <loa@pi.se> 
??: Next steps for GMPLS control of Ethernet 

Hi CCAMPers and GELSters, 

In CCAMP this time we explained the discussions and agreements that the 
chairs had with the ADs with respect to the way forward for developing 
GMPLS extensions and procedures for the control of Ethernet devices. 
This email is to clarify the explanation and to give a base reference for 
the procedures that we expect to be followed. 

- Work on procedures and extensions to GMPLS for the control 
of Ethernet devices will be done in CCAMP. 

- This work is already covered by the CCAMP charter... 
    The CCAMP working group coordinates the work within the 
    IETF defining a common control plane and a separate common 
    measurement plane for physical path and core tunneling 
    technologies of Internet and telecom service providers (ISPs 
    and SPs) 
However, if necessary, and if work is forthcoming, we will consider 
adding a specific work item an milestones to the charter. Such a 
charter change is not gating on this work, but may be useful for 
clarity and exposure of the work outside of CCAMP. 

- Data plane specification is out of scope for the IETF. It must not 
be discussed on the CCAMP list. It may be discussed on the 
GELS list. 

- CCAMP will not work on the specification of GMPLS except for 
data planes that are already approved by an SDO with responsibility 
for the Ethernet data plane. It is expected that the primary SDO 
in this case is IEEE. 

We expect that you would use the following steps in order. 

1. Decide upon the data plane behavior you wish to control 

2. Ensure that the data plane you wish to control is approved 
and documented by an SDO with responsibility for Ethernet 
(e.g. IEEE). 
This may be a null op in the case of existing standards, but 
might require you to do work in the other SDO for new 
standards for profiles of existing standards. 

3. Start protocol work in CCAMP with an explicit pointer 
to the approved data plane. If you feel the need to explain 
your data plane in your I-D, then there is probably something 
wrong with the specification in the other SDO and you 
should return to step 2. 

4. When it is clear that protocol work is progressing, 
Deborah and I will liaise with the other SDO to get their 
blessing for using a control plane for the nominated data 
plane. 

Note that this procedure can apply to multiple data planes at the same 
time or separately, but we expect that the protocol encoding 
extensions will be flexible to all data planes. 

Hope this is clear, 
Adrian and Deborah 

Envelope-to: ccamp-data@psg.com
Delivery-date: Mon, 17 Jul 2006 18:26:44 +0000
Message-ID: <02d401c6a9ce$56febcd0$851fdb84@your029b8cecfe>
Reply-To: "Adrian Farrel" <adrian@olddog.co.uk>
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: <ccamp@ops.ietf.org>, <gels@rtg.ietf.org>
Cc: "Ross Callon" <rcallon@juniper.net>, <fenner@rearch.att.com>, "Brungard, Deborah A, ALABS" <dbrungard@att.com>, "Dimitri Papadimitriou" <Dimitri.Papadimitriou@alcatel.be>, "Loa Andersson" <loa@pi.se>
Subject: Next steps for GMPLS control of Ethernet
Date: Mon, 17 Jul 2006 19:24:34 +0100
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Hi CCAMPers and GELSters,

In CCAMP this time we explained the discussions and agreements that the 
chairs had with the ADs with respect to the way forward for developing
GMPLS extensions and procedures for the control of Ethernet devices. 
This email is to clarify the explanation and to give a base reference for 
the procedures that we expect to be followed.

- Work on procedures and extensions to GMPLS for the control
  of Ethernet devices will be done in CCAMP.

- This work is already covered by the CCAMP charter...
      The CCAMP working group coordinates the work within the
      IETF defining a common control plane and a separate common
      measurement plane for physical path and core tunneling
      technologies of Internet and telecom service providers (ISPs
      and SPs)
  However, if necessary, and if work is forthcoming, we will consider
  adding a specific work item an milestones to the charter. Such a
  charter change is not gating on this work, but may be useful for
  clarity and exposure of the work outside of CCAMP.

- Data plane specification is out of scope for the IETF. It must not
  be discussed on the CCAMP list. It may be discussed on the
  GELS list.

- CCAMP will not work on the specification of GMPLS except for
  data planes that are already approved by an SDO with responsibility
  for the Ethernet data plane. It is expected that the primary SDO
  in this case is IEEE.

We expect that you would use the following steps in order.

1. Decide upon the data plane behavior you wish to control

2. Ensure that the data plane you wish to control is approved
and documented by an SDO with responsibility for Ethernet
(e.g. IEEE).
This may be a null op in the case of existing standards, but
might require you to do work in the other SDO for new
standards for profiles of existing standards.

3. Start protocol work in CCAMP with an explicit pointer
to the approved data plane. If you feel the need to explain
your data plane in your I-D, then there is probably something
wrong with the specification in the other SDO and you
should return to step 2.

4. When it is clear that protocol work is progressing,
Deborah and I will liaise with the other SDO to get their
blessing for using a control plane for the nominated data
plane.

Note that this procedure can apply to multiple data planes at the same
time or separately, but we expect that the protocol encoding 
extensions will be flexible to all data planes.

Hope this is clear,
Adrian and Deborah 

Envelope-to: ccamp-data@psg.com
Delivery-date: Mon, 17 Jul 2006 10:20:19 +0000
To: Freek Dijkstra <fdijkstr@science.uva.nl>
Cc: ccamp@ops.ietf.org
Subject: Re: Ethernet interface in a TDM device: FSC, TDM, or L2SC?
MIME-Version: 1.0
Message-ID: <OF69303EF1.98F4EECD-ONC12571AE.0037A0AC-C12571AE.0038C8D7@netfr.alcatel.fr>
From: Dimitri.Papadimitriou@alcatel.be
Date: Mon, 17 Jul 2006 12:20:12 +0200
Content-Type: text/plain; charset="US-ASCII"

hi -

from your drawing, i/f B: TDM and i/f A: L2SC with Ethernet port mode - 
not frame mode - in the port mode case for i/f A the Max = Min LSP 
bandwidth = port capacity 

note: your device is combining the two interfaces i initially describes

the reference i provided allows to link capacities between interfaces (i/f 
A with i/f B) see IACD sub-TLV section

<http://www.ietf.org/internet-drafts/draft-papadimitriou-ccamp-gmpls-mrn-extensions-02.txt>

thanks,
- d.

Freek Dijkstra <fdijkstr@science.uva.nl>
Sent by: owner-ccamp@ops.ietf.org
17/07/2006 12:05

        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     ccamp@ops.ietf.org
        Subject:        Re: Ethernet interface in a TDM device: FSC, TDM, 
or L2SC?

Hi Dimitri,

Thanks for your insights.

> in your case your interface knows about processing payload of the TDM 
LSP, 
> hence the point is if you put such i/f  back to back 
> 
> o) do you switch the STS -> TDM LSP with TDM encoding and TDM ST 
> 
> o) do you switch the whole Ethernet packet flow from port-to-port (no 
> granularity from the Ethernet header info) -> Ethernet LSP with TDM 
> Encoding and L2SC

Neither. The link between two of these kind of interfaces will be pure
Ethernet, no TDM encoding.

Let me make a drawing here.

    Gigabit     +------------+     Gigabit
   Ethernet     |            |     Ethernet in
 ---------------o TDM switch o----------------------
     in UTP   A |            | B   STS-24c in OC-192
                +------------+

My question concerned interface A in the above drawing. It seems that
your descriptions concern interface B instead.

In this case all bytes from interface A are adapted in 24 STS channels,
which are then adapted to the OC-192 of interface B. I can imagine three
lines of reasoning:

* Interface A announces LSC with Ethernet encoding. After all, it does
not look into the headers, and also does no do the TDM encoding (that
happens at interface B)

* Interface A announces TDM ST with Ethernet encoding. After all, it
will embed the Ethernet packets in STS, so it knows about TDM switching.

* Interface A announces L2SC with Ethernet encoding. That seems
incorrect; while the interfaces will probably know about frame
bounderies, it does not process the header.

I assume the first or second is correct.

> ps: if you take such flow from another interface and have limited 
capacity 
> i suggest you take a look at the mln/mln solution doc where you can link 

> such capacities

Do you have a reference?

Regards,
Freek

Envelope-to: ccamp-data@psg.com
Delivery-date: Mon, 17 Jul 2006 10:05:58 +0000
Message-ID: <44BB60F1.3030906@science.uva.nl>
Date: Mon, 17 Jul 2006 12:05:37 +0200
From: Freek Dijkstra <fdijkstr@science.uva.nl>
User-Agent: Mail/News 1.5.0.2 (Macintosh/20060401)
MIME-Version: 1.0
To: Dimitri.Papadimitriou@alcatel.be
Cc: ccamp@ops.ietf.org
Subject: Re: Ethernet interface in a TDM device: FSC, TDM, or L2SC?
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Hi Dimitri,

Thanks for your insights.

> in your case your interface knows about processing payload of the TDM LSP, 
> hence the point is if you put such i/f  back to back 
> 
> o) do you switch the STS -> TDM LSP with TDM encoding and TDM ST 
> 
> o) do you switch the whole Ethernet packet flow from port-to-port (no 
> granularity from the Ethernet header info) -> Ethernet LSP with TDM 
> Encoding and L2SC

Neither. The link between two of these kind of interfaces will be pure
Ethernet, no TDM encoding.

Let me make a drawing here.

    Gigabit     +------------+     Gigabit
   Ethernet     |            |     Ethernet in
 ---------------o TDM switch o----------------------
     in UTP   A |            | B   STS-24c in OC-192
                +------------+

My question concerned interface A in the above drawing. It seems that
your descriptions concern interface B instead.

In this case all bytes from interface A are adapted in 24 STS channels,
which are then adapted to the OC-192 of interface B. I can imagine three
lines of reasoning:

* Interface A announces LSC with Ethernet encoding. After all, it does
not look into the headers, and also does no do the TDM encoding (that
happens at interface B)

* Interface A announces TDM ST with Ethernet encoding. After all, it
will embed the Ethernet packets in STS, so it knows about TDM switching.

* Interface A announces L2SC with Ethernet encoding. That seems
incorrect; while the interfaces will probably know about frame
bounderies, it does not process the header.

I assume the first or second is correct.

> ps: if you take such flow from another interface and have limited capacity 
> i suggest you take a look at the mln/mln solution doc where you can link 
> such capacities

Do you have a reference?

Regards,
Freek

Envelope-to: ccamp-data@psg.com
Delivery-date: Mon, 17 Jul 2006 09:40:43 +0000
To: Freek Dijkstra <fdijkstr@science.uva.nl>
Cc: ccamp@ops.ietf.org
Subject: Re: Ethernet interface in a TDM device: FSC, TDM, or L2SC?
MIME-Version: 1.0
Message-ID: <OFCAF6947B.790D230D-ONC12571AE.0034655B-C12571AE.00352758@netfr.alcatel.fr>
From: Dimitri.Papadimitriou@alcatel.be
Date: Mon, 17 Jul 2006 11:40:33 +0200
Content-Type: text/plain; charset="US-ASCII"

hi - 

it can't be FSC as you don't switch in the spatial domain (FSC is for 
inst. used in the case of fiber distribution frames)

in your case your interface knows about processing payload of the TDM LSP, 
hence the point is if you put such i/f  back to back 

o) do you switch the STS -> TDM LSP with TDM encoding and TDM ST 

o) do you switch the whole Ethernet packet flow from port-to-port (no 
granularity from the Ethernet header info) -> Ethernet LSP with TDM 
Encoding and L2SC 

ps: if you take such flow from another interface and have limited capacity 
i suggest you take a look at the mln/mln solution doc where you can link 
such capacities

much thanks,
- dimitri.

Freek Dijkstra <fdijkstr@science.uva.nl>
Sent by: owner-ccamp@ops.ietf.org
17/07/2006 11:25

        To:     ccamp@ops.ietf.org
        cc: 
        Subject:        Ethernet interface in a TDM device: FSC, TDM, or 
L2SC?

Hi,

Another question.

I have a SONET cross connect. That is, a TDM device.
Most of the interfaces are TDM switch capable interfaces, which known
only about TDM encoding.

However, one of the interfaces of this devices knows about Ethernet
encoding, and is capable of taking the Ethernet packets and embed them
in a couple of STS channels (e.g. STC-24c or STS-3c-7v).

My question: what is the switching capability of this device?

It's not a L2SC, since it does not make decisions based on the MAC
addresses. I'm inclined to think it is also not a TDM switch capable
interface, since it does not switch based on time slots. All it does is
embed all data it encounters on the fiber. So it seems to me that this
interface is a Fiber-Switch capable (FSC) interface with Ethernet
encoding, despite that it is in a "TDM device".

Am I correct here?

Regards,
Freek

Envelope-to: ccamp-data@psg.com
Delivery-date: Mon, 17 Jul 2006 09:26:57 +0000
Message-ID: <44BB5775.1000801@science.uva.nl>
Date: Mon, 17 Jul 2006 11:25:09 +0200
From: Freek Dijkstra <fdijkstr@science.uva.nl>
User-Agent: Mail/News 1.5.0.2 (Macintosh/20060401)
MIME-Version: 1.0
To: ccamp@ops.ietf.org
Subject: Ethernet interface in a TDM device: FSC, TDM, or L2SC?
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Hi,

Another question.

I have a SONET cross connect. That is, a TDM device.
Most of the interfaces are TDM switch capable interfaces, which known
only about TDM encoding.

However, one of the interfaces of this devices knows about Ethernet
encoding, and is capable of taking the Ethernet packets and embed them
in a couple of STS channels (e.g. STC-24c or STS-3c-7v).

My question: what is the switching capability of this device?

It's not a L2SC, since it does not make decisions based on the MAC
addresses. I'm inclined to think it is also not a TDM switch capable
interface, since it does not switch based on time slots. All it does is
embed all data it encounters on the fiber. So it seems to me that this
interface is a Fiber-Switch capable (FSC) interface with Ethernet
encoding, despite that it is in a "TDM device".

Am I correct here?

Regards,
Freek

Envelope-to: ccamp-data@psg.com
Delivery-date: Fri, 14 Jul 2006 16:47:17 +0000
Message-ID: <009301c6a765$1ca049c0$851fdb84@your029b8cecfe>
Reply-To: "Adrian Farrel" <adrian@olddog.co.uk>
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: "Mack-Crane, T. Benjamin" <Ben.Mack-Crane@tellabs.com>, "Brungard, Deborah A, ALABS" <dbrungard@att.com>
Cc: <ccamp@ops.ietf.org>
Subject: Re: Working Group Last Call on draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt
Date: Fri, 14 Jul 2006 17:46:42 +0100
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Thanks Ben,

Thanks for providing the additional details on your previous questions. I 
think this now gives us something to answer and we will come back to you in 
a couple of days.

Adrian
----- Original Message ----- 
From: "Mack-Crane, T. Benjamin" <Ben.Mack-Crane@tellabs.com>
To: "Adrian Farrel" <adrian@olddog.co.uk>; "Brungard, Deborah A, ALABS" 
<dbrungard@att.com>
Cc: <ccamp@ops.ietf.org>
Sent: Friday, July 14, 2006 5:42 PM
Subject: RE: Working Group Last Call on 
draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt

Hi Adrian,

There were also these comments which have not been fully addressed
afaik:

> > 3)       The network models being used in section 4.3 and section 7
are
> > not clear.  In particular the relationships between the call
> > controllers, network boundaries, ingress/egress nodes, and
> > ingress/egress links are not clear.  Figures would be very helpful
here.
>
> Figures are always helpful, and usually (but not always) better than
> words.
>
> In order to be sure to clarify the network models that you are finding
> confusing, it would be helpful if you asked specific questions or
proposed
> text.

It is not clear how the form of initiation of a call affects the
information available about the egress link. In part this may be
affected by whether the ingress node is inside or outside the network
(IGP) boundary.  It would seem that the situation at the egress would
have something to do with this as well.  It is unclear where the egress
trail termination point is expected to be, e.g. inside or outside the
network boundary, and, if inside, at the near or far side of the egress
node's matrix.

> >5)       The call control mechanism defined appears to support
> > only IPv4 or IPv6 addressed endpoints from a single address
> > space.  Is this correct?
>
>  I don't think so.

I would be interested to know how to correctly understand the draft.
That is, what addressing other than IPv4/6 is supported, and how
multiple address spaces are supported.

Regards,
Ben

> -----Original Message-----
> From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On
Behalf
> Of Adrian Farrel
> Sent: Wednesday, July 12, 2006 2:54 PM
> To: Brungard, Deborah A, ALABS
> Cc: ccamp@ops.ietf.org
> Subject: Re: Working Group Last Call on
draft-ietf-ccamp-gmpls-rsvp-te-
> call-00.txt
>
> Hi,
>
> > The Working Group Last Call has closed on this document.
> >
> > Authors/editors please summarize the comments and document
> > how they will be addressed.
>
> Thanks Deborah, it's interesting to be on the receiving side for a
change
> :-)
>
> I noted the following comments during WG last call.
>
> 1. Desirability of liaison to ITU-T SG15 (Lyndon)
> Lyndon suggested that this I-D should be liaised to SG15 prior to
becoming
> an RFC to ensure that terminology is correct and that it meets the
> requirments for supporting ASON calls.
> Our response here is that:
> a. This I-D is not specifically targeted at satisfying RFC4139.
> b. An applicability statement will be produced describing how this and
>    other I-Ds/RFCs can be used to meet the requirements set out in
>    RFC4139. That work will definitely be liaised to the ITU-T.
> c. The terms used in this document are not specific to ASON, but
>    in general they have been taken from RFC4139 and RFC4397
>    both of which received substantial and useful review by SG15.
> No further action is planned by the authors.
>
> 2. Format of Long Call ID (Lyndon)
> Lyndon points out that a format for the long call ID has been defined
in
> G.7713.2 and suggests that this might be included by reference.
> The authors note that the format of an ASON call ID is defined in
several
> places (including G.7713.1 and G.7713.2), but the intention of the
draft
> is
> not to be limited to ASON applicability. Therefore other call ID
formats
> would also be supported, and the format is out of scope for the draft.
> An applicability statement will be produced describing how this and
other
> I-Ds/RFCs can be used to meet the requirements set out in RFC4139, and
> that
> will definitely include the encoding of ASON call IDs. That work will
be
> liaised to the ITU-T.
> No further action is planned by the authors.
>
> 3. Location of Short Call ID in Path message (Lyndon and Ben)
> Both Lyndon and Ben questioned the location of the short call ID in
the
> Session object.
> a. Impact of existing, non-conformant implementations
>    The draft currently describes the behavior if non-conformant
transit
>    LSRs react to the use of the previously reserved bits of the
Session
>    object. They might reject the Path message, or they might zero out
>    the short call ID.
>    Lyndon asked whether it might be better to use a separate object
>    to avoid this issue completely.
>    The authors had previously discussed this point at some length and
>    believe that protocol design should not be shaped by the possiblity
>    of dysfunctional implementations. Further, the use of a new object
>     might also cause problems with defective implementations.
>    The authors propose no changes to the I-D for this point, but will
>    send mail to the MPLS mailing list to check that the 'owners' of
>    RSVP-TE have no issue with this use of a previkously reserved
>    field.
> b. Illogicality of use of Session object
>     Ben and Lyndon expressed the view that it would be more
>     logical to place the short call ID in a new object than to
>     complicate the concept of the Session. The possibility of
>     using the Association object was also raised.
>     The authors had discussed this at some length over the
>     last two years that the I-D has been in production, and
>     recently on the mailing list. Our conclusion is that:
>     i. The Association object is for associating LSPs with
>        each other. The call ID is used to associate LSPs
>        with a call.
>     ii. A separate object would be perfectly functional.
>     iii. There is already some logical association between the
>        session and the LSPs in the call, and it makes sense to
>        extend this.
>     iv. The key on the Notify message is the session.
>     v. The current I-D is also perfectly functional, and has been
>         successfully implemented.
> Given that no specific draw-back to the current encoding has been put
> forward except for a feeling of illogicality among some readers, the
> authors
> propose no further action except for polling the MPLS WG as described
> above.
>
> 4. Procedures for including LINK_CAPABILITIES object
> A comment was made that this appears to be totally optional without
any
> defined procedures for how an LSR should decide wheter to include the
> object.
> The authors agree with this view, and it is intentional. The draft
> states...
>    The LINK CAPABILITY object is introduced to support link capability
>    exchange during Call setup and MAY be included in a Notify message
>    used for Call setup. This optional object includes the bundled link
>    local capabilities of the Call initiating node (or terminating
node)
>    indicated by the source address of the Notify message.
> This text makes it quite clear that the object is completely optional.
> The authors propose to make no changes for this point.
>
> 5. Question about processing rules in section 6.2.1
> There was a detailed quesiton about the procedure in seciton 6.2.1.
> The authors believe that this was answered and concluded on the
mailing
> list.
> The authors propose to make no changes for this point.
>
> 6. Refresh Notify
> Lyndon asked whether the refresh of the Notify message is really
necessary
> if there are active LSPs in the call?  Possibly the LSP refresh
> could be sufficient, since this carries the short Call ID. He also
asked
> if it possible that the call would be dropped while there are still
> active LSPs.
> The authors consider that you cannot infer the status of the call when
> there
> are no connections on the call. They believe that a single mechanism
> should be used to monitor the call status in all circumstances.
> The draft describes refresh failure of calls when connections already
> exist
> in section 6.7.
>
>
> In short, we propose to make no changes to the document as a result of
WG
> last call. We will notify the MPLS WG as described above.
>
> Can this I-D now move on the ADs?
>
> Thanks,
> Adrian
>
============================================================
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
============================================================

Envelope-to: ccamp-data@psg.com
Delivery-date: Fri, 14 Jul 2006 16:44:21 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: Working Group Last Call on draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt
Date: Fri, 14 Jul 2006 11:42:32 -0500
Message-ID: <A1A52203CA93634BA1748887B9993AEA02EF539E@USNVEX1.tellabs-west.tellabsinc.net>
Thread-Topic: Working Group Last Call on draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt
Thread-Index: Acal7QycniWFvH3/SkG33P44WdPzUABdQFMA
From: "Mack-Crane, T. Benjamin" <Ben.Mack-Crane@tellabs.com>
To: "Adrian Farrel" <adrian@olddog.co.uk>, "Brungard, Deborah A, ALABS" <dbrungard@att.com>
Cc: <ccamp@ops.ietf.org>
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="us-ascii"

Hi Adrian,

There were also these comments which have not been fully addressed
afaik:

> > 3)       The network models being used in section 4.3 and section 7
are
> > not clear.  In particular the relationships between the call
> > controllers, network boundaries, ingress/egress nodes, and
> > ingress/egress links are not clear.  Figures would be very helpful
here.
>=20
> Figures are always helpful, and usually (but not always) better than
> words.
>=20
> In order to be sure to clarify the network models that you are finding
> confusing, it would be helpful if you asked specific questions or
proposed
> text.

It is not clear how the form of initiation of a call affects the
information available about the egress link. In part this may be
affected by whether the ingress node is inside or outside the network
(IGP) boundary.  It would seem that the situation at the egress would
have something to do with this as well.  It is unclear where the egress
trail termination point is expected to be, e.g. inside or outside the
network boundary, and, if inside, at the near or far side of the egress
node's matrix.

> >5)       The call control mechanism defined appears to support
> > only IPv4 or IPv6 addressed endpoints from a single address
> > space.  Is this correct?
>=20
>  I don't think so.

I would be interested to know how to correctly understand the draft.
That is, what addressing other than IPv4/6 is supported, and how
multiple address spaces are supported.

Regards,
Ben

> -----Original Message-----
> From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On
Behalf
> Of Adrian Farrel
> Sent: Wednesday, July 12, 2006 2:54 PM
> To: Brungard, Deborah A, ALABS
> Cc: ccamp@ops.ietf.org
> Subject: Re: Working Group Last Call on
draft-ietf-ccamp-gmpls-rsvp-te-
> call-00.txt
>=20
> Hi,
>=20
> > The Working Group Last Call has closed on this document.
> >
> > Authors/editors please summarize the comments and document
> > how they will be addressed.
>=20
> Thanks Deborah, it's interesting to be on the receiving side for a
change
> :-)
>=20
> I noted the following comments during WG last call.
>=20
> 1. Desirability of liaison to ITU-T SG15 (Lyndon)
> Lyndon suggested that this I-D should be liaised to SG15 prior to
becoming
> an RFC to ensure that terminology is correct and that it meets the
> requirments for supporting ASON calls.
> Our response here is that:
> a. This I-D is not specifically targeted at satisfying RFC4139.
> b. An applicability statement will be produced describing how this and
>    other I-Ds/RFCs can be used to meet the requirements set out in
>    RFC4139. That work will definitely be liaised to the ITU-T.
> c. The terms used in this document are not specific to ASON, but
>    in general they have been taken from RFC4139 and RFC4397
>    both of which received substantial and useful review by SG15.
> No further action is planned by the authors.
>=20
> 2. Format of Long Call ID (Lyndon)
> Lyndon points out that a format for the long call ID has been defined
in
> G.7713.2 and suggests that this might be included by reference.
> The authors note that the format of an ASON call ID is defined in
several
> places (including G.7713.1 and G.7713.2), but the intention of the
draft
> is
> not to be limited to ASON applicability. Therefore other call ID
formats
> would also be supported, and the format is out of scope for the draft.
> An applicability statement will be produced describing how this and
other
> I-Ds/RFCs can be used to meet the requirements set out in RFC4139, and
> that
> will definitely include the encoding of ASON call IDs. That work will
be
> liaised to the ITU-T.
> No further action is planned by the authors.
>=20
> 3. Location of Short Call ID in Path message (Lyndon and Ben)
> Both Lyndon and Ben questioned the location of the short call ID in
the
> Session object.
> a. Impact of existing, non-conformant implementations
>    The draft currently describes the behavior if non-conformant
transit
>    LSRs react to the use of the previously reserved bits of the
Session
>    object. They might reject the Path message, or they might zero out
>    the short call ID.
>    Lyndon asked whether it might be better to use a separate object
>    to avoid this issue completely.
>    The authors had previously discussed this point at some length and
>    believe that protocol design should not be shaped by the possiblity
>    of dysfunctional implementations. Further, the use of a new object
>     might also cause problems with defective implementations.
>    The authors propose no changes to the I-D for this point, but will
>    send mail to the MPLS mailing list to check that the 'owners' of
>    RSVP-TE have no issue with this use of a previkously reserved
>    field.
> b. Illogicality of use of Session object
>     Ben and Lyndon expressed the view that it would be more
>     logical to place the short call ID in a new object than to
>     complicate the concept of the Session. The possibility of
>     using the Association object was also raised.
>     The authors had discussed this at some length over the
>     last two years that the I-D has been in production, and
>     recently on the mailing list. Our conclusion is that:
>     i. The Association object is for associating LSPs with
>        each other. The call ID is used to associate LSPs
>        with a call.
>     ii. A separate object would be perfectly functional.
>     iii. There is already some logical association between the
>        session and the LSPs in the call, and it makes sense to
>        extend this.
>     iv. The key on the Notify message is the session.
>     v. The current I-D is also perfectly functional, and has been
>         successfully implemented.
> Given that no specific draw-back to the current encoding has been put
> forward except for a feeling of illogicality among some readers, the
> authors
> propose no further action except for polling the MPLS WG as described
> above.
>=20
> 4. Procedures for including LINK_CAPABILITIES object
> A comment was made that this appears to be totally optional without
any
> defined procedures for how an LSR should decide wheter to include the
> object.
> The authors agree with this view, and it is intentional. The draft
> states...
>    The LINK CAPABILITY object is introduced to support link capability
>    exchange during Call setup and MAY be included in a Notify message
>    used for Call setup. This optional object includes the bundled link
>    local capabilities of the Call initiating node (or terminating
node)
>    indicated by the source address of the Notify message.
> This text makes it quite clear that the object is completely optional.
> The authors propose to make no changes for this point.
>=20
> 5. Question about processing rules in section 6.2.1
> There was a detailed quesiton about the procedure in seciton 6.2.1.
> The authors believe that this was answered and concluded on the
mailing
> list.
> The authors propose to make no changes for this point.
>=20
> 6. Refresh Notify
> Lyndon asked whether the refresh of the Notify message is really
necessary
> if there are active LSPs in the call?  Possibly the LSP refresh
> could be sufficient, since this carries the short Call ID. He also
asked
> if it possible that the call would be dropped while there are still
> active LSPs.
> The authors consider that you cannot infer the status of the call when
> there
> are no connections on the call. They believe that a single mechanism
> should be used to monitor the call status in all circumstances.
> The draft describes refresh failure of calls when connections already
> exist
> in section 6.7.
>=20
>=20
> In short, we propose to make no changes to the document as a result of
WG
> last call. We will notify the MPLS WG as described above.
>=20
> Can this I-D now move on the ADs?
>=20
> Thanks,
> Adrian
>=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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

Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 12 Jul 2006 19:54:41 +0000
Message-ID: <063e01c6a5ec$fa4d4270$e90ddb84@your029b8cecfe>
Reply-To: "Adrian Farrel" <adrian@olddog.co.uk>
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: "Brungard, Deborah A, ALABS" <dbrungard@att.com>
Cc: <ccamp@ops.ietf.org>
Subject: Re: Working Group Last Call on draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt
Date: Wed, 12 Jul 2006 20:53:46 +0100
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Hi,

> The Working Group Last Call has closed on this document.
>
> Authors/editors please summarize the comments and document
> how they will be addressed.

Thanks Deborah, it's interesting to be on the receiving side for a change
:-)

I noted the following comments during WG last call.

1. Desirability of liaison to ITU-T SG15 (Lyndon)
Lyndon suggested that this I-D should be liaised to SG15 prior to becoming
an RFC to ensure that terminology is correct and that it meets the
requirments for supporting ASON calls.
Our response here is that:
a. This I-D is not specifically targeted at satisfying RFC4139.
b. An applicability statement will be produced describing how this and
   other I-Ds/RFCs can be used to meet the requirements set out in
   RFC4139. That work will definitely be liaised to the ITU-T.
c. The terms used in this document are not specific to ASON, but
   in general they have been taken from RFC4139 and RFC4397
   both of which received substantial and useful review by SG15.
No further action is planned by the authors.

2. Format of Long Call ID (Lyndon)
Lyndon points out that a format for the long call ID has been defined in
G.7713.2 and suggests that this might be included by reference.
The authors note that the format of an ASON call ID is defined in several
places (including G.7713.1 and G.7713.2), but the intention of the draft is
not to be limited to ASON applicability. Therefore other call ID formats
would also be supported, and the format is out of scope for the draft.
An applicability statement will be produced describing how this and other
I-Ds/RFCs can be used to meet the requirements set out in RFC4139, and that
will definitely include the encoding of ASON call IDs. That work will be
liaised to the ITU-T.
No further action is planned by the authors.

3. Location of Short Call ID in Path message (Lyndon and Ben)
Both Lyndon and Ben questioned the location of the short call ID in the
Session object.
a. Impact of existing, non-conformant implementations
   The draft currently describes the behavior if non-conformant transit
   LSRs react to the use of the previously reserved bits of the Session
   object. They might reject the Path message, or they might zero out
   the short call ID.
   Lyndon asked whether it might be better to use a separate object
   to avoid this issue completely.
   The authors had previously discussed this point at some length and
   believe that protocol design should not be shaped by the possiblity
   of dysfunctional implementations. Further, the use of a new object
    might also cause problems with defective implementations.
   The authors propose no changes to the I-D for this point, but will
   send mail to the MPLS mailing list to check that the 'owners' of
   RSVP-TE have no issue with this use of a previkously reserved
   field.
b. Illogicality of use of Session object
    Ben and Lyndon expressed the view that it would be more
    logical to place the short call ID in a new object than to
    complicate the concept of the Session. The possibility of
    using the Association object was also raised.
    The authors had discussed this at some length over the
    last two years that the I-D has been in production, and
    recently on the mailing list. Our conclusion is that:
    i. The Association object is for associating LSPs with
       each other. The call ID is used to associate LSPs
       with a call.
    ii. A separate object would be perfectly functional.
    iii. There is already some logical association between the
       session and the LSPs in the call, and it makes sense to
       extend this.
    iv. The key on the Notify message is the session.
    v. The current I-D is also perfectly functional, and has been
        successfully implemented.
Given that no specific draw-back to the current encoding has been put
forward except for a feeling of illogicality among some readers, the authors
propose no further action except for polling the MPLS WG as described above.

4. Procedures for including LINK_CAPABILITIES object
A comment was made that this appears to be totally optional without any
defined procedures for how an LSR should decide wheter to include the
object.
The authors agree with this view, and it is intentional. The draft states...
   The LINK CAPABILITY object is introduced to support link capability
   exchange during Call setup and MAY be included in a Notify message
   used for Call setup. This optional object includes the bundled link
   local capabilities of the Call initiating node (or terminating node)
   indicated by the source address of the Notify message.
This text makes it quite clear that the object is completely optional.
The authors propose to make no changes for this point.

5. Question about processing rules in section 6.2.1
There was a detailed quesiton about the procedure in seciton 6.2.1.
The authors believe that this was answered and concluded on the mailing
list.
The authors propose to make no changes for this point.

6. Refresh Notify
Lyndon asked whether the refresh of the Notify message is really necessary
if there are active LSPs in the call?  Possibly the LSP refresh
could be sufficient, since this carries the short Call ID. He also asked
if it possible that the call would be dropped while there are still
active LSPs.
The authors consider that you cannot infer the status of the call when there
are no connections on the call. They believe that a single mechanism
should be used to monitor the call status in all circumstances.
The draft describes refresh failure of calls when connections already exist
in section 6.7.

In short, we propose to make no changes to the document as a result of WG 
last call. We will notify the MPLS WG as described above.

Can this I-D now move on the ADs?

Thanks,
Adrian 

Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 12 Jul 2006 19:12:29 +0000
Message-ID: <062701c6a5e6$e40805f0$e90ddb84@your029b8cecfe>
Reply-To: "Adrian Farrel" <adrian@olddog.co.uk>
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: <ccamp@ops.ietf.org>
Subject: OSPF ASON Routing Solution
Date: Wed, 12 Jul 2006 20:10:05 +0100
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Hi,
On Monday in CCAMP we discussed 
draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt the solutions draft for 
OSPF in ASON routing.

There is agreement from the OSPF WG chair that we are not treading on toes, 
and the meeting seemed to say that this was pretty stable.

So a this is a quick poll to see if anyone objects to this becoming a WG 
draft.
NB, this is a charter item and we have an obligation to work on this for the 
ITU-T.

Thanks,
Adrian

PS Note that a solution does not have to be 100% perfect to become a WG 
draft. 

Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 12 Jul 2006 15:01:34 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6A5C4.0AEBC201"
Subject: RE: Revision 02 of draft-caviglia-ccamp-pc-and-sc-reqs
Date: Wed, 12 Jul 2006 10:00:31 -0500
Message-ID: <A278CCD6FF152E478C3CF84E4C3BC79D0982BC@rchemx01.fnc.net.local>
Thread-Topic: Revision 02 of draft-caviglia-ccamp-pc-and-sc-reqs
thread-index: AcalJgaEcilYGUEZSA650kwBcNqpTAAmU43uAAElrcg=
From: "Bardalai, Snigdho" <Snigdho.Bardalai@us.fujitsu.com>
To: "Diego Caviglia" <Diego.Caviglia@marconi.com>, <ccamp@ops.ietf.org>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6A5C4.0AEBC201
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Diego,
=20
I would like to clarify the the difference between the terms =
"conversion" and
"migration".
=20
The title says "conversion" and in the document "migration" is used.
=20
Migration seems to be defined in the document i.e. migration of MP =
states to
CP states. The difference between MP state (in the node) and CP state is =
that
MP states do not have the end-point information whereas the CP states =
have
end-point information. I belief the assumption here is that the =
end-point information
is provided from an external source e.g. NMS.
=20
Now coming to conversion I belief we mean at some point of time the =
operator was
using the MP states and after the conversion is complete the operator =
starts using
the CP. Now I belief the migration is just a single step in all of this. =
For example,
the conversion process could include:
+ Identification of the circuits or auto-discovery of the circuits
+ Migration
+ Some grouping to associate the various LSPs into protection groups, =
VCAT groups
   etc.
=20
My point is we need to have an understanding of these processes and =
exclude or
include these within the scope of GMPLS.
=20
Regards,
Snigdho
=20
________________________________

From: owner-ccamp@ops.ietf.org on behalf of Diego Caviglia
Sent: Tue 7/11/2006 3:08 PM
To: ccamp@ops.ietf.org
Subject: Revision 02 of draft-caviglia-ccamp-pc-and-sc-reqs

Hi all,=20
               seems that the revision 02 of the draft in subject has =
been published =
(http://www.ietf.org/internet-drafts/draft-caviglia-ccamp-pc-and-sc-reqs-=
02.txt) on the repository.=20

This revision addresses the last comments we received from Dimitri and =
Adrian.=20

If I've understood correctly what we decided yestarday this version is =
candidate to become WG document, is this correct Adrian?=20

Best Regards=20

Diego=20

------_=_NextPart_001_01C6A5C4.0AEBC201
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">=0A=
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">=0A=
<HTML dir=3Dltr><HEAD>=0A=
<META content=3D"MSHTML 6.00.2800.1491" name=3DGENERATOR></HEAD>=0A=
<BODY>=0A=
<DIV id=3DidOWAReplyText96388 dir=3Dltr>=0A=
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 size=3D2><FONT =
face=3DArial =0A=
color=3D#000000 size=3D2>Hi Diego,</FONT></DIV></DIV>=0A=
<DIV dir=3Dltr>=0A=
<DIV id=3DidOWAReplyText25970 dir=3Dltr>=0A=
<DIV dir=3Dltr>=0A=
<DIV id=3DidOWAReplyText21420 dir=3Dltr>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>I would like to clarify the =
the difference =0A=
between the terms "conversion" and</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>"migration".</FONT></DIV>=0A=
<DIV dir=3Dltr>&nbsp;</DIV>=0A=
<DIV dir=3Dltr>The title says "conversion" and in the document =
"migration" is =0A=
used.</DIV>=0A=
<DIV dir=3Dltr>&nbsp;</DIV>=0A=
<DIV dir=3Dltr>Migration seems to be defined in the document i.e. =
migration of MP =0A=
states to</DIV>=0A=
<DIV dir=3Dltr>CP states. The difference between MP state (in the node) =
and CP =0A=
state is that</DIV>=0A=
<DIV dir=3Dltr>MP states do not have the end-point information whereas =
the CP =0A=
states have</DIV>=0A=
<DIV dir=3Dltr>end-point information. I belief the assumption here is =
that the =0A=
end-point information</DIV>=0A=
<DIV dir=3Dltr>is provided from an external source e.g. NMS.</DIV>=0A=
<DIV dir=3Dltr>&nbsp;</DIV>=0A=
<DIV dir=3Dltr>Now coming to conversion I belief we mean at some point =
of time the =0A=
operator was</DIV>=0A=
<DIV dir=3Dltr>using the MP states and after the conversion is complete =
the =0A=
operator starts using</DIV>=0A=
<DIV dir=3Dltr>the CP. Now I belief the migration is just a single step =
in all of =0A=
this. For example,</DIV>=0A=
<DIV dir=3Dltr>the conversion process could include:</DIV>=0A=
<DIV dir=3Dltr>+ Identification of the circuits or auto-discovery of the =0A=
circuits</DIV>=0A=
<DIV dir=3Dltr>+ Migration</DIV>=0A=
<DIV dir=3Dltr>+ Some grouping to associate the various LSPs into =
protection =0A=
groups, VCAT groups</DIV>=0A=
<DIV dir=3Dltr>&nbsp;&nbsp; etc.</DIV>=0A=
<DIV dir=3Dltr>&nbsp;</DIV>=0A=
<DIV dir=3Dltr>My point is we need to have an understanding of these =
processes and =0A=
exclude or</DIV>=0A=
<DIV dir=3Dltr>include these within the scope of GMPLS.</DIV>=0A=
<DIV dir=3Dltr>&nbsp;</DIV>=0A=
<DIV dir=3Dltr>Regards,</DIV>=0A=
<DIV dir=3Dltr>Snigdho</DIV>=0A=
<DIV dir=3Dltr></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr>=0A=
<HR tabIndex=3D-1>=0A=
</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DTahoma size=3D2><B>From:</B> =
owner-ccamp@ops.ietf.org on =0A=
behalf of Diego Caviglia<BR><B>Sent:</B> Tue 7/11/2006 3:08 =
PM<BR><B>To:</B> =0A=
ccamp@ops.ietf.org<BR><B>Subject:</B> Revision 02 of =0A=
draft-caviglia-ccamp-pc-and-sc-reqs<BR></FONT><BR></DIV></DIV></DIV></DIV=
>=0A=
<DIV><BR><FONT face=3Dsans-serif size=3D2>Hi all,</FONT> <BR><FONT =
face=3Dsans-serif =0A=
size=3D2>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;seems =
that the =0A=
revision 02 of the draft in subject has been published =0A=
(http://www.ietf.org/internet-drafts/draft-caviglia-ccamp-pc-and-sc-reqs-=
02.txt) =0A=
on the repository.</FONT> <BR><BR><FONT face=3Dsans-serif size=3D2>This =
revision =0A=
addresses the last comments we received from Dimitri and Adrian.</FONT> =0A=
<BR><BR><FONT face=3Dsans-serif size=3D2>If I've understood correctly =
what we =0A=
decided yestarday this version is candidate to become WG document, is =
this =0A=
correct Adrian?</FONT> <BR><BR><FONT face=3Dsans-serif size=3D2>Best =
Regards</FONT> =0A=
<BR><BR><FONT face=3Dsans-serif size=3D2>Diego</FONT> =0A=
<BR><BR></DIV></DIV></BODY></HTML>=0A=

------_=_NextPart_001_01C6A5C4.0AEBC201--

Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 12 Jul 2006 14:55:39 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: VLAN label range requirement
Date: Wed, 12 Jul 2006 10:51:53 -0400
Message-ID: <0901D1988E815341A0103206A834DA07E7D143@mdmxm02.ciena.com>
Thread-Topic: VLAN label range requirement
Thread-Index: AcalunZT/igJvRN2QqqWvLz5rX3c6QABdRQg
From: "Ong, Lyndon" <Lyong@Ciena.com>
To: <dpapadimitriou@psg.com>, <dimitri.papadimitriou@alcatel.be>
Cc: "Stephen Shew" <sdshew@nortel.com>, "Adrian Farrel" <adrian@olddog.co.uk>, <ccamp@ops.ietf.org>

Hi dimitri,

No, that's a fair point - in practice we have been testing up to 21v,
had not looked into the ability to signal 256v.

I suppose if you did have a co-routed 256v this would require
256 32-bit SUKLM values, for 1024 bytes.

The issue with VLAN IDs came about when someone calculated that
4094 12 bit VLAN IDs would consume 6144 bytes worth of message
(or 5 messages) if you just sent each VLAN ID without compressing this.

Lyndon

-----Original Message-----
From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com]=20
Sent: Wednesday, July 12, 2006 6:53 AM
To: Ong, Lyndon
Cc: dimitri.papadimitriou@alcatel.be; Stephen Shew; Adrian Farrel;
ccamp@ops.ietf.org
Subject: Re: VLAN label range requirement

lyndon

- not sure to understand - the information part of the liaison question
was "how large is large" ?

eg. RFC 3946 support VC4-256v did you ever ask the question whether we
have an efficient encoding ?

Ong, Lyndon wrote:

> Sure, I understand.  I think the concern that was expressed at the
last
> OIF
> meeting was whether we might need to define an efficient way of
> describing
> a set consisting of a very large set of labels, since the range of
VLAN
> tags,
> for example, is quite a bit larger than the typical set of labels
> assumed for
> optical switches.  If OIF comes up with=20
> any proposals along those lines, it would then liaise this to CCAMP
for
> its
> consideration.
>=20
> Cheers,
>=20
> Lyndon=20
>=20
> -----Original Message-----
> From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com]=20
> Sent: Wednesday, July 12, 2006 6:33 AM
> To: Ong, Lyndon
> Cc: Stephen Shew; Adrian Farrel; ccamp@ops.ietf.org
> Subject: Re: VLAN label range requirement
>=20
> lyndon -
>=20
> listing a set of labels as part of the response is something already
> covered in GMPLS
>=20
> hence if i well understand the MEF.10 document the information
elements
> that needs to be considered is quite straightforward
>=20
> so do we need this loop back and forth ? why not just produce a 2 page
> doc and close this ?
>=20
> thx,
> - d.
>=20
> Ong, Lyndon wrote:
>=20
>=20
>>That was my interpretation also, not sure if that came through on the=20
>>slides.
>>
>>Lyndon
>>
>>-----Original Message-----
>>From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On=20
>>Behalf Of Stephen Shew
>>Sent: Tuesday, July 11, 2006 8:09 PM
>>To: Adrian Farrel; ccamp@ops.ietf.org
>>Subject: RE: VLAN label range requirement
>>
>>You're welcome.
>>
>>The response from CCAMP on this question is very thorough, and I=20
>>certainly appreciate the thought that went into it.  My interpretation
>=20
>=20
>>of the response is that that CCAMP encourages the OIF to design an=20
>>encoding for the VLAN identifiers, and communicate it back to CCAMP.
>>
>>Stephen
>>
>>-----Original Message-----
>>From: Adrian Farrel [mailto:adrian@olddog.co.uk]
>>Sent: July 11, 2006 18:42
>>To: Shew, Stephen (CAR:Q840); ccamp@ops.ietf.org
>>Subject: Re: VLAN label range requirement
>>
>>Thanks Stephen.
>>
>>What is your opinion of the response to this question that CCAMP=20
>>supplied in its return communication to the OIF?
>>
>>Adrian
>>----- Original Message -----
>>From: "Stephen Shew" <sdshew@nortel.com>
>>To: <ccamp@ops.ietf.org>
>>Sent: Tuesday, July 11, 2006 4:44 PM
>>Subject: VLAN label range requirement
>>
>>
>>In yesterday's meeting, there was a request for more information on=20
>>the VLAN label range requirement.  From the original OIF liaison, the=20
>>description was:
>>"We are investigating label formats to represent a list or range of=20
>>VLAN identifiers, as used in MEF.11 bundling. In the case where a=20
>>large number of non-consecutive VLAN identifiers is used for the same=20
>>connection, we would like to keep the label to a reasonable size."
>>
>>The requirement to send a range of VLAN identifiers in signalling=20
>>arises in the bundling feature in Ethernet services as specified in=20
>>Metro Ethernet Forum (MEF) and ITU-T SG15 documents.  In the MEF, the=20
>>MEF.11 spec "User Network Interface (UNI) Requirements and Framework"=20
>>there is a UNI service attribute called "bundling" that is described=20
>>as "A UNI attribute in which more than one CE-VLAN ID is associated
>=20
> with an EVC."
>=20
>>It is more fully described in MEF.10 "Ethernet Services Attributes=20
>>Phase 1".  Both technical specs may be obtained free at:
>>http://www.metroethernetforum.org/TechSpec.htm
>>
>>Equivalent ITU-T Recs. are G.8011, G8011.1, and G.8011.2.  These are=20
>>available to ITU-T members, or under a "3 free" capability on the=20
>>ITU-T website.
>>
>>Of interest is the MEF Ethernet Link Management Interface (E-LMI)=20
>>defined in MEF.16 that has an encoding for passing VLAN ranges between
>=20
>=20
>>the UNI client and network.  This in a structure called the "CE-VLAN=20
>>ID/EVC Map information element".
>>
>>I hope this provides more clarity to the VLAN label range issue.
>>
>>Stephen Shew
>>Metro Ethernet Networks
>>Nortel
>>sdshew@nortel.com
>>Telephone: +1 613 763 2462 / ESN 393 2462
>>
>>
>>
>>
>>.
>>
>=20
>=20
> .
>=20

Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 12 Jul 2006 13:52:51 +0000
Message-ID: <44B4FEB1.3080500@psg.com>
Date: Wed, 12 Jul 2006 15:52:49 +0200
From: dimitri papadimitriou <dpapadimitriou@psg.com>
Reply-To:  dpapadimitriou@psg.com,  dimitri.papadimitriou@alcatel.be
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728
MIME-Version: 1.0
To: "Ong, Lyndon" <Lyong@Ciena.com>
CC:  dimitri.papadimitriou@alcatel.be, Stephen Shew <sdshew@nortel.com>,  Adrian Farrel <adrian@olddog.co.uk>, ccamp@ops.ietf.org
Subject: Re: VLAN label range requirement
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

lyndon

- not sure to understand - the information part of the liaison question 
was "how large is large" ?

eg. RFC 3946 support VC4-256v did you ever ask the question whether we 
have an efficient encoding ?

Ong, Lyndon wrote:

> Sure, I understand.  I think the concern that was expressed at the last
> OIF
> meeting was whether we might need to define an efficient way of
> describing
> a set consisting of a very large set of labels, since the range of VLAN
> tags,
> for example, is quite a bit larger than the typical set of labels
> assumed for
> optical switches.  If OIF comes up with 
> any proposals along those lines, it would then liaise this to CCAMP for
> its
> consideration.
> 
> Cheers,
> 
> Lyndon 
> 
> -----Original Message-----
> From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com] 
> Sent: Wednesday, July 12, 2006 6:33 AM
> To: Ong, Lyndon
> Cc: Stephen Shew; Adrian Farrel; ccamp@ops.ietf.org
> Subject: Re: VLAN label range requirement
> 
> lyndon -
> 
> listing a set of labels as part of the response is something already
> covered in GMPLS
> 
> hence if i well understand the MEF.10 document the information elements
> that needs to be considered is quite straightforward
> 
> so do we need this loop back and forth ? why not just produce a 2 page
> doc and close this ?
> 
> thx,
> - d.
> 
> Ong, Lyndon wrote:
> 
> 
>>That was my interpretation also, not sure if that came through on the 
>>slides.
>>
>>Lyndon
>>
>>-----Original Message-----
>>From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On 
>>Behalf Of Stephen Shew
>>Sent: Tuesday, July 11, 2006 8:09 PM
>>To: Adrian Farrel; ccamp@ops.ietf.org
>>Subject: RE: VLAN label range requirement
>>
>>You're welcome.
>>
>>The response from CCAMP on this question is very thorough, and I 
>>certainly appreciate the thought that went into it.  My interpretation
> 
> 
>>of the response is that that CCAMP encourages the OIF to design an 
>>encoding for the VLAN identifiers, and communicate it back to CCAMP.
>>
>>Stephen
>>
>>-----Original Message-----
>>From: Adrian Farrel [mailto:adrian@olddog.co.uk]
>>Sent: July 11, 2006 18:42
>>To: Shew, Stephen (CAR:Q840); ccamp@ops.ietf.org
>>Subject: Re: VLAN label range requirement
>>
>>Thanks Stephen.
>>
>>What is your opinion of the response to this question that CCAMP 
>>supplied in its return communication to the OIF?
>>
>>Adrian
>>----- Original Message -----
>>From: "Stephen Shew" <sdshew@nortel.com>
>>To: <ccamp@ops.ietf.org>
>>Sent: Tuesday, July 11, 2006 4:44 PM
>>Subject: VLAN label range requirement
>>
>>
>>In yesterday's meeting, there was a request for more information on 
>>the VLAN label range requirement.  From the original OIF liaison, the 
>>description was:
>>"We are investigating label formats to represent a list or range of 
>>VLAN identifiers, as used in MEF.11 bundling. In the case where a 
>>large number of non-consecutive VLAN identifiers is used for the same 
>>connection, we would like to keep the label to a reasonable size."
>>
>>The requirement to send a range of VLAN identifiers in signalling 
>>arises in the bundling feature in Ethernet services as specified in 
>>Metro Ethernet Forum (MEF) and ITU-T SG15 documents.  In the MEF, the 
>>MEF.11 spec "User Network Interface (UNI) Requirements and Framework" 
>>there is a UNI service attribute called "bundling" that is described 
>>as "A UNI attribute in which more than one CE-VLAN ID is associated
> 
> with an EVC."
> 
>>It is more fully described in MEF.10 "Ethernet Services Attributes 
>>Phase 1".  Both technical specs may be obtained free at:
>>http://www.metroethernetforum.org/TechSpec.htm
>>
>>Equivalent ITU-T Recs. are G.8011, G8011.1, and G.8011.2.  These are 
>>available to ITU-T members, or under a "3 free" capability on the 
>>ITU-T website.
>>
>>Of interest is the MEF Ethernet Link Management Interface (E-LMI) 
>>defined in MEF.16 that has an encoding for passing VLAN ranges between
> 
> 
>>the UNI client and network.  This in a structure called the "CE-VLAN 
>>ID/EVC Map information element".
>>
>>I hope this provides more clarity to the VLAN label range issue.
>>
>>Stephen Shew
>>Metro Ethernet Networks
>>Nortel
>>sdshew@nortel.com
>>Telephone: +1 613 763 2462 / ESN 393 2462
>>
>>
>>
>>
>>.
>>
> 
> 
> .
> 

Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 12 Jul 2006 13:47:36 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: VLAN label range requirement
Date: Wed, 12 Jul 2006 09:41:22 -0400
Message-ID: <0901D1988E815341A0103206A834DA07E7D123@mdmxm02.ciena.com>
Thread-Topic: VLAN label range requirement
Thread-Index: Acalt6HFebRjnOiuR22lSaWgFw8YZgAACPDQ
From: "Ong, Lyndon" <Lyong@Ciena.com>
To: <dpapadimitriou@psg.com>, <dimitri.papadimitriou@alcatel.be>, "Ong, Lyndon" <Lyong@Ciena.com>
Cc: "Stephen Shew" <sdshew@nortel.com>, "Adrian Farrel" <adrian@olddog.co.uk>, <ccamp@ops.ietf.org>

Sure, I understand.  I think the concern that was expressed at the last
OIF
meeting was whether we might need to define an efficient way of
describing
a set consisting of a very large set of labels, since the range of VLAN
tags,
for example, is quite a bit larger than the typical set of labels
assumed for
optical switches.  If OIF comes up with=20
any proposals along those lines, it would then liaise this to CCAMP for
its
consideration.

Cheers,

Lyndon=20

-----Original Message-----
From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com]=20
Sent: Wednesday, July 12, 2006 6:33 AM
To: Ong, Lyndon
Cc: Stephen Shew; Adrian Farrel; ccamp@ops.ietf.org
Subject: Re: VLAN label range requirement

lyndon -

listing a set of labels as part of the response is something already
covered in GMPLS

hence if i well understand the MEF.10 document the information elements
that needs to be considered is quite straightforward

so do we need this loop back and forth ? why not just produce a 2 page
doc and close this ?

thx,
- d.

Ong, Lyndon wrote:

> That was my interpretation also, not sure if that came through on the=20
> slides.
>=20
> Lyndon
>=20
> -----Original Message-----
> From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On=20
> Behalf Of Stephen Shew
> Sent: Tuesday, July 11, 2006 8:09 PM
> To: Adrian Farrel; ccamp@ops.ietf.org
> Subject: RE: VLAN label range requirement
>=20
> You're welcome.
>=20
> The response from CCAMP on this question is very thorough, and I=20
> certainly appreciate the thought that went into it.  My interpretation

> of the response is that that CCAMP encourages the OIF to design an=20
> encoding for the VLAN identifiers, and communicate it back to CCAMP.
>=20
> Stephen
>=20
> -----Original Message-----
> From: Adrian Farrel [mailto:adrian@olddog.co.uk]
> Sent: July 11, 2006 18:42
> To: Shew, Stephen (CAR:Q840); ccamp@ops.ietf.org
> Subject: Re: VLAN label range requirement
>=20
> Thanks Stephen.
>=20
> What is your opinion of the response to this question that CCAMP=20
> supplied in its return communication to the OIF?
>=20
> Adrian
> ----- Original Message -----
> From: "Stephen Shew" <sdshew@nortel.com>
> To: <ccamp@ops.ietf.org>
> Sent: Tuesday, July 11, 2006 4:44 PM
> Subject: VLAN label range requirement
>=20
>=20
> In yesterday's meeting, there was a request for more information on=20
> the VLAN label range requirement.  From the original OIF liaison, the=20
> description was:
> "We are investigating label formats to represent a list or range of=20
> VLAN identifiers, as used in MEF.11 bundling. In the case where a=20
> large number of non-consecutive VLAN identifiers is used for the same=20
> connection, we would like to keep the label to a reasonable size."
>=20
> The requirement to send a range of VLAN identifiers in signalling=20
> arises in the bundling feature in Ethernet services as specified in=20
> Metro Ethernet Forum (MEF) and ITU-T SG15 documents.  In the MEF, the=20
> MEF.11 spec "User Network Interface (UNI) Requirements and Framework"=20
> there is a UNI service attribute called "bundling" that is described=20
> as "A UNI attribute in which more than one CE-VLAN ID is associated
with an EVC."
> It is more fully described in MEF.10 "Ethernet Services Attributes=20
> Phase 1".  Both technical specs may be obtained free at:
> http://www.metroethernetforum.org/TechSpec.htm
>=20
> Equivalent ITU-T Recs. are G.8011, G8011.1, and G.8011.2.  These are=20
> available to ITU-T members, or under a "3 free" capability on the=20
> ITU-T website.
>=20
> Of interest is the MEF Ethernet Link Management Interface (E-LMI)=20
> defined in MEF.16 that has an encoding for passing VLAN ranges between

> the UNI client and network.  This in a structure called the "CE-VLAN=20
> ID/EVC Map information element".
>=20
> I hope this provides more clarity to the VLAN label range issue.
>=20
> Stephen Shew
> Metro Ethernet Networks
> Nortel
> sdshew@nortel.com
> Telephone: +1 613 763 2462 / ESN 393 2462
>=20
>=20
>=20
>=20
> .
>=20

Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 12 Jul 2006 13:32:59 +0000
Message-ID: <44B4F9F3.70205@psg.com>
Date: Wed, 12 Jul 2006 15:32:35 +0200
From: dimitri papadimitriou <dpapadimitriou@psg.com>
Reply-To:  dpapadimitriou@psg.com,  dimitri.papadimitriou@alcatel.be
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728
MIME-Version: 1.0
To: "Ong, Lyndon" <Lyong@Ciena.com>
CC: Stephen Shew <sdshew@nortel.com>, Adrian Farrel <adrian@olddog.co.uk>,  ccamp@ops.ietf.org
Subject: Re: VLAN label range requirement
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

lyndon -

listing a set of labels as part of the response is something already 
covered in GMPLS

hence if i well understand the MEF.10 document the information elements 
that needs to be considered is quite straightforward

so do we need this loop back and forth ? why not just produce a 2 page 
doc and close this ?

thx,
- d.

Ong, Lyndon wrote:

> That was my interpretation also, not sure if that
> came through on the slides.
> 
> Lyndon 
> 
> -----Original Message-----
> From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On
> Behalf Of Stephen Shew
> Sent: Tuesday, July 11, 2006 8:09 PM
> To: Adrian Farrel; ccamp@ops.ietf.org
> Subject: RE: VLAN label range requirement
> 
> You're welcome.
> 
> The response from CCAMP on this question is very thorough, and I
> certainly appreciate the thought that went into it.  My interpretation
> of the response is that that CCAMP encourages the OIF to design an
> encoding for the VLAN identifiers, and communicate it back to CCAMP.
> 
> Stephen 
> 
> -----Original Message-----
> From: Adrian Farrel [mailto:adrian@olddog.co.uk]
> Sent: July 11, 2006 18:42
> To: Shew, Stephen (CAR:Q840); ccamp@ops.ietf.org
> Subject: Re: VLAN label range requirement
> 
> Thanks Stephen.
> 
> What is your opinion of the response to this question that CCAMP
> supplied in its return communication to the OIF?
> 
> Adrian
> ----- Original Message -----
> From: "Stephen Shew" <sdshew@nortel.com>
> To: <ccamp@ops.ietf.org>
> Sent: Tuesday, July 11, 2006 4:44 PM
> Subject: VLAN label range requirement
> 
> 
> In yesterday's meeting, there was a request for more information on the
> VLAN label range requirement.  From the original OIF liaison, the
> description was:
> "We are investigating label formats to represent a list or range of VLAN
> identifiers, as used in MEF.11 bundling. In the case where a large
> number of non-consecutive VLAN identifiers is used for the same
> connection, we would like to keep the label to a reasonable size."
> 
> The requirement to send a range of VLAN identifiers in signalling arises
> in the bundling feature in Ethernet services as specified in Metro
> Ethernet Forum (MEF) and ITU-T SG15 documents.  In the MEF, the MEF.11
> spec "User Network Interface (UNI) Requirements and Framework" there is
> a UNI service attribute called "bundling" that is described as "A UNI
> attribute in which more than one CE-VLAN ID is associated with an EVC."
> It is more fully described in MEF.10 "Ethernet Services Attributes Phase
> 1".  Both technical specs may be obtained free at:
> http://www.metroethernetforum.org/TechSpec.htm
> 
> Equivalent ITU-T Recs. are G.8011, G8011.1, and G.8011.2.  These are
> available to ITU-T members, or under a "3 free" capability on the ITU-T
> website.
> 
> Of interest is the MEF Ethernet Link Management Interface (E-LMI)
> defined in MEF.16 that has an encoding for passing VLAN ranges between
> the UNI client and network.  This in a structure called the "CE-VLAN
> ID/EVC Map information element".
> 
> I hope this provides more clarity to the VLAN label range issue.
> 
> Stephen Shew
> Metro Ethernet Networks
> Nortel
> sdshew@nortel.com
> Telephone: +1 613 763 2462 / ESN 393 2462
> 
> 
> 
> 
> .
> 

Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 12 Jul 2006 12:32:35 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: VLAN label range requirement
Date: Wed, 12 Jul 2006 08:30:48 -0400
Message-ID: <0901D1988E815341A0103206A834DA07E7D103@mdmxm02.ciena.com>
Thread-Topic: VLAN label range requirement
Thread-Index: AcalO0odqDQlf0kXQ3+aEMcooJ7rvgAJEmjQABPW83A=
From: "Ong, Lyndon" <Lyong@Ciena.com>
To: "Stephen Shew" <sdshew@nortel.com>, "Adrian Farrel" <adrian@olddog.co.uk>, <ccamp@ops.ietf.org>

That was my interpretation also, not sure if that
came through on the slides.

Lyndon=20

-----Original Message-----
From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On
Behalf Of Stephen Shew
Sent: Tuesday, July 11, 2006 8:09 PM
To: Adrian Farrel; ccamp@ops.ietf.org
Subject: RE: VLAN label range requirement

You're welcome.

The response from CCAMP on this question is very thorough, and I
certainly appreciate the thought that went into it.  My interpretation
of the response is that that CCAMP encourages the OIF to design an
encoding for the VLAN identifiers, and communicate it back to CCAMP.

Stephen=20

-----Original Message-----
From: Adrian Farrel [mailto:adrian@olddog.co.uk]
Sent: July 11, 2006 18:42
To: Shew, Stephen (CAR:Q840); ccamp@ops.ietf.org
Subject: Re: VLAN label range requirement

Thanks Stephen.

What is your opinion of the response to this question that CCAMP
supplied in its return communication to the OIF?

Adrian
----- Original Message -----
From: "Stephen Shew" <sdshew@nortel.com>
To: <ccamp@ops.ietf.org>
Sent: Tuesday, July 11, 2006 4:44 PM
Subject: VLAN label range requirement

In yesterday's meeting, there was a request for more information on the
VLAN label range requirement.  From the original OIF liaison, the
description was:
"We are investigating label formats to represent a list or range of VLAN
identifiers, as used in MEF.11 bundling. In the case where a large
number of non-consecutive VLAN identifiers is used for the same
connection, we would like to keep the label to a reasonable size."

The requirement to send a range of VLAN identifiers in signalling arises
in the bundling feature in Ethernet services as specified in Metro
Ethernet Forum (MEF) and ITU-T SG15 documents.  In the MEF, the MEF.11
spec "User Network Interface (UNI) Requirements and Framework" there is
a UNI service attribute called "bundling" that is described as "A UNI
attribute in which more than one CE-VLAN ID is associated with an EVC."
It is more fully described in MEF.10 "Ethernet Services Attributes Phase
1".  Both technical specs may be obtained free at:
http://www.metroethernetforum.org/TechSpec.htm

Equivalent ITU-T Recs. are G.8011, G8011.1, and G.8011.2.  These are
available to ITU-T members, or under a "3 free" capability on the ITU-T
website.

Of interest is the MEF Ethernet Link Management Interface (E-LMI)
defined in MEF.16 that has an encoding for passing VLAN ranges between
the UNI client and network.  This in a structure called the "CE-VLAN
ID/EVC Map information element".

I hope this provides more clarity to the VLAN label range issue.

Stephen Shew
Metro Ethernet Networks
Nortel
sdshew@nortel.com
Telephone: +1 613 763 2462 / ESN 393 2462

Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 12 Jul 2006 03:10:25 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: VLAN label range requirement
Date: Tue, 11 Jul 2006 23:09:22 -0400
Message-ID: <29D15BBCA340DA4D8146D38B4924FC7A072DBC5F@zcarhxm0.corp.nortel.com>
Thread-Topic: VLAN label range requirement
Thread-Index: AcalO0odqDQlf0kXQ3+aEMcooJ7rvgAJEmjQ
From: "Stephen Shew" <sdshew@nortel.com>
To: "Adrian Farrel" <adrian@olddog.co.uk>, <ccamp@ops.ietf.org>

You're welcome.

The response from CCAMP on this question is very thorough, and I
certainly appreciate the thought that went into it.  My interpretation
of the response is that that CCAMP encourages the OIF to design an
encoding for the VLAN identifiers, and communicate it back to CCAMP.

Stephen=20

-----Original Message-----
From: Adrian Farrel [mailto:adrian@olddog.co.uk]=20
Sent: July 11, 2006 18:42
To: Shew, Stephen (CAR:Q840); ccamp@ops.ietf.org
Subject: Re: VLAN label range requirement

Thanks Stephen.

What is your opinion of the response to this question that CCAMP
supplied in its return communication to the OIF?

Adrian
----- Original Message -----
From: "Stephen Shew" <sdshew@nortel.com>
To: <ccamp@ops.ietf.org>
Sent: Tuesday, July 11, 2006 4:44 PM
Subject: VLAN label range requirement

In yesterday's meeting, there was a request for more information on the
VLAN label range requirement.  From the original OIF liaison, the
description was:
"We are investigating label formats to represent a list or range of
VLAN identifiers, as used in MEF.11 bundling. In the case where a large
number of non-consecutive VLAN identifiers is used for the same
connection, we would like to keep the label to a reasonable size."

The requirement to send a range of VLAN identifiers in signalling arises
in the bundling feature in Ethernet services as specified in Metro
Ethernet Forum (MEF) and ITU-T SG15 documents.  In the MEF, the MEF.11
spec "User Network Interface (UNI) Requirements and Framework" there is
a UNI service attribute called "bundling" that is described as "A UNI
attribute in which more than one CE-VLAN ID is associated with an EVC."
It is more fully described in MEF.10 "Ethernet Services Attributes Phase
1".  Both technical specs may be obtained free at:
http://www.metroethernetforum.org/TechSpec.htm

Equivalent ITU-T Recs. are G.8011, G8011.1, and G.8011.2.  These are
available to ITU-T members, or under a "3 free" capability on the ITU-T
website.

Of interest is the MEF Ethernet Link Management Interface (E-LMI)
defined in MEF.16 that has an encoding for passing VLAN ranges between
the UNI client and network.  This in a structure called the "CE-VLAN
ID/EVC Map information element".

I hope this provides more clarity to the VLAN label range issue.

Stephen Shew
Metro Ethernet Networks
Nortel
sdshew@nortel.com
Telephone: +1 613 763 2462 / ESN 393 2462

Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 12 Jul 2006 01:16:59 +0000
From: "Jaihyung Cho" <jaihyung@etri.re.kr>
To: "'Brungard, Deborah A, ALABS'" <dbrungard@att.com>
Cc: <ccamp@ops.ietf.org>, <gels@rtg.ietf.org>
Subject: RE: Future of the GELS mailing list
Date: Wed, 12 Jul 2006 10:16:05 +0900
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Thread-Index: Acak9iUj36oBCZC9Tom2kJdsvltFVgABi3swABMDOiA=
Message-ID: <EMAIL1T2NqFJ3sl3xbY0001de60@email1.etri.info>

Thanks Debora, 
but a question remains.

Is GELS the initial place to bring control plane issue of Ethernet?

I think the appropriate form of work is 
CCAMP to charter the control plane work ASAP and
go standardization process in CCAMP.
Any necessary data plane issue should be discussed in IEEE
and GELS should only remain as temporary place for it.
If the control plane work assumes any unsupported 
data plane feature in IEEE, it shouldn't be dealt in CCAMP.

Thanks

Jaihyung

> -----Original Message-----
> From: gels-bounces@rtg.ietf.org [mailto:gels-bounces@rtg.ietf.org] On
> Behalf Of Brungard, Deborah A, ALABS
> Sent: Wednesday, July 12, 2006 12:18 AM
> To: Loa Andersson; Adrian Farrel
> Cc: ccamp@ops.ietf.org; Dimitri.Papadimitriou@alcatel.be;
gels@rtg.ietf.org;
> Don Fedyk
> Subject: RE: Future of the GELS mailing list
> 
> 
> Hi all,
> 
> Decision: The GELS mailing list continues - please use it to progress
> the work. And when appropriate for an item (the chairs hope you all can
> determine this, if not, ask), use the CCAMP list.
> 
> Anyone interested can subscribe to GELS:
> https://rtg.ietf.org/mailman/listinfo/gels
> 
> Adrian and Deborah
> 
> -----Original Message-----
> From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On
> Behalf Of Loa Andersson
> Sent: Tuesday, July 11, 2006 10:27 AM
> To: Adrian Farrel
> Cc: Don Fedyk; Dimitri.Papadimitriou@alcatel.be; ccamp@ops.ietf.org;
> gels@rtg.ietf.org
> Subject: Re: Future of the GELS mailing list
> 
> 
> 
> Adrian Farrel wrote:
> >> We have agreed we don't define the IEEE data planes in
> >> the IETF.  But we will need a venue to discuss the profile
> >> of the data plane(s).  A separate list may be useful.
> >
> > That was also my thinking, and I would prefer *that* discussion to not
> > happen on the CCAMP list.
> 
> isn't this statement enough? wg chair says do not discuss this on the
> main wg mailing list, do take somewhere?
> 
> I can understand asking for consensus, but this is an issue where
> we are unlikely to get anyway near consensus
> 
> wg chairs decide!!
> 
> /Loa
> 
> >
> > Adrian
> >
> >
> >
> 
> 
> --
> Loa Andersson
> 
> Principal Networking Architect
> Acreo AB                           phone:  +46 8 632 77 14
> Isafjordsgatan 22                  mobile: +46 739 81 21 64
> Kista, Sweden                      email:  loa.andersson@acreo.se
>                                            loa@pi.se
> 
> 
> _______________________________________________
> gels mailing list
> gels@rtg.ietf.org
> https://rtg.ietf.org/mailman/listinfo/gels

Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 12 Jul 2006 00:07:58 +0000
Message-ID: <44B43D28.9060806@psg.com>
Date: Wed, 12 Jul 2006 02:07:04 +0200
From: dimitri papadimitriou <dpapadimitriou@psg.com>
Reply-To:  dpapadimitriou@psg.com,  dimitri.papadimitriou@alcatel.be
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728
MIME-Version: 1.0
To: Diego Caviglia <Diego.Caviglia@marconi.com>
CC:  dimitri.papadimitriou@alcatel.be, ccamp <ccamp@ops.ietf.org>
Subject: Re: Revision 02 of draft-caviglia-ccamp-pc-and-sc-reqs
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

hi diego - would you indicate these conditions in your doc.

thanks,
- dimitri.

Diego Caviglia wrote:

> Hi Dimitri,
>                  for sure GR and its extensions reduce the possibility 
> that the CP fails permanently but do not make it zero.  I mean it is 
> possible that the CP is not able to restart for a long period of time, or 
> that some of its data are corrupted and so on.
> 
> Best Regards
> 
> Diego
> 
> 
> Please respond to dpapadimitriou@psg.com; Please respond to 
> dimitri.papadimitriou@alcatel.be
> To:     Diego Caviglia <Diego.Caviglia@marconi.com>
> cc:     ccamp@ops.ietf.org 
> 
> Subject:        Re: Revision 02 of draft-caviglia-ccamp-pc-and-sc-reqs
> 
> hi diego
> 
> could you please explain positioning of section 2.2 wrt to control plane 
> recovery we have today defined in GR and extensions
> 
> much thanks,
> - dimitri.
> 
> Diego Caviglia wrote:
> 
> 
>>Hi all,
>>               seems that the revision 02 of the draft in subject has 
> 
> been 
> 
>>published 
>>(http://www.ietf.org/internet-drafts/draft-caviglia-ccamp-pc-and-sc-reqs-02.txt) 
>>on the repository.
>>
>>This revision addresses the last comments we received from Dimitri and 
>>Adrian.
>>
>>If I've understood correctly what we decided yestarday this version is 
>>candidate to become WG document, is this correct Adrian?
>>
>>Best Regards
>>
>>Diego
>>
>>
> 
> 
> 
> 
> 

Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 11 Jul 2006 22:42:29 +0000
Message-ID: <049301c6a53b$3aba76f0$e90ddb84@your029b8cecfe>
Reply-To: "Adrian Farrel" <adrian@olddog.co.uk>
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: "Stephen Shew" <sdshew@nortel.com>, <ccamp@ops.ietf.org>
Subject: Re: VLAN label range requirement
Date: Tue, 11 Jul 2006 23:41:52 +0100
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Thanks Stephen.

What is your opinion of the response to this question that CCAMP supplied in 
its return communication to the OIF?

Adrian
----- Original Message ----- 
From: "Stephen Shew" <sdshew@nortel.com>
To: <ccamp@ops.ietf.org>
Sent: Tuesday, July 11, 2006 4:44 PM
Subject: VLAN label range requirement

In yesterday's meeting, there was a request for more information on the
VLAN label range requirement.  From the original OIF liaison, the
description was:
"We are investigating label formats to represent a list or range of
VLAN identifiers, as used in MEF.11 bundling. In the case where a large
number of non-consecutive VLAN identifiers is used for the same
connection, we would like to keep the label to a reasonable size."

The requirement to send a range of VLAN identifiers in signalling arises
in the bundling feature in Ethernet services as specified in Metro
Ethernet Forum (MEF) and ITU-T SG15 documents.  In the MEF, the MEF.11
spec "User Network Interface (UNI) Requirements and Framework" there is
a UNI service attribute called "bundling" that is described as "A UNI
attribute in which more than one CE-VLAN ID is associated with an EVC."
It is more fully described in MEF.10 "Ethernet Services Attributes Phase
1".  Both technical specs may be obtained free at:
http://www.metroethernetforum.org/TechSpec.htm

Equivalent ITU-T Recs. are G.8011, G8011.1, and G.8011.2.  These are
available to ITU-T members, or under a "3 free" capability on the ITU-T
website.

Of interest is the MEF Ethernet Link Management Interface (E-LMI)
defined in MEF.16 that has an encoding for passing VLAN ranges between
the UNI client and network.  This in a structure called the "CE-VLAN
ID/EVC Map information element".

I hope this provides more clarity to the VLAN label range issue.

Stephen Shew
Metro Ethernet Networks
Nortel
sdshew@nortel.com
Telephone: +1 613 763 2462 / ESN 393 2462

Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 11 Jul 2006 22:29:55 +0000
Sensitivity: 
Subject: Re: Revision 02 of draft-caviglia-ccamp-pc-and-sc-reqs
To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be
Cc: "ccamp" <ccamp@ops.ietf.org>
Message-ID: <OF94EE2A39.6A9DDC05-ONC12571A8.0079AC01-C12571A8.007B9CFD@uk.marconicomms.com>
From: "Diego Caviglia" <Diego.Caviglia@marconi.com>
Date: Wed, 12 Jul 2006 00:29:42 +0200
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

Hi Dimitri,
                 for sure GR and its extensions reduce the possibility that
the CP fails permanently but do not make it zero.  I mean it is possible
that the CP is not able to restart for a long period of time, or that some
of its data are corrupted and so on.

Best Regards

Diego

dimitri papadimitriou <dpapadimitriou@psg.com> on 12/07/2006 00.06.21

Please respond to dpapadimitriou@psg.com; Please respond to
       dimitri.papadimitriou@alcatel.be

To:    Diego Caviglia <Diego.Caviglia@marconi.com>
cc:    ccamp@ops.ietf.org

Subject:    Re: Revision 02 of draft-caviglia-ccamp-pc-and-sc-reqs

hi diego

could you please explain positioning of section 2.2 wrt to control plane
recovery we have today defined in GR and extensions

much thanks,
- dimitri.

Diego Caviglia wrote:

> Hi all,
>                seems that the revision 02 of the draft in subject has
been
> published
> (
http://www.ietf.org/internet-drafts/draft-caviglia-ccamp-pc-and-sc-reqs-02.txt
)
> on the repository.
>
> This revision addresses the last comments we received from Dimitri and
> Adrian.
>
> If I've understood correctly what we decided yestarday this version is
> candidate to become WG document, is this correct Adrian?
>
> Best Regards
>
> Diego
>
>

Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 11 Jul 2006 22:07:02 +0000
Message-ID: <44B420DD.4060201@psg.com>
Date: Wed, 12 Jul 2006 00:06:21 +0200
From: dimitri papadimitriou <dpapadimitriou@psg.com>
Reply-To:  dpapadimitriou@psg.com,  dimitri.papadimitriou@alcatel.be
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728
MIME-Version: 1.0
To: Diego Caviglia <Diego.Caviglia@marconi.com>
CC:  ccamp@ops.ietf.org
Subject: Re: Revision 02 of draft-caviglia-ccamp-pc-and-sc-reqs
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

hi diego

could you please explain positioning of section 2.2 wrt to control plane 
recovery we have today defined in GR and extensions

much thanks,
- dimitri.

Diego Caviglia wrote:

> Hi all,
>                seems that the revision 02 of the draft in subject has been 
> published 
> (http://www.ietf.org/internet-drafts/draft-caviglia-ccamp-pc-and-sc-reqs-02.txt) 
> on the repository.
> 
> This revision addresses the last comments we received from Dimitri and 
> Adrian.
> 
> If I've understood correctly what we decided yestarday this version is 
> candidate to become WG document, is this correct Adrian?
> 
> Best Regards
> 
> Diego
> 
> 

Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 11 Jul 2006 20:55:19 +0000
Message-ID: <44B41010.3000207@science.uva.nl>
Date: Tue, 11 Jul 2006 22:54:40 +0200
From: Freek Dijkstra <fdijkstr@science.uva.nl>
User-Agent: Thunderbird 1.5.0.4 (Macintosh/20060530)
MIME-Version: 1.0
To: ccamp@ops.ietf.org
Subject: Short question on LSA
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Hi,

If there is a link between two interfaces (of two devices), is that link
announced by one or by two LSAs?

Could someone point me to the right RFC? I couldn't find a definitive
answer there. I expected it in RFC 4202 or RFC 4203.

  +-------------+                         +-------------+
  |             |          Link           |             |
  | Eth. switch o-------------------------o TDM switch  o--
  |             | A                     B |             |
  +-------------+                         +-------------+

The above scenario features a ethernet switch and a TDM switch which can
embed Ethernet in a STS-24c channel.
In this scenario, I now expect that there is one LSA made by the
Ethernet switch, and one LSA made by the TDM switch, and that the
Ethernet switch would announce L2SC and Ethernet encoding for interface
A, and the TDM switch would announce TDM switching capability and
Ethernet encoding for interface B.

Please flame me if I'm wrong ;-)

Regards,
Freek

Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 11 Jul 2006 20:08:34 +0000
MIME-Version: 1.0
Sensitivity: 
To: ccamp@ops.ietf.org
Subject: Revision 02 of draft-caviglia-ccamp-pc-and-sc-reqs
Message-ID: <OF108BA503.B289923C-ONC12571A8.006E4478-C12571A8.006EA7D1@uk.marconicomms.com>
From: "Diego Caviglia" <Diego.Caviglia@marconi.com>
Date: Tue, 11 Jul 2006 22:08:10 +0200
Content-Type: multipart/alternative; boundary="=_alternative 006EA7D0C12571A8_="

This is a multipart message in MIME format.
--=_alternative 006EA7D0C12571A8_=
Content-Type: text/plain; charset="us-ascii"

Hi all,
               seems that the revision 02 of the draft in subject has been 
published 
(http://www.ietf.org/internet-drafts/draft-caviglia-ccamp-pc-and-sc-reqs-02.txt) 
on the repository.

This revision addresses the last comments we received from Dimitri and 
Adrian.

If I've understood correctly what we decided yestarday this version is 
candidate to become WG document, is this correct Adrian?

Best Regards

Diego

--=_alternative 006EA7D0C12571A8_=
Content-Type: text/html; charset="us-ascii"

<br><font size=2 face="sans-serif">Hi all,</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;seems that the revision 02 of the draft in subject has been published (http://www.ietf.org/internet-drafts/draft-caviglia-ccamp-pc-and-sc-reqs-02.txt) on the repository.</font>
<br>
<br><font size=2 face="sans-serif">This revision addresses the last comments we received from Dimitri and Adrian.</font>
<br>
<br><font size=2 face="sans-serif">If I've understood correctly what we decided yestarday this version is candidate to become WG document, is this correct Adrian?</font>
<br>
<br><font size=2 face="sans-serif">Best Regards</font>
<br>
<br><font size=2 face="sans-serif">Diego</font>
<br>
<br>
--=_alternative 006EA7D0C12571A8_=--

Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 11 Jul 2006 19:34:03 +0000
Message-ID: <44B3FCF4.6020600@psg.com>
Date: Tue, 11 Jul 2006 21:33:08 +0200
From: dimitri papadimitriou <dpapadimitriou@psg.com>
Reply-To:  dpapadimitriou@psg.com,  dimitri.papadimitriou@alcatel.be
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728
MIME-Version: 1.0
To: Igor Bryskin <ibryskin@movaz.com>
CC: Stephen Shew <sdshew@nortel.com>,  ccamp@ops.ietf.org
Subject: Re: Comments (2) on draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

relaxing seems sensible for the cases indicated here below

-d.

Igor Bryskin wrote:

> Comments (2) on draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt2.
> Section 5.1. The text indicates that the new Local and Remote TE
> Router ID sub-TLV is only included when the Ri is advertising more
> than one Li. I think this should be relaxed to allow it to be sent
> even in the case that the Ri:Li relationship is 1:1.  For an Ri that
> an operator plans to start of with 1 Li and then add more in scope,
> the processing becomes consistent.
> 
> Agree 100%
> 
> Igor Stephen Shew Metro Ethernet Networks Nortel sdshew@nortel.com 
> Telephone: +1 613 763 2462 / ESN 393 2462
> 

Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 11 Jul 2006 16:31:39 +0000
Message-ID: <006b01c6a507$694fa820$d70010ac@movaz.com>
From: "Igor Bryskin" <ibryskin@movaz.com>
To: "Stephen Shew" <sdshew@nortel.com>, <ccamp@ops.ietf.org>
Subject: Re: Comments (2) on draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt
Date: Tue, 11 Jul 2006 12:30:39 -0400
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0062_01C6A4E5.D131B680"

This is a multi-part message in MIME format.

------=_NextPart_000_0062_01C6A4E5.D131B680
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Comments (2) on draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt2. =
Section 5.1. The text indicates that the new Local and Remote TE Router =
ID sub-TLV is only included when the Ri is advertising more than one Li. =
I think this should be relaxed to allow it to be sent even in the case =
that the Ri:Li relationship is 1:1.  For an Ri that an operator plans to =
start of with 1 Li and then add more in scope, the processing becomes =
consistent.

Agree 100%

Igor
  Stephen Shew=20
  Metro Ethernet Networks=20
  Nortel=20
  sdshew@nortel.com=20
  Telephone: +1 613 763 2462 / ESN 393 2462=20

------=_NextPart_000_0062_01C6A4E5.D131B680
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Comments (2) on =
draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1400" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>2. Section =
5.1. The text=20
indicates that the new Local and Remote TE Router ID sub-TLV is only =
included=20
when the Ri is advertising more than one Li. I think this should be =
relaxed to=20
allow it to be sent even in the case that the Ri:Li relationship is =
1:1.&nbsp;=20
For an Ri that an operator plans to start of with 1 Li and then add more =
in=20
scope, the processing becomes consistent.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Agree 100%</DIV>
<DIV>&nbsp;</DIV>
<DIV>Igor</DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
 Stephen Shew =
 <FONT=20
 face=3DArial color=3D#000000 size=3D2>Metro Ethernet Networks =
 <FONT=20
 face=3DArial color=3D#000000 size=3D2>Nortel sdshew@nortel.com Telephone: +1 613 763 2462 / ESN 393 =
2462=20
</BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0062_01C6A4E5.D131B680--

Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 11 Jul 2006 15:55:13 +0000
Message-ID: <44B3C9C4.9090801@netscape.net>
Date: Tue, 11 Jul 2006 11:54:44 -0400
From: Eric W Gray <ewgray2k@netscape.net>
Reply-To: ewgray@GraIyMage.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
MIME-Version: 1.0
To: "Andrew G. Malis" <agmalis@gmail.com>
CC: "Dimitri.Papadimitriou@alcatel.be" <Dimitri.Papadimitriou@alcatel.be>, Adrian Farrel <adrian@olddog.co.uk>, ccamp@ops.ietf.org, gels@rtg.ietf.org, owner-ccamp@ops.ietf.org, Don Fedyk <dwfedyk@nortel.com>
Subject: Re: Future of the GELS mailing list
Content-Type: multipart/alternative; boundary="------------070102090709000003090009"

--------------070102090709000003090009
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Andy,

    Because this is an over-simplification, I have to disagree.

    We need somewhere in which to talk about work - even if it is being done
somewhere else - partly because we are otherwise asking everyone to join an
IEEE mailing list (for example) and partly because we would otherwise gum up
the CCAMP mailing list with that discussion (as we are now doing).

--
Eric

Andrew G. Malis wrote:

> Dimitri,
>  
> Since we've agreed that the data plane elements are out of the IETF's 
> charter, this discussion shouldn't occur on an IETF-sponsored list 
> (such as gels@rtg.ietf.org <mailto:gels@rtg.ietf.org>).  This should 
> happen either on an IEEE-associated list, or a private list not 
> associated with the IETF.
>  
> Thanks,
> Andy
>
>  
> On 7/11/06, Dimitri.Papadimitriou@alcatel.be 
> <mailto:Dimitri.Papadimitriou@alcatel.be> 
> <Dimitri.Papadimitriou@alcatel.be 
> <mailto:Dimitri.Papadimitriou@alcatel.be>> wrote:
>
>     adrian & don
>
>     > We have agreed we don't define the IEEE data planes in the IETF.
>
>     this is agreed before starting GELS (from last year)
>
>     the point is that we need a place to discuss data plane elements
>     that are
>     in scope of the control plane
>
>     thanks,
>     - dimitri.
>
>
>
>
>
>     "Adrian Farrel" < adrian@olddog.co.uk <mailto:adrian@olddog.co.uk>>
>     Sent by: owner-ccamp@ops.ietf.org <mailto:owner-ccamp@ops.ietf.org>
>     11/07/2006 15:35
>     Please respond to "Adrian Farrel"
>
>            To:     "Don Fedyk" < dwfedyk@nortel.com
>     <mailto:dwfedyk@nortel.com>>, Dimitri
>     PAPADIMITRIOU/BE/ALCATEL@ALCATEL
>            cc:     <ccamp@ops.ietf.org <mailto:ccamp@ops.ietf.org>>, <
>     gels@rtg.ietf.org <mailto:gels@rtg.ietf.org>>
>            Subject:        Re: Future of the GELS mailing list
>
>
>     > We have agreed we don't define the IEEE data planes in
>     > the IETF.  But we will need a venue to discuss the profile
>     > of the data plane(s).  A separate list may be useful.
>
>     That was also my thinking, and I would prefer *that* discussion to not
>     happen on the CCAMP list.
>
>     Adrian
>
>
>
>
>
>     _______________________________________________
>     gels mailing list
>     gels@rtg.ietf.org <mailto:gels@rtg.ietf.org>
>     https://rtg.ietf.org/mailman/listinfo/gels
>
>

--------------070102090709000003090009
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Andy,<br>
<br>
&nbsp;&nbsp;&nbsp; Because this is an over-simplification, I have to disagree.<br>
<br>
&nbsp;&nbsp;&nbsp; We need somewhere in which to talk about work - even if it is being
done<br>
somewhere else - partly because we are otherwise asking everyone to
join an<br>
IEEE mailing list (for example) and partly because we would otherwise
gum up<br>
the CCAMP mailing list with that discussion (as we are now doing).<br>
<br>
--<br>
Eric<br>
<br>
Andrew G. Malis wrote:<br>
<blockquote  cite="mid8c99930d0607110700y12fb55bl994ca5f6e38c3e07@mail.gmail.com"  type="cite">
  <div>Dimitri,</div>
  <div>&nbsp;</div>
  <div>Since we've agreed that the data plane elements are out of the
IETF's charter, this discussion shouldn't occur on an IETF-sponsored
list (such as <a href="mailto:gels@rtg.ietf.org">gels@rtg.ietf.org</a>).&nbsp;
This should happen either on an IEEE-associated list, or a private list
not associated with the IETF.
  </div>
  <div>&nbsp;</div>
  <div>Thanks,</div>
  <div>Andy<br>
  <br>
&nbsp;</div>
  <div><span class="gmail_quote">On 7/11/06, <b  class="gmail_sendername"><a  href="mailto:Dimitri.Papadimitriou@alcatel.be">Dimitri.Papadimitriou@alcatel.be</a></b>
&lt;<a href="mailto:Dimitri.Papadimitriou@alcatel.be">Dimitri.Papadimitriou@alcatel.be
  </a>&gt; wrote:</span>
  <blockquote class="gmail_quote"  style="border-left: 1px solid rgb(204, 204, 204); margin: 0px 0px 0px 0.8ex; padding-left: 1ex;">adrian
&amp; don<br>
    <br>
&gt; We have agreed we don't define the IEEE data planes in the IETF.<br>
    <br>
this is agreed before starting GELS (from last year)
    <br>
    <br>
the point is that we need a place to discuss data plane elements that
are<br>
in scope of the control plane<br>
    <br>
thanks,<br>
- dimitri.<br>
    <br>
    <br>
    <br>
    <br>
    <br>
"Adrian Farrel" &lt;<a href="mailto:adrian@olddog.co.uk">
adrian@olddog.co.uk</a>&gt;<br>
Sent by: <a href="mailto:owner-ccamp@ops.ietf.org">owner-ccamp@ops.ietf.org</a><br>
11/07/2006 15:35<br>
Please respond to "Adrian Farrel"<br>
    <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; To:&nbsp;&nbsp;&nbsp;&nbsp; "Don Fedyk" &lt;
    <a href="mailto:dwfedyk@nortel.com">dwfedyk@nortel.com</a>&gt;,
Dimitri<br>
PAPADIMITRIOU/BE/ALCATEL@ALCATEL<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; cc:&nbsp;&nbsp;&nbsp;&nbsp; &lt;<a href="mailto:ccamp@ops.ietf.org">ccamp@ops.ietf.org</a>&gt;,
&lt;<a href="mailto:gels@rtg.ietf.org">
gels@rtg.ietf.org</a>&gt;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Re: Future of the GELS mailing list<br>
    <br>
    <br>
&gt; We have agreed we don't define the IEEE data planes in<br>
&gt; the IETF.&nbsp;&nbsp;But we will need a venue to discuss the profile
    <br>
&gt; of the data plane(s).&nbsp;&nbsp;A separate list may be useful.<br>
    <br>
That was also my thinking, and I would prefer *that* discussion to not<br>
happen on the CCAMP list.<br>
    <br>
Adrian<br>
    <br>
    <br>
    <br>
    <br>
    <br>
_______________________________________________
    <br>
gels mailing list<br>
    <a href="mailto:gels@rtg.ietf.org">gels@rtg.ietf.org</a><br>
    <a href="https://rtg.ietf.org/mailman/listinfo/gels">https://rtg.ietf.org/mailman/listinfo/gels</a><br>
  </blockquote>
  </div>
  <br>
</blockquote>
</body>
</html>

--------------070102090709000003090009--

Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 11 Jul 2006 15:45:03 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6A500.DCC1618D"
Subject: VLAN label range requirement
Date: Tue, 11 Jul 2006 11:44:13 -0400
Message-ID: <29D15BBCA340DA4D8146D38B4924FC7A07273313@zcarhxm0.corp.nortel.com>
Thread-Topic: VLAN label range requirement
Thread-Index: AcalANspXO9XhpA9QhSLGSDxJEWSwQ==
From: "Stephen Shew" <sdshew@nortel.com>
To: <ccamp@ops.ietf.org>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6A500.DCC1618D
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

In yesterday's meeting, there was a request for more information on the
VLAN label range requirement.  From the original OIF liaison, the
description was:
"We are investigating label formats to represent a list or range of
VLAN identifiers, as used in MEF.11 bundling. In the case where a large
number of non-consecutive VLAN identifiers is used for the same
connection, we would like to keep the label to a reasonable size."

The requirement to send a range of VLAN identifiers in signalling arises
in the bundling feature in Ethernet services as specified in Metro
Ethernet Forum (MEF) and ITU-T SG15 documents.  In the MEF, the MEF.11
spec "User Network Interface (UNI) Requirements and Framework" there is
a UNI service attribute called "bundling" that is described as "A UNI
attribute in which more than one CE-VLAN ID is associated with an EVC."
It is more fully described in MEF.10 "Ethernet Services Attributes Phase
1".  Both technical specs may be obtained free at:
http://www.metroethernetforum.org/TechSpec.htm

Equivalent ITU-T Recs. are G.8011, G8011.1, and G.8011.2.  These are
available to ITU-T members, or under a "3 free" capability on the ITU-T
website.

Of interest is the MEF Ethernet Link Management Interface (E-LMI)
defined in MEF.16 that has an encoding for passing VLAN ranges between
the UNI client and network.  This in a structure called the "CE-VLAN
ID/EVC Map information element".

I hope this provides more clarity to the VLAN label range issue.

Stephen Shew
Metro Ethernet Networks
Nortel
sdshew@nortel.com
Telephone: +1 613 763 2462 / ESN 393 2462

------_=_NextPart_001_01C6A500.DCC1618D
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7233.69">
<TITLE>VLAN label range requirement</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->

<P><FONT COLOR=3D"#008080" SIZE=3D2 FACE=3D"Times New Roman">In =
yesterday's meeting, there was a request for more information on the =
VLAN label range requirement.&nbsp; From the original OIF liaison, the =
description was:</FONT></P>

&quot;We =
are investigating label formats to represent a list or range of&nbsp; =
VLAN identifiers, as used in MEF.11 bundling. In the case where a large =
number of non-consecutive VLAN identifiers is used for the same =
connection, we would like to keep the label to a reasonable =
size.&quot;

<P><FONT COLOR=3D"#008080" SIZE=3D2 FACE=3D"Times New Roman">The =
requirement to send a range of VLAN identifiers in signalling arises in =
the bundling feature in Ethernet services as specified in Metro Ethernet =
Forum (MEF) and ITU-T SG15 documents.&nbsp; In the MEF, the MEF.11 spec =
&quot;User Network Interface (UNI) Requirements and Framework&quot; =
there is a UNI service attribute called &quot;bundling&quot; that is =
described as &quot;A UNI attribute in which more than one CE-VLAN ID is =
associated with an EVC.&quot;&nbsp; It is more fully described in MEF.10 =
&quot;Ethernet Services Attributes Phase 1&quot;.&nbsp; Both technical =
specs may be obtained free at: </FONT><A =
HREF=3D"http://www.metroethernetforum.org/TechSpec.htm"><U></U><U><FONT =
COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">http://www.metroethernetforum.org/TechSpec.htm</FONT></U></A></P>

Equivalent =
ITU-T Recs. are G.8011, G8011.1, and G.8011.2.&nbsp; These are available =
to ITU-T members, or under a &quot;3 free&quot; capability on the ITU-T =
website.

<P><FONT COLOR=3D"#008080" SIZE=3D2 FACE=3D"Times New Roman">Of interest =
is the MEF Ethernet Link Management Interface (E-LMI) defined in MEF.16 =
that has an encoding for passing VLAN ranges between the UNI client and =
network.&nbsp; This in a structure called the &quot;CE-VLAN ID/EVC Map =
information element&quot;.</FONT></P>

<P><FONT COLOR=3D"#008080" SIZE=3D2 FACE=3D"Times New Roman">I hope this =
provides more clarity to the VLAN label range issue.</FONT>
</P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Stephen Shew</FONT>

<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Metro Ethernet =
Networks</FONT>

<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Nortel</FONT>

<BR><FONT COLOR=3D"#000000" SIZE=3D2 =
FACE=3D"Arial">sdshew@nortel.com</FONT>

<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Telephone: +1 613 =
763 2462 / ESN 393 2462</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C6A500.DCC1618D--

Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 11 Jul 2006 14:45:08 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6A4F8.7210E9D0"
Subject: RE: Comments (2) on draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt
Date: Tue, 11 Jul 2006 10:43:59 -0400
Message-ID: <0901D1988E815341A0103206A834DA07E7D055@mdmxm02.ciena.com>
Thread-Topic: Comments (2) on draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt
Thread-Index: Acak9DB3v2qcH6daSoqpZPeMVmAUTwAA+EHQ
From: "Ong, Lyndon" <Lyong@Ciena.com>
To: "Stephen Shew" <sdshew@nortel.com>, <ccamp@ops.ietf.org>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6A4F8.7210E9D0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,
=20
I agree with Stephen, especially on the last item: it's better to head
off any confusion now between
the data plane node identifier and the routing controller identifier by
keeping these separate.=20
=20
Cheers,
=20
Lyndon

________________________________

From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On
Behalf Of Stephen Shew
Sent: Tuesday, July 11, 2006 7:14 AM
To: ccamp@ops.ietf.org
Subject: Comments (2) on
draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt

Two comments on the draft I have are:=20

1. General - it would be helpful to indicate in more places, if an
identifier is from a control plane address space or data plane address
space.  Some example places are in Section 3 and 5.2.

2. Section 5.1. The text indicates that the new Local and Remote TE
Router ID sub-TLV is only included when the Ri is advertising more than
one Li. I think this should be relaxed to allow it to be sent even in
the case that the Ri:Li relationship is 1:1.  For an Ri that an operator
plans to start of with 1 Li and then add more in scope, the processing
becomes consistent.

Stephen Shew=20
Metro Ethernet Networks=20
Nortel=20
sdshew@nortel.com=20
Telephone: +1 613 763 2462 / ESN 393 2462=20

------_=_NextPart_001_01C6A4F8.7210E9D0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Comments (2) on =
draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.2912" name=3DGENERATOR></HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft>Hi,</DIV>
<DIV dir=3Dltr align=3Dleft>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft>I agree with Stephen, especially on the last =
item: it's=20
better to head off any confusion now between</DIV>
<DIV dir=3Dltr align=3Dleft>the data plane node identifier and the routing =
controller=20
identifier by keeping these separate.&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft>Cheers,</DIV>
<DIV dir=3Dltr align=3Dleft>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft>Lyndon</DIV> 
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
<HR tabIndex=3D-1>
From: owner-ccamp@ops.ietf.org=20
[mailto:owner-ccamp@ops.ietf.org] On Behalf Of Stephen=20
Shew Sent: Tuesday, July 11, 2006 7:14 AM To:=20
ccamp@ops.ietf.org Subject: Comments (2) on=20
draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt </DIV>
<DIV></DIV>
Two comments =
on the draft I=20
have are: 
1. General - =
it would be=20
helpful to indicate in more places, if an identifier is from a control =
plane=20
address space or data plane address space.&nbsp; Some example places are =
in=20
Section 3 and 5.2.
2. Section =
5.1. The text=20
indicates that the new Local and Remote TE Router ID sub-TLV is only =
included=20
when the Ri is advertising more than one Li. I think this should be =
relaxed to=20
allow it to be sent even in the case that the Ri:Li relationship is =
1:1.&nbsp;=20
For an Ri that an operator plans to start of with 1 Li and then add more =
in=20
scope, the processing becomes consistent.
Stephen Shew =
 <FONT=20
face=3DArial color=3D#000000 size=3D2>Metro Ethernet Networks =
 <FONT=20
face=3DArial color=3D#000000 size=3D2>Nortel sdshew@nortel.com <FONT face=3DArial color=3D#000000 =

size=3D2>Telephone: +1 613 763 2462 / ESN 393 2462</FONT> =
</P></BODY></HTML>

------_=_NextPart_001_01C6A4F8.7210E9D0--

Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 11 Jul 2006 14:27:13 +0000
Message-ID: <44B3B526.5050206@pi.se>
Date: Tue, 11 Jul 2006 16:26:46 +0200
From: Loa Andersson <loa@pi.se>
Organization: Acreo AB
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: Adrian Farrel <adrian@olddog.co.uk>
CC: Don Fedyk <dwfedyk@nortel.com>,  Dimitri.Papadimitriou@alcatel.be,  ccamp@ops.ietf.org,  gels@rtg.ietf.org
Subject: Re: Future of the GELS mailing list
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Adrian Farrel wrote:
>> We have agreed we don't define the IEEE data planes in
>> the IETF.  But we will need a venue to discuss the profile
>> of the data plane(s).  A separate list may be useful.
> 
> That was also my thinking, and I would prefer *that* discussion to not
> happen on the CCAMP list.

isn't this statement enough? wg chair says do not discuss this on the
main wg mailing list, do take somewhere?

I can understand asking for consensus, but this is an issue where
we are unlikely to get anyway near consensus

wg chairs decide!!

/Loa

> 
> Adrian
> 
> 
> 

-- 
Loa Andersson

Principal Networking Architect
Acreo AB                           phone:  +46 8 632 77 14
Isafjordsgatan 22                  mobile: +46 739 81 21 64
Kista, Sweden                      email:  loa.andersson@acreo.se
                                           loa@pi.se

Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 11 Jul 2006 14:24:14 +0000
To: "Don Fedyk" <dwfedyk@nortel.com>
Cc: "Adrian Farrel" <adrian@olddog.co.uk>, "Andrew G. Malis" <agmalis@gmail.com>, ccamp@ops.ietf.org, gels@rtg.ietf.org, owner-ccamp@ops.ietf.org
Subject: RE: Future of the GELS mailing list
MIME-Version: 1.0
Message-ID: <OF5F8AAEE9.2695F21F-ONC12571A8.004E4D4C-C12571A8.004F0952@netfr.alcatel.fr>
From: Dimitri.Papadimitriou@alcatel.be
Date: Tue, 11 Jul 2006 16:23:15 +0200
Content-Type: text/plain; charset="US-ASCII"

don - 

indeed liaison toward IEEE needs to be committed by IETF so there is a 
need to maintain this discussion within IETF (open) mailing list 
discussion and consensus

otherwise situation will be identical to the one we faced in GELS (no WG, 
no WG document hence difficulty to communicate with IEEE beside private 
discussions, hence no backup of potential solutions and so finally no 
possibility to start the intended control plane work) 

thanks,
- dimitri.

"Don Fedyk" <dwfedyk@nortel.com>
11/07/2006 16:06

        To:     "Andrew G. Malis" <agmalis@gmail.com>, Dimitri 
PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     "Adrian Farrel" <adrian@olddog.co.uk>, 
<ccamp@ops.ietf.org>, <gels@rtg.ietf.org>, <owner-ccamp@ops.ietf.org>
        Subject:        RE: Future of the GELS mailing list

Andy

The goal is not to have discussion that are out of scope but the messages 
will constantly be attempting to get the content into scope.  I don't 
think this is the private discussions of the data plane but it is the 
messages that are trying to define the profile we can talk about and 
liaise to the IEEE.  The outcome of this will be shared with CCAMP. 

Don 

From: Andrew G. Malis [mailto:agmalis@gmail.com] 
Sent: Tuesday, July 11, 2006 10:01 AM
To: Dimitri.Papadimitriou@alcatel.be
Cc: Adrian Farrel; ccamp@ops.ietf.org; gels@rtg.ietf.org; 
owner-ccamp@ops.ietf.org; Fedyk, Don (BL60:1A00)
Subject: Re: Future of the GELS mailing list

Dimitri,

Since we've agreed that the data plane elements are out of the IETF's 
charter, this discussion shouldn't occur on an IETF-sponsored list (such 
as gels@rtg.ietf.org).  This should happen either on an IEEE-associated 
list, or a private list not associated with the IETF. 

Thanks,
Andy

On 7/11/06, Dimitri.Papadimitriou@alcatel.be <
Dimitri.Papadimitriou@alcatel.be > wrote: 
adrian & don

> We have agreed we don't define the IEEE data planes in the IETF.

this is agreed before starting GELS (from last year) 

the point is that we need a place to discuss data plane elements that are
in scope of the control plane

thanks,
- dimitri.

"Adrian Farrel" < adrian@olddog.co.uk>
Sent by: owner-ccamp@ops.ietf.org
11/07/2006 15:35
Please respond to "Adrian Farrel"

       To:     "Don Fedyk" < dwfedyk@nortel.com>, Dimitri
PAPADIMITRIOU/BE/ALCATEL@ALCATEL
       cc:     <ccamp@ops.ietf.org>, < gels@rtg.ietf.org>
       Subject:        Re: Future of the GELS mailing list

> We have agreed we don't define the IEEE data planes in
> the IETF.  But we will need a venue to discuss the profile 
> of the data plane(s).  A separate list may be useful.

That was also my thinking, and I would prefer *that* discussion to not
happen on the CCAMP list.

Adrian

_______________________________________________ 
gels mailing list
gels@rtg.ietf.org
https://rtg.ietf.org/mailman/listinfo/gels

Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 11 Jul 2006 14:18:36 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6A4F3.2EE80276"
Subject: RE: Future of the GELS mailing list
Date: Tue, 11 Jul 2006 10:06:19 -0400
Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA409641951@zrtphxm2.corp.nortel.com>
Thread-Topic: Future of the GELS mailing list
Thread-Index: Acak8nBE0KcqIU9mTrKs22nCTfud1QAADiQQ
From: "Don Fedyk" <dwfedyk@nortel.com>
To: "Andrew G. Malis" <agmalis@gmail.com>, <Dimitri.Papadimitriou@alcatel.be>
Cc: "Adrian Farrel" <adrian@olddog.co.uk>, <ccamp@ops.ietf.org>, <gels@rtg.ietf.org>, <owner-ccamp@ops.ietf.org>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6A4F3.2EE80276
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Andy
=20
The goal is not to have discussion that are out of scope but the
messages will constantly be attempting to get the content into scope.  I
don't think this is the private discussions of the data plane but it is
the messages that are trying to define the profile we can talk about and
liaise to the IEEE.  The outcome of this will be shared with CCAMP.=20
=20
Don=20

________________________________

	From: Andrew G. Malis [mailto:agmalis@gmail.com]=20
	Sent: Tuesday, July 11, 2006 10:01 AM
	To: Dimitri.Papadimitriou@alcatel.be
	Cc: Adrian Farrel; ccamp@ops.ietf.org; gels@rtg.ietf.org;
owner-ccamp@ops.ietf.org; Fedyk, Don (BL60:1A00)
	Subject: Re: Future of the GELS mailing list
=09
=09
	Dimitri,
	=20
	Since we've agreed that the data plane elements are out of the
IETF's charter, this discussion shouldn't occur on an IETF-sponsored
list (such as gels@rtg.ietf.org).  This should happen either on an
IEEE-associated list, or a private list not associated with the IETF.=20
	=20
	Thanks,
	Andy
=09
	=20
	On 7/11/06, Dimitri.Papadimitriou@alcatel.be
<Dimitri.Papadimitriou@alcatel.be > wrote:=20

		adrian & don
	=09
		> We have agreed we don't define the IEEE data planes in
the IETF.
	=09
		this is agreed before starting GELS (from last year)=20
	=09
		the point is that we need a place to discuss data plane
elements that are
		in scope of the control plane
	=09
		thanks,
		- dimitri.
	=09
	=09
	=09
	=09
	=09
		"Adrian Farrel" < adrian@olddog.co.uk
<mailto:adrian@olddog.co.uk> >
		Sent by: owner-ccamp@ops.ietf.org
		11/07/2006 15:35
		Please respond to "Adrian Farrel"
	=09
		       To:     "Don Fedyk" < dwfedyk@nortel.com>,
Dimitri
		PAPADIMITRIOU/BE/ALCATEL@ALCATEL
		       cc:     <ccamp@ops.ietf.org>, < gels@rtg.ietf.org
<mailto:gels@rtg.ietf.org> >
		       Subject:        Re: Future of the GELS mailing
list
	=09
	=09
		> We have agreed we don't define the IEEE data planes in
		> the IETF.  But we will need a venue to discuss the
profile=20
		> of the data plane(s).  A separate list may be useful.
	=09
		That was also my thinking, and I would prefer *that*
discussion to not
		happen on the CCAMP list.
	=09
		Adrian
	=09
	=09
	=09
	=09
	=09
		_______________________________________________=20
		gels mailing list
		gels@rtg.ietf.org
		https://rtg.ietf.org/mailman/listinfo/gels
	=09

------_=_NextPart_001_01C6A4F3.2EE80276
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.2912" name=3DGENERATOR></HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft>Andy</DIV>
<DIV dir=3Dltr align=3Dleft>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft>The goal is not to have discussion that are out =
of scope=20
but the messages will constantly be attempting to get the content into=20
scope.&nbsp; I don't think this is the private discussions of the data =
plane but=20
it is the messages that are trying to define the profile we can talk =
about and=20
liaise to the IEEE. &nbsp;The outcome of this will be shared with CCAMP. =

</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D900340214-11072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D900340214-11072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Don </FONT></SPAN></DIV><BR>
<BLOCKQUOTE=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
  <HR tabIndex=3D-1>
  <FONT face=3DTahoma size=3D2><B>From:</B> Andrew G. Malis=20
  [mailto:agmalis@gmail.com] <BR><B>Sent:</B> Tuesday, July 11, 2006 =
10:01=20
  AM<BR><B>To:</B> Dimitri.Papadimitriou@alcatel.be<BR><B>Cc:</B> Adrian =
Farrel;=20
  ccamp@ops.ietf.org; gels@rtg.ietf.org; owner-ccamp@ops.ietf.org; =
Fedyk, Don=20
  (BL60:1A00)<BR><B>Subject:</B> Re: Future of the GELS mailing=20
  list<BR></FONT><BR></DIV>
  <DIV></DIV>
  <DIV>Dimitri,</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>Since we've agreed that the data plane elements are out of the =
IETF's=20
  charter, this discussion shouldn't occur on an IETF-sponsored list =
(such as <A=20
  href=3D"mailto:gels@rtg.ietf.org">gels@rtg.ietf.org</A>).&nbsp; This =
should=20
  happen either on an IEEE-associated list, or a private list not =
associated=20
  with the IETF. </DIV>
  <DIV>&nbsp;</DIV>
  <DIV>Thanks,</DIV>
  <DIV>Andy<BR><BR>&nbsp;</DIV>
  <DIV><SPAN class=3Dgmail_quote>On 7/11/06, <B =
class=3Dgmail_sendername><A=20
  =
href=3D"mailto:Dimitri.Papadimitriou@alcatel.be">Dimitri.Papadimitriou@al=
catel.be</A></B>=20
  &lt;<A=20
  =
href=3D"mailto:Dimitri.Papadimitriou@alcatel.be">Dimitri.Papadimitriou@al=
catel.be=20
  </A>&gt; wrote:</SPAN>=20
  <BLOCKQUOTE class=3Dgmail_quote=20
  style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: =
#ccc 1px solid">adrian=20
    &amp; don<BR><BR>&gt; We have agreed we don't define the IEEE data =
planes in=20
    the IETF.<BR><BR>this is agreed before starting GELS (from last =
year)=20
    <BR><BR>the point is that we need a place to discuss data plane =
elements=20
    that are<BR>in scope of the control plane<BR><BR>thanks,<BR>-=20
    dimitri.<BR><BR><BR><BR><BR><BR>"Adrian Farrel" &lt;<A=20
    href=3D"mailto:adrian@olddog.co.uk"> =
adrian@olddog.co.uk</A>&gt;<BR>Sent by:=20
    <A=20
    =
href=3D"mailto:owner-ccamp@ops.ietf.org">owner-ccamp@ops.ietf.org</A><BR>=
11/07/2006=20
    15:35<BR>Please respond to "Adrian=20
    Farrel"<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    To:&nbsp;&nbsp;&nbsp;&nbsp; "Don Fedyk" &lt; <A=20
    href=3D"mailto:dwfedyk@nortel.com">dwfedyk@nortel.com</A>&gt;,=20
    =
Dimitri<BR>PAPADIMITRIOU/BE/ALCATEL@ALCATEL<BR>&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;=20
    cc:&nbsp;&nbsp;&nbsp;&nbsp; &lt;<A=20
    href=3D"mailto:ccamp@ops.ietf.org">ccamp@ops.ietf.org</A>&gt;, =
&lt;<A=20
    href=3D"mailto:gels@rtg.ietf.org">=20
    gels@rtg.ietf.org</A>&gt;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Re: Future =
of the=20
    GELS mailing list<BR><BR><BR>&gt; We have agreed we don't define the =
IEEE=20
    data planes in<BR>&gt; the IETF.&nbsp;&nbsp;But we will need a venue =
to=20
    discuss the profile <BR>&gt; of the data plane(s).&nbsp;&nbsp;A =
separate=20
    list may be useful.<BR><BR>That was also my thinking, and I would =
prefer=20
    *that* discussion to not<BR>happen on the CCAMP=20
    =
list.<BR><BR>Adrian<BR><BR><BR><BR><BR><BR>______________________________=
_________________=20
    <BR>gels mailing list<BR><A=20
    href=3D"mailto:gels@rtg.ietf.org">gels@rtg.ietf.org</A><BR><A=20
    =
href=3D"https://rtg.ietf.org/mailman/listinfo/gels">https://rtg.ietf.org/=
mailman/listinfo/gels</A><BR></BLOCKQUOTE></DIV><BR></BLOCKQUOTE></BODY><=
/HTML>

------_=_NextPart_001_01C6A4F3.2EE80276--

Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 11 Jul 2006 14:17:31 +0000
To: "Andrew G. Malis" <agmalis@gmail.com>
Cc: "Adrian Farrel" <adrian@olddog.co.uk>, ccamp@ops.ietf.org, "Don Fedyk" <dwfedyk@nortel.com>, gels@rtg.ietf.org, owner-ccamp@ops.ietf.org
Subject: Re: Future of the GELS mailing list
MIME-Version: 1.0
Message-ID: <OFCB80EC16.DCD0267F-ONC12571A8.004DB75E-C12571A8.004E4479@netfr.alcatel.fr>
From: Dimitri.Papadimitriou@alcatel.be
Date: Tue, 11 Jul 2006 16:14:51 +0200
Content-Type: text/plain; charset="US-ASCII"

andy 

gels list would not be there for discussing the data plane functionality - 
but discuss there specific topics that will be in scope of the control 
plane mechanisms e.g. signaling & routing to be discussed at CCAMP - once 
the item will be part of the charter (note: this is not yet explicitly the 
case afaik)

-d. 

"Andrew G. Malis" <agmalis@gmail.com>
Sent by: owner-ccamp@ops.ietf.org
11/07/2006 16:00

        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     "Adrian Farrel" <adrian@olddog.co.uk>, ccamp@ops.ietf.org, 
gels@rtg.ietf.org, owner-ccamp@ops.ietf.org, "Don Fedyk" 
<dwfedyk@nortel.com>
        Subject:        Re: Future of the GELS mailing list

Dimitri,

Since we've agreed that the data plane elements are out of the IETF's 
charter, this discussion shouldn't occur on an IETF-sponsored list (such 
as gels@rtg.ietf.org).  This should happen either on an IEEE-associated 
list, or a private list not associated with the IETF. 

Thanks,
Andy

On 7/11/06, Dimitri.Papadimitriou@alcatel.be <
Dimitri.Papadimitriou@alcatel.be > wrote: 
adrian & don

> We have agreed we don't define the IEEE data planes in the IETF.

this is agreed before starting GELS (from last year) 

the point is that we need a place to discuss data plane elements that are
in scope of the control plane

thanks,
- dimitri.

"Adrian Farrel" < adrian@olddog.co.uk>
Sent by: owner-ccamp@ops.ietf.org
11/07/2006 15:35
Please respond to "Adrian Farrel"

       To:     "Don Fedyk" < dwfedyk@nortel.com>, Dimitri
PAPADIMITRIOU/BE/ALCATEL@ALCATEL
       cc:     <ccamp@ops.ietf.org>, < gels@rtg.ietf.org>
       Subject:        Re: Future of the GELS mailing list

> We have agreed we don't define the IEEE data planes in
> the IETF.  But we will need a venue to discuss the profile 
> of the data plane(s).  A separate list may be useful.

That was also my thinking, and I would prefer *that* discussion to not
happen on the CCAMP list.

Adrian

_______________________________________________ 
gels mailing list
gels@rtg.ietf.org
https://rtg.ietf.org/mailman/listinfo/gels

Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 11 Jul 2006 14:16:48 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6A4F4.31D48325"
Subject: Comments (2) on draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt
Date: Tue, 11 Jul 2006 10:13:33 -0400
Message-ID: <29D15BBCA340DA4D8146D38B4924FC7A07273067@zcarhxm0.corp.nortel.com>
Thread-Topic: Comments (2) on draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt
Thread-Index: Acak9DB3v2qcH6daSoqpZPeMVmAUTw==
From: "Stephen Shew" <sdshew@nortel.com>
To: <ccamp@ops.ietf.org>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6A4F4.31D48325
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Two comments on the draft I have are:

1. General - it would be helpful to indicate in more places, if an
identifier is from a control plane address space or data plane address
space.  Some example places are in Section 3 and 5.2.

2. Section 5.1. The text indicates that the new Local and Remote TE
Router ID sub-TLV is only included when the Ri is advertising more than
one Li. I think this should be relaxed to allow it to be sent even in
the case that the Ri:Li relationship is 1:1.  For an Ri that an operator
plans to start of with 1 Li and then add more in scope, the processing
becomes consistent.

Stephen Shew
Metro Ethernet Networks
Nortel
sdshew@nortel.com
Telephone: +1 613 763 2462 / ESN 393 2462

------_=_NextPart_001_01C6A4F4.31D48325
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7233.69">
<TITLE>Comments (2) on =
draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->

<P><FONT COLOR=3D"#008080" SIZE=3D2 FACE=3D"Times New Roman">Two =
comments on the draft I have are:</FONT>
</P>

<P><FONT COLOR=3D"#008080" SIZE=3D2 FACE=3D"Times New Roman">1. General =
- it would be helpful to indicate in more places, if an identifier is =
from a control plane address space or data plane address space.&nbsp; =
Some example places are in Section 3 and 5.2.</FONT></P>

2. Section =
5.1. The text indicates that the new Local and Remote TE Router ID =
sub-TLV is only included when the Ri is advertising more than one Li. I =
think this should be relaxed to allow it to be sent even in the case =
that the Ri:Li relationship is 1:1.&nbsp; For an Ri that an operator =
plans to start of with 1 Li and then add more in scope, the processing =
becomes consistent.

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Stephen Shew</FONT>

<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Metro Ethernet =
Networks</FONT>

<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Nortel</FONT>

<BR><FONT COLOR=3D"#000000" SIZE=3D2 =
FACE=3D"Arial">sdshew@nortel.com</FONT>

<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Telephone: +1 613 =
763 2462 / ESN 393 2462</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C6A4F4.31D48325--

Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 11 Jul 2006 14:06:06 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Future of the GELS mailing list
Date: Tue, 11 Jul 2006 16:05:36 +0200
Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB02603A53295@FTRDMEL2.rd.francetelecom.fr>
Thread-Topic: Future of the GELS mailing list
Thread-Index: Acak8C1qtfSbfFL+TKq+TDvycQpzswAACi3AAACKIMA=
From: "MEURIC Julien RD-CORE-LAN" <julien.meuric@orange-ft.com>
To: "Don Fedyk" <dwfedyk@nortel.com>, <Dimitri.Papadimitriou@alcatel.be>, <adrian@olddog.co.uk>
Cc: <ccamp@ops.ietf.org>, <gels@rtg.ietf.org>

Hi all.

I agree with you Don, especially since I know how large the amount of
GELS messages can be. ;-)  I believe having a dedicated list for those
specific topics can be convenient.

Regards,

Julien

-----Original Message-----
From: gels-bounces@rtg.ietf.org [mailto:gels-bounces@rtg.ietf.org] On
Behalf Of Don Fedyk

Hi Dimitri
> -----Original Message-----
> From: Dimitri.Papadimitriou@alcatel.be=20
>=20
> adrian & don
>=20
> > We have agreed we don't define the IEEE data planes in the IETF.
>=20
> this is agreed before starting GELS (from last year)

I was just reinforcing the point about what we profile on the data
plane.=20

>=20
> the point is that we need a place to discuss data plane=20
> elements that are in scope of the control plane

But many CCAMP people may not be interested in the details of that in
profile until it is finalized.=20
>=20
> thanks,
> - dimitri.
>=20
>=20
>=20
>=20
>=20
> "Adrian Farrel" <adrian@olddog.co.uk>
> Sent by: owner-ccamp@ops.ietf.org
> 11/07/2006 15:35
> Please respond to "Adrian Farrel"
> =20
>         To:     "Don Fedyk" <dwfedyk@nortel.com>, Dimitri=20
> PAPADIMITRIOU/BE/ALCATEL@ALCATEL
>         cc:     <ccamp@ops.ietf.org>, <gels@rtg.ietf.org>
>         Subject:        Re: Future of the GELS mailing list
>=20
>=20
> > We have agreed we don't define the IEEE data planes in the=20
> IETF.  But=20
> > we will need a venue to discuss the profile of the data=20
> plane(s).  A=20
> > separate list may be useful.
>=20
> That was also my thinking, and I would prefer *that*=20
> discussion to not happen on the CCAMP list.
>=20
> Adrian=20
>=20
>=20
>=20
>=20
>=20
>=20

_______________________________________________
gels mailing list
gels@rtg.ietf.org
https://rtg.ietf.org/mailman/listinfo/gels

Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 11 Jul 2006 14:01:02 +0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=TLzyXOexajAfDHSRo7AoaigVUFP3njg8T6bJeUc2N58bOp/dIb1thvPqj+Dg85hxdsqdXfXzKDQGNZMonpuKz9K9/Y9fKTJxFThCYqsh+w+FaS1Dd8V7Ht1dLxJf35q1HTVYP1AWuaz0v6rNIK+geTsbg2cJUvhc7zibehZoZbQ=
Message-ID: <8c99930d0607110700y12fb55bl994ca5f6e38c3e07@mail.gmail.com>
Date: Tue, 11 Jul 2006 10:00:48 -0400
From: "Andrew G. Malis" <agmalis@gmail.com>
To: "Dimitri.Papadimitriou@alcatel.be" <Dimitri.Papadimitriou@alcatel.be>
Subject: Re: Future of the GELS mailing list
Cc: "Adrian Farrel" <adrian@olddog.co.uk>, ccamp@ops.ietf.org, gels@rtg.ietf.org, owner-ccamp@ops.ietf.org, "Don Fedyk" <dwfedyk@nortel.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_104483_20182149.1152626448357"

------=_Part_104483_20182149.1152626448357
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Dimitri,

Since we've agreed that the data plane elements are out of the IETF's
charter, this discussion shouldn't occur on an IETF-sponsored list (such as
gels@rtg.ietf.org).  This should happen either on an IEEE-associated list,
or a private list not associated with the IETF.

Thanks,
Andy

On 7/11/06, Dimitri.Papadimitriou@alcatel.be <
Dimitri.Papadimitriou@alcatel.be> wrote:
>
> adrian & don
>
> > We have agreed we don't define the IEEE data planes in the IETF.
>
> this is agreed before starting GELS (from last year)
>
> the point is that we need a place to discuss data plane elements that are
> in scope of the control plane
>
> thanks,
> - dimitri.
>
>
>
>
>
> "Adrian Farrel" <adrian@olddog.co.uk>
> Sent by: owner-ccamp@ops.ietf.org
> 11/07/2006 15:35
> Please respond to "Adrian Farrel"
>
>        To:     "Don Fedyk" <dwfedyk@nortel.com>, Dimitri
> PAPADIMITRIOU/BE/ALCATEL@ALCATEL
>        cc:     <ccamp@ops.ietf.org>, <gels@rtg.ietf.org>
>        Subject:        Re: Future of the GELS mailing list
>
>
> > We have agreed we don't define the IEEE data planes in
> > the IETF.  But we will need a venue to discuss the profile
> > of the data plane(s).  A separate list may be useful.
>
> That was also my thinking, and I would prefer *that* discussion to not
> happen on the CCAMP list.
>
> Adrian
>
>
>
>
>
> _______________________________________________
> gels mailing list
> gels@rtg.ietf.org
> https://rtg.ietf.org/mailman/listinfo/gels
>

------=_Part_104483_20182149.1152626448357
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

<div>Dimitri,</div>
<div>&nbsp;</div>
<div>Since we've agreed that the data plane elements are out of the IETF's charter, this discussion shouldn't occur on an IETF-sponsored list (such as <a href="mailto:gels@rtg.ietf.org">gels@rtg.ietf.org</a>).&nbsp; This should happen either on an IEEE-associated list, or a private list not associated with the IETF.
</div>
<div>&nbsp;</div>
<div>Thanks,</div>
<div>Andy &nbsp;</div>
<div>On 7/11/06, <a href="mailto:Dimitri.Papadimitriou@alcatel.be">Dimitri.Papadimitriou@alcatel.be</a> &lt;<a href="mailto:Dimitri.Papadimitriou@alcatel.be">Dimitri.Papadimitriou@alcatel.be
</a>&gt; wrote:
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">adrian &amp; don &gt; We have agreed we don't define the IEEE data planes in the IETF. this is agreed before starting GELS (from last year)
 the point is that we need a place to discuss data plane elements that are in scope of the control plane thanks, - dimitri. &quot;Adrian Farrel&quot; &lt;<a href="mailto:adrian@olddog.co.uk">
adrian@olddog.co.uk</a>&gt; Sent by: <a href="mailto:owner-ccamp@ops.ietf.org">owner-ccamp@ops.ietf.org</a> 11/07/2006 15:35 Please respond to &quot;Adrian Farrel&quot; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; To:&nbsp;&nbsp;&nbsp;&nbsp; &quot;Don Fedyk&quot; &lt;
<a href="mailto:dwfedyk@nortel.com">dwfedyk@nortel.com</a>&gt;, Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; cc:&nbsp;&nbsp;&nbsp;&nbsp; &lt;<a href="mailto:ccamp@ops.ietf.org">ccamp@ops.ietf.org</a>&gt;, &lt;<a href="mailto:gels@rtg.ietf.org">
gels@rtg.ietf.org</a>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Re: Future of the GELS mailing list &gt; We have agreed we don't define the IEEE data planes in &gt; the IETF.&nbsp;&nbsp;But we will need a venue to discuss the profile
 &gt; of the data plane(s).&nbsp;&nbsp;A separate list may be useful. That was also my thinking, and I would prefer *that* discussion to not happen on the CCAMP list. Adrian _______________________________________________
 gels mailing list <a href="mailto:gels@rtg.ietf.org">gels@rtg.ietf.org</a> <a href="https://rtg.ietf.org/mailman/listinfo/gels">https://rtg.ietf.org/mailman/listinfo/gels</a> </blockquote></div>

------=_Part_104483_20182149.1152626448357--

Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 11 Jul 2006 13:57:26 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Future of the GELS mailing list
Date: Tue, 11 Jul 2006 09:56:16 -0400
Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA4096418EF@zrtphxm2.corp.nortel.com>
Thread-Topic: Future of the GELS mailing list
Thread-Index: Acak8C1qtfSbfFL+TKq+TDvycQpzswAACi3A
From: "Don Fedyk" <dwfedyk@nortel.com>
To: <Dimitri.Papadimitriou@alcatel.be>, "Adrian Farrel" <adrian@olddog.co.uk>
Cc: <ccamp@ops.ietf.org>, <gels@rtg.ietf.org>, <owner-ccamp@ops.ietf.org>

Hi Dimitri
> -----Original Message-----
> From: Dimitri.Papadimitriou@alcatel.be=20
>=20
> adrian & don
>=20
> > We have agreed we don't define the IEEE data planes in the IETF.
>=20
> this is agreed before starting GELS (from last year)

I was just reinforcing the point about what we profile on the data
plane.=20

>=20
> the point is that we need a place to discuss data plane=20
> elements that are in scope of the control plane

But many CCAMP people may not be interested in the details of that in
profile until it is finalized.=20
>=20
> thanks,
> - dimitri.
>=20
>=20
>=20
>=20
>=20
> "Adrian Farrel" <adrian@olddog.co.uk>
> Sent by: owner-ccamp@ops.ietf.org
> 11/07/2006 15:35
> Please respond to "Adrian Farrel"
> =20
>         To:     "Don Fedyk" <dwfedyk@nortel.com>, Dimitri=20
> PAPADIMITRIOU/BE/ALCATEL@ALCATEL
>         cc:     <ccamp@ops.ietf.org>, <gels@rtg.ietf.org>
>         Subject:        Re: Future of the GELS mailing list
>=20
>=20
> > We have agreed we don't define the IEEE data planes in the=20
> IETF.  But=20
> > we will need a venue to discuss the profile of the data=20
> plane(s).  A=20
> > separate list may be useful.
>=20
> That was also my thinking, and I would prefer *that*=20
> discussion to not happen on the CCAMP list.
>=20
> Adrian=20
>=20
>=20
>=20
>=20
>=20
>=20

Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 11 Jul 2006 13:44:53 +0000
To: "Adrian Farrel" <adrian@olddog.co.uk>
Cc: ccamp@ops.ietf.org, "Don Fedyk" <dwfedyk@nortel.com>, gels@rtg.ietf.org, owner-ccamp@ops.ietf.org
Subject: Re: Future of the GELS mailing list
MIME-Version: 1.0
Message-ID: <OF432D2F4F.01C01DF2-ONC12571A8.004B4305-C12571A8.004B73C3@netfr.alcatel.fr>
From: Dimitri.Papadimitriou@alcatel.be
Date: Tue, 11 Jul 2006 15:44:06 +0200
Content-Type: text/plain; charset="US-ASCII"

adrian & don

> We have agreed we don't define the IEEE data planes in the IETF.

this is agreed before starting GELS (from last year)

the point is that we need a place to discuss data plane elements that are 
in scope of the control plane

thanks,
- dimitri.

"Adrian Farrel" <adrian@olddog.co.uk>
Sent by: owner-ccamp@ops.ietf.org
11/07/2006 15:35
Please respond to "Adrian Farrel"

        To:     "Don Fedyk" <dwfedyk@nortel.com>, Dimitri 
PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     <ccamp@ops.ietf.org>, <gels@rtg.ietf.org>
        Subject:        Re: Future of the GELS mailing list

> We have agreed we don't define the IEEE data planes in
> the IETF.  But we will need a venue to discuss the profile
> of the data plane(s).  A separate list may be useful.

That was also my thinking, and I would prefer *that* discussion to not 
happen on the CCAMP list.

Adrian 

Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 11 Jul 2006 13:36:10 +0000
Message-ID: <02a601c6a4ee$f04519f0$e90ddb84@your029b8cecfe>
Reply-To: "Adrian Farrel" <adrian@olddog.co.uk>
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: "Don Fedyk" <dwfedyk@nortel.com>, <Dimitri.Papadimitriou@alcatel.be>
Cc: <ccamp@ops.ietf.org>, <gels@rtg.ietf.org>
Subject: Re: Future of the GELS mailing list
Date: Tue, 11 Jul 2006 14:35:49 +0100
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

> We have agreed we don't define the IEEE data planes in
> the IETF.  But we will need a venue to discuss the profile
> of the data plane(s).  A separate list may be useful.

That was also my thinking, and I would prefer *that* discussion to not 
happen on the CCAMP list.

Adrian 

Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 11 Jul 2006 13:34:34 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Future of the GELS mailing list
Date: Tue, 11 Jul 2006 16:34:09 +0200
Message-ID: <347D74C07C4F924091F863CBC284F41202CF543B@dove.seabridge.co.il>
Thread-Topic: Future of the GELS mailing list
Thread-Index: Acak9vsbHGB1X3E9SiGn2PNY+MqG0AAABOVA
From: "Nurit Sprecher" <nurit.sprecher@SeabridgeNetworks.com>
To: "Diego Caviglia" <Diego.Caviglia@marconi.com>, <dwfedyk@nortel.com>
Cc: "gels" <gels@rtg.ietf.org>, "ccamp" <ccamp@ops.ietf.org>, "<Dimitri.Papadimitriou" <Dimitri.Papadimitriou@alcatel.be>, "dpapadimitriou" <dpapadimitriou@psg.com>, " Adrian Farrel  <adrian" <adrian@olddog.co.uk>, "owner-ccamp" <owner-ccamp@ops.ietf.org>

TO me as well=20

-----Original Message-----
From: gels-bounces@rtg.ietf.org [mailto:gels-bounces@rtg.ietf.org] On
Behalf Of Diego Caviglia
Sent: Tuesday, July 11, 2006 15:32
To: dwfedyk@nortel.com
Cc: gels; ccamp; <Dimitri.Papadimitriou; dpapadimitriou; Adrian Farrel
<adrian; owner-ccamp
Subject: RE: Future of the GELS mailing list

Sounds good to me.

Diego

"Don Fedyk" <dwfedyk@nortel.com>@rtg.ietf.org on 11/07/2006 15.27.04

Sent by:    gels-bounces@rtg.ietf.org

To:    <Dimitri.Papadimitriou@alcatel.be>, "Adrian Farrel"
       <adrian@olddog.co.uk>
cc:    ccamp@ops.ietf.org, gels@rtg.ietf.org, owner-ccamp@ops.ietf.org,
       dpapadimitriou@psg.com

Subject:    RE: Future of the GELS mailing list

I too would be leery to shut down the list until CCAMP agreed to take on
the work as a charter item. I support the initiative but at the right
time.

We have agreed we don't define the IEEE data planes in the IETF.  But we
will need a venue to discuss the profile of the data plane(s).  A
separate list may be useful.

Don

> -----Original Message-----
> From: owner-ccamp@ops.ietf.org
> [mailto:owner-ccamp@ops.ietf.org] On Behalf Of=20
> Dimitri.Papadimitriou@alcatel.be
> Sent: Tuesday, July 11, 2006 8:17 AM
> To: Adrian Farrel
> Cc: ccamp@ops.ietf.org; gels@rtg.ietf.org; owner-ccamp@ops.ietf.org;=20
> dpapadimitriou@psg.com
> Subject: Re: Future of the GELS mailing list
>
> i can have different interpretations on why people are asking to=20
> shutdown the GELS list (so let's try one that goes beyond mailing list

> duplication which is oversimplistic)
>
> shutting down the list means that -de facto- agreement that this=20
> effort is committed and to be chartered as a control plane only work=20
> item @CCAMP with data plane "solutions"
> sitting outside IETF scope
>
> is my interpretation correct ?
>
> if yes - GELS mailing can be shut down -
>
> if not - it means we don't have agreement to continue this work either

> within GELS, CCAMP or whatsover
>
> let's have the real discussion.
>
>
>
>
>
> Monique Morrow <mmorrow@cisco.com>
> Sent by: owner-ccamp@ops.ietf.org
> 11/07/2006 11:34
>
>         To:     Adrian Farrel <adrian@olddog.co.uk>,
> <ccamp@ops.ietf.org>
>         cc:     <gels@rtg.ietf.org>
>         Subject:        Re: Future of the GELS mailing list
>
>
> Agree with shutting down the GELS list.
>
> /m
>
>
> On 10/7/06 7:35 pm, "Adrian Farrel" <adrian@olddog.co.uk> wrote:
>
> > Hi,
> >
> > We reached a sort-of decision in CCAMP today on the future of GELS.
> > You
> can
> > see this on the chairs slides at
> >
> http://www3.ietf.org/proceedings/06jul/slides/ccamp-15.ppt#286,8,GELS?
> >
> > One question remains.
> > Should the GELS mailing list continue or should all
> discussions move
> > to
> the
> > CCAMP list?
> >
> > I am personally inclined to think that the separate list is a useful
> venue
> > for discussions that might not be completely dedicated to GMPLS=20
> > protocol issues. On the other hand, maybe the WG would like all=20
> > discussions in
> the
> > same place.
> >
> > I would prefer that we stopped copying emails to both lists.
> >
> > Opinions?
> > Adrian
> >
>
>
>
>
>
>

_______________________________________________
gels mailing list
gels@rtg.ietf.org
https://rtg.ietf.org/mailman/listinfo/gels

_______________________________________________
gels mailing list
gels@rtg.ietf.org
https://rtg.ietf.org/mailman/listinfo/gels

Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 11 Jul 2006 13:32:01 +0000
Sensitivity: 
Subject: RE: Future of the GELS mailing list
To: dwfedyk@nortel.com
Cc: "<Dimitri.Papadimitriou" <Dimitri.Papadimitriou@alcatel.be>, ""Adrian Farrel" <adrian" <adrian@olddog.co.uk>, "ccamp" <ccamp@ops.ietf.org>, "gels" <gels@rtg.ietf.org>, "owner-ccamp" <owner-ccamp@ops.ietf.org>, "dpapadimitriou" <dpapadimitriou@psg.com>
Message-ID: <OF25E4BE01.85C084CF-ONC12571A8.004A4816-C12571A8.004A5C87@uk.marconicomms.com>
From: "Diego Caviglia" <Diego.Caviglia@marconi.com>
Date: Tue, 11 Jul 2006 15:31:45 +0200
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

Sounds good to me.

Diego

"Don Fedyk" <dwfedyk@nortel.com>@rtg.ietf.org on 11/07/2006 15.27.04

Sent by:    gels-bounces@rtg.ietf.org

To:    <Dimitri.Papadimitriou@alcatel.be>, "Adrian Farrel"
       <adrian@olddog.co.uk>
cc:    ccamp@ops.ietf.org, gels@rtg.ietf.org, owner-ccamp@ops.ietf.org,
       dpapadimitriou@psg.com

Subject:    RE: Future of the GELS mailing list

I too would be leery to shut down the list until CCAMP agreed to take on
the work as a charter item. I support the initiative but at the right
time.

We have agreed we don't define the IEEE data planes in the IETF.  But we
will need a venue to discuss the profile of the data plane(s).  A
separate list may be useful.

Don

> -----Original Message-----
> From: owner-ccamp@ops.ietf.org
> [mailto:owner-ccamp@ops.ietf.org] On Behalf Of
> Dimitri.Papadimitriou@alcatel.be
> Sent: Tuesday, July 11, 2006 8:17 AM
> To: Adrian Farrel
> Cc: ccamp@ops.ietf.org; gels@rtg.ietf.org;
> owner-ccamp@ops.ietf.org; dpapadimitriou@psg.com
> Subject: Re: Future of the GELS mailing list
>
> i can have different interpretations on why people are asking
> to shutdown the GELS list (so let's try one that goes beyond
> mailing list duplication which is oversimplistic)
>
> shutting down the list means that -de facto- agreement that
> this effort is committed and to be chartered as a control
> plane only work item @CCAMP with data plane "solutions"
> sitting outside IETF scope
>
> is my interpretation correct ?
>
> if yes - GELS mailing can be shut down -
>
> if not - it means we don't have agreement to continue this
> work either within GELS, CCAMP or whatsover
>
> let's have the real discussion.
>
>
>
>
>
> Monique Morrow <mmorrow@cisco.com>
> Sent by: owner-ccamp@ops.ietf.org
> 11/07/2006 11:34
>
>         To:     Adrian Farrel <adrian@olddog.co.uk>,
> <ccamp@ops.ietf.org>
>         cc:     <gels@rtg.ietf.org>
>         Subject:        Re: Future of the GELS mailing list
>
>
> Agree with shutting down the GELS list.
>
> /m
>
>
> On 10/7/06 7:35 pm, "Adrian Farrel" <adrian@olddog.co.uk> wrote:
>
> > Hi,
> >
> > We reached a sort-of decision in CCAMP today on the future of GELS.
> > You
> can
> > see this on the chairs slides at
> >
> http://www3.ietf.org/proceedings/06jul/slides/ccamp-15.ppt#286,8,GELS?
> >
> > One question remains.
> > Should the GELS mailing list continue or should all
> discussions move
> > to
> the
> > CCAMP list?
> >
> > I am personally inclined to think that the separate list is a useful
> venue
> > for discussions that might not be completely dedicated to GMPLS
> > protocol issues. On the other hand, maybe the WG would like all
> > discussions in
> the
> > same place.
> >
> > I would prefer that we stopped copying emails to both lists.
> >
> > Opinions?
> > Adrian
> >
>
>
>
>
>
>

_______________________________________________
gels mailing list
gels@rtg.ietf.org
https://rtg.ietf.org/mailman/listinfo/gels

Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 11 Jul 2006 13:28:00 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Future of the GELS mailing list
Date: Tue, 11 Jul 2006 09:27:04 -0400
Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA4096417F8@zrtphxm2.corp.nortel.com>
Thread-Topic: Future of the GELS mailing list
Thread-Index: Acak5AOdaN+PVPfwQz+vboAt1sV5IwACJeag
From: "Don Fedyk" <dwfedyk@nortel.com>
To: <Dimitri.Papadimitriou@alcatel.be>, "Adrian Farrel" <adrian@olddog.co.uk>
Cc: <ccamp@ops.ietf.org>, <gels@rtg.ietf.org>, <owner-ccamp@ops.ietf.org>, <dpapadimitriou@psg.com>

I too would be leery to shut down the list until CCAMP agreed to take on
the work as a charter item. I support the initiative but at the right
time.=20

We have agreed we don't define the IEEE data planes in the IETF.  But we
will need a venue to discuss the profile of the data plane(s).  A
separate list may be useful.    =20

Don  =20

> -----Original Message-----
> From: owner-ccamp@ops.ietf.org=20
> [mailto:owner-ccamp@ops.ietf.org] On Behalf Of=20
> Dimitri.Papadimitriou@alcatel.be
> Sent: Tuesday, July 11, 2006 8:17 AM
> To: Adrian Farrel
> Cc: ccamp@ops.ietf.org; gels@rtg.ietf.org;=20
> owner-ccamp@ops.ietf.org; dpapadimitriou@psg.com
> Subject: Re: Future of the GELS mailing list
>=20
> i can have different interpretations on why people are asking=20
> to shutdown the GELS list (so let's try one that goes beyond=20
> mailing list duplication which is oversimplistic)
>=20
> shutting down the list means that -de facto- agreement that=20
> this effort is committed and to be chartered as a control=20
> plane only work item @CCAMP with data plane "solutions"=20
> sitting outside IETF scope
>=20
> is my interpretation correct ?
>=20
> if yes - GELS mailing can be shut down -
>=20
> if not - it means we don't have agreement to continue this=20
> work either within GELS, CCAMP or whatsover
>=20
> let's have the real discussion.
>=20
>=20
>=20
>=20
>=20
> Monique Morrow <mmorrow@cisco.com>
> Sent by: owner-ccamp@ops.ietf.org
> 11/07/2006 11:34
> =20
>         To:     Adrian Farrel <adrian@olddog.co.uk>,=20
> <ccamp@ops.ietf.org>
>         cc:     <gels@rtg.ietf.org>
>         Subject:        Re: Future of the GELS mailing list
>=20
>=20
> Agree with shutting down the GELS list.
>=20
> /m
>=20
>=20
> On 10/7/06 7:35 pm, "Adrian Farrel" <adrian@olddog.co.uk> wrote:
>=20
> > Hi,
> >=20
> > We reached a sort-of decision in CCAMP today on the future of GELS.=20
> > You
> can
> > see this on the chairs slides at
> >=20
> http://www3.ietf.org/proceedings/06jul/slides/ccamp-15.ppt#286,8,GELS?
> >=20
> > One question remains.
> > Should the GELS mailing list continue or should all=20
> discussions move=20
> > to
> the
> > CCAMP list?
> >=20
> > I am personally inclined to think that the separate list is a useful
> venue
> > for discussions that might not be completely dedicated to GMPLS=20
> > protocol issues. On the other hand, maybe the WG would like all=20
> > discussions in
> the
> > same place.
> >=20
> > I would prefer that we stopped copying emails to both lists.
> >=20
> > Opinions?
> > Adrian
> >=20
>=20
>=20
>=20
>=20
>=20
>=20

Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 11 Jul 2006 13:25:51 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Future of the GELS mailing list
Date: Tue, 11 Jul 2006 16:25:21 +0200
Message-ID: <347D74C07C4F924091F863CBC284F41202CF5406@dove.seabridge.co.il>
Thread-Topic: Future of the GELS mailing list
Thread-Index: Acak9aGmATL7wIhnRYW9AmvjKNmorQAADKyA
From: "Nurit Sprecher" <nurit.sprecher@SeabridgeNetworks.com>
To: <Dimitri.Papadimitriou@alcatel.be>, "Ping Pan" <ppan@hammerheadsystems.com>
Cc: <ccamp@ops.ietf.org>, "Adrian Farrel" <adrian@olddog.co.uk>, <gels@rtg.ietf.org>, <gels-bounces@rtg.ietf.org>, <dpapadimitriou@psg.com>

I agree.
=20

-----Original Message-----
From: gels-bounces@rtg.ietf.org [mailto:gels-bounces@rtg.ietf.org] On
Behalf Of Dimitri.Papadimitriou@alcatel.be
Sent: Tuesday, July 11, 2006 15:21
To: Ping Pan
Cc: ccamp@ops.ietf.org; Adrian Farrel; gels@rtg.ietf.org;
gels-bounces@rtg.ietf.org; dpapadimitriou@psg.com
Subject: RE: Future of the GELS mailing list

ping - this is exactly my point -=20

-d.

"Ping Pan" <ppan@hammerheadsystems.com>
Sent by: gels-bounces@rtg.ietf.org
11/07/2006 14:33
=20
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Adrian
Farrel"=20
<adrian@olddog.co.uk>
        cc:     ccamp@ops.ietf.org, gels@rtg.ietf.org,=20
dpapadimitriou@psg.com
        Subject:        RE: Future of the GELS mailing list

To make sure further work will be done in GELS, I would think that we
should keep the GELS mailing open until it is within the charter of one
of the WG's.

Yes, let's have the real discussion.

- Ping

-----Original Message-----
From: gels-bounces@rtg.ietf.org [mailto:gels-bounces@rtg.ietf.org] On
Behalf Of Dimitri.Papadimitriou@alcatel.be
Sent: Tuesday, July 11, 2006 5:17 AM
To: Adrian Farrel
Cc: ccamp@ops.ietf.org; gels@rtg.ietf.org; owner-ccamp@ops.ietf.org;
dpapadimitriou@psg.com
Subject: Re: Future of the GELS mailing list

i can have different interpretations on why people are asking to
shutdown the GELS list (so let's try one that goes beyond mailing list
duplication which is oversimplistic)

shutting down the list means that -de facto- agreement that this effort
is committed and to be chartered as a control plane only work item
@CCAMP with data plane "solutions" sitting outside IETF scope

is my interpretation correct ?

if yes - GELS mailing can be shut down -

if not - it means we don't have agreement to continue this work either
within GELS, CCAMP or whatsover

let's have the real discussion.

Monique Morrow <mmorrow@cisco.com>
Sent by: owner-ccamp@ops.ietf.org
11/07/2006 11:34
=20
        To:     Adrian Farrel <adrian@olddog.co.uk>,
<ccamp@ops.ietf.org>
        cc:     <gels@rtg.ietf.org>
        Subject:        Re: Future of the GELS mailing list

Agree with shutting down the GELS list.

/m

On 10/7/06 7:35 pm, "Adrian Farrel" <adrian@olddog.co.uk> wrote:

> Hi,
>=20
> We reached a sort-of decision in CCAMP today on the future of GELS.=20
> You
can
> see this on the chairs slides at
> http://www3.ietf.org/proceedings/06jul/slides/ccamp-15.ppt#286,8,GELS?
>=20
> One question remains.
> Should the GELS mailing list continue or should all discussions move=20
> to
the
> CCAMP list?
>=20
> I am personally inclined to think that the separate list is a useful
venue
> for discussions that might not be completely dedicated to GMPLS=20
> protocol issues. On the other hand, maybe the WG would like all=20
> discussions in
the
> same place.
>=20
> I would prefer that we stopped copying emails to both lists.
>=20
> Opinions?
> Adrian
>=20

_______________________________________________
gels mailing list
gels@rtg.ietf.org
https://rtg.ietf.org/mailman/listinfo/gels

_______________________________________________
gels mailing list
gels@rtg.ietf.org
https://rtg.ietf.org/mailman/listinfo/gels

_______________________________________________
gels mailing list
gels@rtg.ietf.org
https://rtg.ietf.org/mailman/listinfo/gels

Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 11 Jul 2006 13:21:59 +0000
To: "Ping Pan" <ppan@hammerheadsystems.com>
Cc: "Adrian Farrel" <adrian@olddog.co.uk>, ccamp@ops.ietf.org, dpapadimitriou@psg.com, gels@rtg.ietf.org, gels-bounces@rtg.ietf.org
Subject: RE: Future of the GELS mailing list
MIME-Version: 1.0
Message-ID: <OF3D444E49.DECC2702-ONC12571A8.00484467-C12571A8.0049550B@netfr.alcatel.fr>
From: Dimitri.Papadimitriou@alcatel.be
Date: Tue, 11 Jul 2006 15:20:57 +0200
Content-Type: text/plain; charset="US-ASCII"

ping - this is exactly my point - 

-d.

"Ping Pan" <ppan@hammerheadsystems.com>
Sent by: gels-bounces@rtg.ietf.org
11/07/2006 14:33

        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Adrian Farrel" 
<adrian@olddog.co.uk>
        cc:     ccamp@ops.ietf.org, gels@rtg.ietf.org, 
dpapadimitriou@psg.com
        Subject:        RE: Future of the GELS mailing list

To make sure further work will be done in GELS, I would think that we
should keep the GELS mailing open until it is within the charter of one
of the WG's.

Yes, let's have the real discussion.

- Ping

-----Original Message-----
From: gels-bounces@rtg.ietf.org [mailto:gels-bounces@rtg.ietf.org] On
Behalf Of Dimitri.Papadimitriou@alcatel.be
Sent: Tuesday, July 11, 2006 5:17 AM
To: Adrian Farrel
Cc: ccamp@ops.ietf.org; gels@rtg.ietf.org; owner-ccamp@ops.ietf.org;
dpapadimitriou@psg.com
Subject: Re: Future of the GELS mailing list

i can have different interpretations on why people are asking to
shutdown the GELS list (so let's try one that goes beyond mailing list
duplication which is oversimplistic)

shutting down the list means that -de facto- agreement that this effort
is committed and to be chartered as a control plane only work item
@CCAMP with data plane "solutions" sitting outside IETF scope

is my interpretation correct ?

if yes - GELS mailing can be shut down -

if not - it means we don't have agreement to continue this work either
within GELS, CCAMP or whatsover

let's have the real discussion.

Monique Morrow <mmorrow@cisco.com>
Sent by: owner-ccamp@ops.ietf.org
11/07/2006 11:34

        To:     Adrian Farrel <adrian@olddog.co.uk>,
<ccamp@ops.ietf.org>
        cc:     <gels@rtg.ietf.org>
        Subject:        Re: Future of the GELS mailing list

Agree with shutting down the GELS list.

/m

On 10/7/06 7:35 pm, "Adrian Farrel" <adrian@olddog.co.uk> wrote:

> Hi,
> 
> We reached a sort-of decision in CCAMP today on the future of GELS. 
> You
can
> see this on the chairs slides at
> http://www3.ietf.org/proceedings/06jul/slides/ccamp-15.ppt#286,8,GELS?
> 
> One question remains.
> Should the GELS mailing list continue or should all discussions move 
> to
the
> CCAMP list?
> 
> I am personally inclined to think that the separate list is a useful
venue
> for discussions that might not be completely dedicated to GMPLS 
> protocol issues. On the other hand, maybe the WG would like all 
> discussions in
the
> same place.
> 
> I would prefer that we stopped copying emails to both lists.
> 
> Opinions?
> Adrian
> 

_______________________________________________
gels mailing list
gels@rtg.ietf.org
https://rtg.ietf.org/mailman/listinfo/gels

_______________________________________________
gels mailing list
gels@rtg.ietf.org
https://rtg.ietf.org/mailman/listinfo/gels

Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 11 Jul 2006 12:17:35 +0000
To: Adrian Farrel <adrian@olddog.co.uk>
Cc: ccamp@ops.ietf.org, gels@rtg.ietf.org, owner-ccamp@ops.ietf.org, dpapadimitriou@psg.com
Subject: Re: Future of the GELS mailing list
MIME-Version: 1.0
Message-ID: <OF6E181DCF.41B6AA9E-ONC12571A8.0041C3E0-C12571A8.00437202@netfr.alcatel.fr>
From: Dimitri.Papadimitriou@alcatel.be
Date: Tue, 11 Jul 2006 14:16:39 +0200
Content-Type: text/plain; charset="US-ASCII"

i can have different interpretations on why people are asking to shutdown 
the GELS list (so let's try one that goes beyond mailing list duplication 
which is oversimplistic)

shutting down the list means that -de facto- agreement that this effort is 
committed and to be chartered as a control plane only work item @CCAMP 
with data plane "solutions" sitting outside IETF scope

is my interpretation correct ?

if yes - GELS mailing can be shut down -

if not - it means we don't have agreement to continue this work either 
within GELS, CCAMP or whatsover

let's have the real discussion.

Monique Morrow <mmorrow@cisco.com>
Sent by: owner-ccamp@ops.ietf.org
11/07/2006 11:34

        To:     Adrian Farrel <adrian@olddog.co.uk>, <ccamp@ops.ietf.org>
        cc:     <gels@rtg.ietf.org>
        Subject:        Re: Future of the GELS mailing list

Agree with shutting down the GELS list.

/m

On 10/7/06 7:35 pm, "Adrian Farrel" <adrian@olddog.co.uk> wrote:

> Hi,
> 
> We reached a sort-of decision in CCAMP today on the future of GELS. You 
can
> see this on the chairs slides at
> http://www3.ietf.org/proceedings/06jul/slides/ccamp-15.ppt#286,8,GELS?
> 
> One question remains.
> Should the GELS mailing list continue or should all discussions move to 
the
> CCAMP list?
> 
> I am personally inclined to think that the separate list is a useful 
venue
> for discussions that might not be completely dedicated to GMPLS protocol
> issues. On the other hand, maybe the WG would like all discussions in 
the
> same place.
> 
> I would prefer that we stopped copying emails to both lists.
> 
> Opinions?
> Adrian 
> 

Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 11 Jul 2006 09:49:26 +0000
User-Agent: Microsoft-Entourage/11.2.4.060510
Date: Tue, 11 Jul 2006 05:34:33 -0400
Subject: Re: Future of the GELS mailing list
From: Monique Morrow <mmorrow@cisco.com>
To: Adrian Farrel <adrian@olddog.co.uk>, <ccamp@ops.ietf.org>
CC: <gels@rtg.ietf.org>
Message-ID: <C0D8E8E9.28613%mmorrow@cisco.com>
Thread-Topic: Future of the GELS mailing list
Thread-Index: AcakzTdRdgUXOBDAEduB6QANk8LkKg==
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit

Agree with shutting down the GELS list.

/m

On 10/7/06 7:35 pm, "Adrian Farrel" <adrian@olddog.co.uk> wrote:

> Hi,
> 
> We reached a sort-of decision in CCAMP today on the future of GELS. You can
> see this on the chairs slides at
> http://www3.ietf.org/proceedings/06jul/slides/ccamp-15.ppt#286,8,GELS?
> 
> One question remains.
> Should the GELS mailing list continue or should all discussions move to the
> CCAMP list?
> 
> I am personally inclined to think that the separate list is a useful venue
> for discussions that might not be completely dedicated to GMPLS protocol
> issues. On the other hand, maybe the WG would like all discussions in the
> same place.
> 
> I would prefer that we stopped copying emails to both lists.
> 
> Opinions?
> Adrian 
> 

Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 11 Jul 2006 05:58:06 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6A4AE.C5692B4D"
Subject: RE: Future of the GELS mailing list
Date: Tue, 11 Jul 2006 01:56:34 -0400
Message-ID: <BABC859E6D0B9A4D8448CC7F41CD2B07020668BD@xmb-rtp-203.amer.cisco.com>
Thread-Topic: Future of the GELS mailing list
Thread-Index: AcakfzOfbDXOqln6SayTU3/LMeKQ+wAL3waQ
From: "Zafar Ali $zali$" <zali@cisco.com>
To: "Andrew G. Malis" <agmalis@gmail.com>, "Adrian Farrel" <adrian@olddog.co.uk>
Cc: <ccamp@ops.ietf.org>, <gels@rtg.ietf.org>
DKIM-Signature: a=rsa-sha1; q=dns; l=5093; t=1152597398; x=1153461398; c=relaxed/simple; s=sjdkim6001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=zali@cisco.com; z=From:=22Zafar=20Ali=20$zali$=22=20<zali@cisco.com> |Subject:RE=3A=20Future=20of=20the=20GELS=20mailing=20list; X=v=3Dcisco.com=3B=20h=3DOccBOx7CPhyni94g+9U0bcoT04E=3D; b=fuThaJ/AhvPB5gKOvgC9VXKw9R4uQ2hyq1lZcyZGYqEIBxyX91jpgefz9kZuBko7Em/jGTvW zsxc3TcOkhxSxqG24U5ayxAjkfrTeYVATANzce2AAzErWLVMEzjVPb55;
Authentication-Results: sj-dkim-6.cisco.com; header.From=zali@cisco.com; dkim=pass ( 59 extraneous bytes; sig from cisco.com verified; );

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6A4AE.C5692B4D
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

=20

________________________________

	From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]
On Behalf Of Andrew G. Malis
	Sent: Monday, July 10, 2006 8:15 PM
	To: Adrian Farrel
	Cc: ccamp@ops.ietf.org; gels@rtg.ietf.org
	Subject: Re: Future of the GELS mailing list
=09
=09
	Adrian,
=09
	I would suggest shutting down the gels list.  =20
	=20

I agree w/ shutting down the gels list.=20
=20
Thanks
=20
Regards... Zafar=20

	=20
	 That would guarantee that we only see the messages once.
=09
	Cheers,
	Andy
=09
=09
	On 7/10/06, Adrian Farrel <adrian@olddog.co.uk> wrote:=20

		Hi,
	=09
		We reached a sort-of decision in CCAMP today on the
future of GELS. You can
		see this on the chairs slides at
=09
http://www3.ietf.org/proceedings/06jul/slides/ccamp-15.ppt#286,8,GELS ?
	=09
		One question remains.
		Should the GELS mailing list continue or should all
discussions move to the
		CCAMP list?
	=09
		I am personally inclined to think that the separate list
is a useful venue
		for discussions that might not be completely dedicated
to GMPLS protocol=20
		issues. On the other hand, maybe the WG would like all
discussions in the
		same place.
	=09
		I would prefer that we stopped copying emails to both
lists.
	=09
		Opinions?
		Adrian
	=09

------_=_NextPart_001_01C6A4AE.C5692B4D
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1543" name=3DGENERATOR></HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft>&nbsp;</DIV> 
<BLOCKQUOTE=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
 <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
 <HR tabIndex=3D-1>
 From: owner-ccamp@ops.ietf.org=20
 [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Andrew G.=20
 Malis Sent: Monday, July 10, 2006 8:15 PM To: =
Adrian=20
 Farrel Cc: ccamp@ops.ietf.org; =
gels@rtg.ietf.org Subject:=20
 Re: Future of the GELS mailing list </DIV>
 <DIV></DIV>
 <DIV>Adrian, I would suggest shutting down the gels=20
 list.&nbsp;&nbsp;&nbsp;</DIV>
 <DIV>&nbsp;</DIV></BLOCKQUOTE>
<DIV>I=20
agree w/ shutting down the gels list. </DIV>
<DIV><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D731005605-11072006><FONT face=3DArial color=3D#0000ff =

size=3D2>Thanks</FONT></SPAN></DIV>
<DIV><SPAN class=3D731005605-11072006><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D731005605-11072006><FONT face=3DArial color=3D#0000ff =

size=3D2>Regards... Zafar </FONT></SPAN></DIV>
<BLOCKQUOTE=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV><SPAN class=3D731005605-11072006><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D731005605-11072006>&nbsp;</SPAN>That would =
guarantee that we=20
  only see the messages once.<BR><BR>Cheers,<BR>Andy<BR><BR></DIV>
  <DIV><SPAN class=3Dgmail_quote>On 7/10/06, <B =
class=3Dgmail_sendername>Adrian=20
  Farrel </B>&lt;<A=20
  href=3D"mailto:adrian@olddog.co.uk">adrian@olddog.co.uk</A>&gt; =
wrote:</SPAN>
  <BLOCKQUOTE class=3Dgmail_quote=20
  style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: =
#cccccc 1px solid">Hi,<BR><BR>We=20
    reached a sort-of decision in CCAMP today on the future of GELS. You =

    can<BR>see this on the chairs slides at<BR><A=20
    =
href=3D"http://www3.ietf.org/proceedings/06jul/slides/ccamp-15.ppt#286,8,=
GELS">http://www3.ietf.org/proceedings/06jul/slides/ccamp-15.ppt#286,8,GE=
LS=20
    </A>?<BR><BR>One question remains.<BR>Should the GELS mailing list =
continue=20
    or should all discussions move to the<BR>CCAMP list?<BR><BR>I am =
personally=20
    inclined to think that the separate list is a useful venue<BR>for=20
    discussions that might not be completely dedicated to GMPLS protocol =

    <BR>issues. On the other hand, maybe the WG would like all =
discussions in=20
    the<BR>same place.<BR><BR>I would prefer that we stopped copying =
emails to=20
    both=20
lists.<BR><BR>Opinions?<BR>Adrian<BR></BLOCKQUOTE></DIV><BR></BLOCKQUOTE>=
</BODY></HTML>

------_=_NextPart_001_01C6A4AE.C5692B4D--

Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 11 Jul 2006 02:19:32 +0000
Date: Mon, 10 Jul 2006 21:21:26 -0500
From: YongLucy 73674 <lucyyong@huawei.com>
Subject: Re: Future of the GELS mailing list
To: "Andrew G. Malis" <agmalis@gmail.com>
Cc: Adrian Farrel <adrian@olddog.co.uk>, ccamp@ops.ietf.org, gels@rtg.ietf.org
Message-id: <188c79187135.187135188c79@huawei.com>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline

make sense. support!

*******************************************************************************************
 This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!
 *******************************************************************************************

----- Original Message -----
From: "Andrew G. Malis" <agmalis@gmail.com>
Date: Monday, July 10, 2006 7:14 pm
Subject: Re: Future of the GELS mailing list

> Adrian,
> 
> I would suggest shutting down the gels list.  That would guarantee 
> that we
> only see the messages once.
> 
> Cheers,
> Andy
> 
> On 7/10/06, Adrian Farrel <adrian@olddog.co.uk> wrote:
> >
> > Hi,
> >
> > We reached a sort-of decision in CCAMP today on the future of 
> GELS. You
> > can
> > see this on the chairs slides at
> > http://www3.ietf.org/proceedings/06jul/slides/ccamp-
> 15.ppt#286,8,GELS?>
> > One question remains.
> > Should the GELS mailing list continue or should all discussions 
> move to
> > the
> > CCAMP list?
> >
> > I am personally inclined to think that the separate list is a 
> useful venue
> > for discussions that might not be completely dedicated to GMPLS 
> protocol> issues. On the other hand, maybe the WG would like all 
> discussions in the
> > same place.
> >
> > I would prefer that we stopped copying emails to both lists.
> >
> > Opinions?
> > Adrian
> >
> 

Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 11 Jul 2006 00:15:53 +0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=h2bti99B0xGBvFcPk5MJfBi6WxdJWmMoyGxiXfh52j/oHwuUOy6rGLWTZSZboIINGee7qO73MaUoaGuQziiHYPdye5/Q3H/bNjVASRBAd++JVR+UmEP+e/hZpXopBRX8ei1/svEF0rbsdCdR84Bxp5yJ3q0ahJAerEDPmVn+lZ0=
Message-ID: <8c99930d0607101714q2d9973f6hd559c461150a4781@mail.gmail.com>
Date: Mon, 10 Jul 2006 20:14:57 -0400
From: "Andrew G. Malis" <agmalis@gmail.com>
To: "Adrian Farrel" <adrian@olddog.co.uk>
Subject: Re: Future of the GELS mailing list
Cc: ccamp@ops.ietf.org, gels@rtg.ietf.org
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_99219_23197649.1152576897164"

------=_Part_99219_23197649.1152576897164
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Adrian,

I would suggest shutting down the gels list.  That would guarantee that we
only see the messages once.

Cheers,
Andy

On 7/10/06, Adrian Farrel <adrian@olddog.co.uk> wrote:
>
> Hi,
>
> We reached a sort-of decision in CCAMP today on the future of GELS. You
> can
> see this on the chairs slides at
> http://www3.ietf.org/proceedings/06jul/slides/ccamp-15.ppt#286,8,GELS?
>
> One question remains.
> Should the GELS mailing list continue or should all discussions move to
> the
> CCAMP list?
>
> I am personally inclined to think that the separate list is a useful venue
> for discussions that might not be completely dedicated to GMPLS protocol
> issues. On the other hand, maybe the WG would like all discussions in the
> same place.
>
> I would prefer that we stopped copying emails to both lists.
>
> Opinions?
> Adrian
>

------=_Part_99219_23197649.1152576897164
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Adrian, I would suggest shutting down the gels list. &nbsp;That would guarantee that we only see the messages once. Cheers, Andy <div>On 7/10/06, Adrian Farrel
 &lt;<a href="mailto:adrian@olddog.co.uk">adrian@olddog.co.uk</a>&gt; wrote:<blockquote class="gmail_quote" style="margin-top: 0; margin-right: 0; margin-bottom: 0; margin-left: 0; margin-left: 0.80ex; border-left-color: #cccccc; border-left-width: 1px; border-left-style: solid; padding-left: 1ex">
Hi, We reached a sort-of decision in CCAMP today on the future of GELS. You can see this on the chairs slides at <a href="http://www3.ietf.org/proceedings/06jul/slides/ccamp-15.ppt#286,8,GELS">http://www3.ietf.org/proceedings/06jul/slides/ccamp-15.ppt#286,8,GELS
</a>? One question remains. Should the GELS mailing list continue or should all discussions move to the CCAMP list? I am personally inclined to think that the separate list is a useful venue for discussions that might not be completely dedicated to GMPLS protocol
 issues. On the other hand, maybe the WG would like all discussions in the same place. I would prefer that we stopped copying emails to both lists. Opinions? Adrian </blockquote></div>

------=_Part_99219_23197649.1152576897164--

Envelope-to: ccamp-data@psg.com
Delivery-date: Mon, 10 Jul 2006 23:36:53 +0000
Message-ID: <01d401c6a479$7ab92570$e90ddb84@your029b8cecfe>
Reply-To: "Adrian Farrel" <adrian@olddog.co.uk>
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: <ccamp@ops.ietf.org>
Cc: <gels@rtg.ietf.org>
Subject: Future of the GELS mailing list
Date: Tue, 11 Jul 2006 00:35:01 +0100
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Hi,

We reached a sort-of decision in CCAMP today on the future of GELS. You can 
see this on the chairs slides at 
http://www3.ietf.org/proceedings/06jul/slides/ccamp-15.ppt#286,8,GELS?

One question remains.
Should the GELS mailing list continue or should all discussions move to the 
CCAMP list?

I am personally inclined to think that the separate list is a useful venue 
for discussions that might not be completely dedicated to GMPLS protocol 
issues. On the other hand, maybe the WG would like all discussions in the 
same place.

I would prefer that we stopped copying emails to both lists.

Opinions?
Adrian 

Envelope-to: ccamp-data@psg.com
Delivery-date: Mon, 10 Jul 2006 18:33:01 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: High level comment on draft-li-ccamp-confirm-data-channel-status-00.txt, 
Date: Mon, 10 Jul 2006 20:31:42 +0200
Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB02603A53006@FTRDMEL2.rd.francetelecom.fr>
Thread-Topic: High level comment on draft-li-ccamp-confirm-data-channel-status-00.txt, 
Thread-Index: AcajyhK/tBTLSTDlQnagl/WovUYgAwAfvSVA
From: "MEURIC Julien RD-CORE-LAN" <julien.meuric@orange-ft.com>
To: "Zafar Ali \(zali\)" <zali@cisco.com>, <xuhuiying@huawei.com>, <danli@huawei.com>
Cc: "ccamp" <ccamp@ops.ietf.org>

Hi Zafar.

I don't really get you on this. I figure out you're referring to
removing the connection states when RSVP refreshes are not received any
more, aren't you? If so, I'm afraid this is not enough for transmission
devices, where resources can be physically cross-connected even though
there is no (or no longer) corresponding RSVP state. Therefore having a
mechanism to avoid such discrepancies would be welcome.

Regards,

Julien

P.S.: If you totally rely on a management plane, I agree this should be
useless (e.g. the NMS should already know if a cross-connection deletion
failed, cf. Diego's 2nd slides seen this morning).

________________________________

From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On
Behalf Of Zafar Ali (zali)

Dear Authors,=20
=20
RSVP refreshes do this job, so I am not sure motivation for this draft/
LMP extensions.=20
=20
n.b. The draft state, "Although such a situation can be resolved through
the use of the Acceptable Label Set object in GMPLS signaling [RFC3473],
such a procedure is inefficient since it may require an additional
signaling exchange for each LSP that is set up", so I assume that RSVP
signaling is present (Although I did not understand the quoted statement
from the ID). Even if RSVP is not present, e.g., optical core is
completely controlled by a management entity, I would argue introduce
presence of LMP.=20
=20
Thanks
=20
Regards... Zafar=20

Envelope-to: ccamp-data@psg.com
Delivery-date: Mon, 10 Jul 2006 15:09:55 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: Discussion on draft-fedyk-gmpls-ethernet-pbt-00.txt
Date: Mon, 10 Jul 2006 11:07:24 -0400
Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA4095B9548@zrtphxm2.corp.nortel.com>
Thread-Topic: Discussion on draft-fedyk-gmpls-ethernet-pbt-00.txt
Thread-Index: AcakMozMIqVnesiXRfCJBLEdGv1VNg==
From: "Don Fedyk" <dwfedyk@nortel.com>
To: <ccamp@ops.ietf.org>, <gels@rtg.ietf.org>
Cc: "David Allan" <dallan@nortel.com>, <hshah@ciena.com>

Hi

There has been some positive discussion around our proposal to use GMPLS
for the control of Provider Backbone Transport. The WG chairs/ADs asked
us to keep data plane discussions to a minimum in the IETF. Our draft
describes PBT as Ethernet without a Spanning tree IEEE control plane and
optionally using a GMPLS control plane.

We would like to have a face to face meeting on the subject to:

- Get comments on the draft related to GMPLS.=20
- Suggestions for moving forward in the IETF.=20

We have booked the ROOM 522a at 3:30-4:30 Monday July 10th. Caveat the
room seats 10 people comfortably so: Could you indicate if you think
this is something you would like to participate RSVP to me. If I get
much more that 15 responses we will have to find an alternative venue.
Also some people will not be able to make this time we may have another
meeting Thursday Morning please let us know your preference.=20

Thanks,
Don and authors.=20

Envelope-to: ccamp-data@psg.com
Delivery-date: Mon, 10 Jul 2006 12:08:29 +0000
Message-ID: <004201c6a419$5f97cf40$e90ddb84@your029b8cecfe>
Reply-To: "Adrian Farrel" <adrian@olddog.co.uk>
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: <ccamp@ops.ietf.org>
Subject: Agenda and slides uploaded
Date: Mon, 10 Jul 2006 13:07:03 +0100
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Hi,

Just in time working group management.

http://www3.ietf.org/proceedings/06jul/agenda/ccamp.htm

Adrian

Envelope-to: ccamp-data@psg.com
Delivery-date: Mon, 10 Jul 2006 06:09:29 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6A3E7.3526584D"
Subject: Any objection on recommending upstream and downstream component links to be the same, 
Date: Mon, 10 Jul 2006 02:08:01 -0400
Message-ID: <BABC859E6D0B9A4D8448CC7F41CD2B070206646B@xmb-rtp-203.amer.cisco.com>
Thread-Topic: Any objection on recommending upstream and downstream component links to be the same, 
Thread-Index: Acaj5zKDjqHYb9J2Ryis0vT30/tI6Q==
From: "Zafar Ali \(zali\)" <zali@cisco.com>
To: "ccamp" <ccamp@ops.ietf.org>
Cc: "Richard Rabbat" <richard@us.fujitsu.com>, "Kohei Shiomoto" <shiomoto.kohei@lab.ntt.co.jp>, "Rajiv Papneja" <rpapneja@isocore.com>
DKIM-Signature: a=rsa-sha1; q=dns; l=2771; t=1152511688; x=1153375688; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=zali@cisco.com; z=From:=22Zafar=20Ali=20\(zali\)=22=20<zali@cisco.com> |Subject:Any=20objection=20on=20recommending=20upstream=20and=20downstream=20comp onent=20links=20to=20be=20the=20same,=20 |To:=22ccamp=22=20<ccamp@ops.ietf.org>; X=v=3Dcisco.com=3B=20h=3Drz3x9nD+zpHiaaeZHqJMiim0JAE=3D; b=xl5f19CINOrVW3dFQomI1Qv53BlCWZ2Gt3+2ydBFWFd6dKBpre3II1Dq1vvo2n8ETxj7GmUA /E3atAP7x7l4r6ox0en1A01R9I5+78t9Pr/XVcXXLPQasFefoNCIpUl7;
Authentication-Results: rtp-dkim-2.cisco.com; header.From=zali@cisco.com; dkim=pass ( 59 extraneous bytes; sig from cisco.com verified; );

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6A3E7.3526584D
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

Dear CCAMP-ers/ authors of addressing-id,=20
=20
While section "7.2. Component Link Identification" in
draft-ietf-ccamp-gmpls-addressing-04.txt is at this subject, I would
suggest that this draft puts forward a RECOMMENDATION for making
upstream and downstream component links to be the same.=20
=20
Thanks
=20
Regards... Zafar=20

------_=_NextPart_001_01C6A3E7.3526584D
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1543" name=3DGENERATOR></HEAD>
<BODY>
<DIV>Dear CCAMP-ers/ authors of =
addressing-id,=20
</DIV>
<DIV>&nbsp;</DIV>
<DIV>While section "7.2. Component Link =

Identification" in&nbsp;<?xml:namespace prefix =3D o ns =3D=20
"urn:schemas-microsoft-com:office:office" /><o:p></o:p><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'MS Mincho'; mso-ansi-language: EN-US; =
mso-fareast-language: JA; mso-bidi-language: =
AR-SA">draft-ietf-ccamp-gmpls-addressing-04.txt=20
is at this subject,&nbsp;I would suggest that&nbsp;this draft puts =
forward=20
a&nbsp;RECOMMENDATION for making upstream and downstream component links =
to be=20
the same. </DIV>
<DIV><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'MS Mincho'; mso-ansi-language: EN-US; =
mso-fareast-language: JA; mso-bidi-language: =
AR-SA">&nbsp;</DIV>
<DIV><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'MS Mincho'; mso-ansi-language: EN-US; =
mso-fareast-language: JA; mso-bidi-language: =
AR-SA">Thanks</DIV>
<DIV><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'MS Mincho'; mso-ansi-language: EN-US; =
mso-fareast-language: JA; mso-bidi-language: AR-SA"><FONT=20
face=3DArial size=3D2>&nbsp;</DIV>
<DIV><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'MS Mincho'; mso-ansi-language: EN-US; =
mso-fareast-language: JA; mso-bidi-language: AR-SA">Regards...=20
Zafar </DIV></BODY></HTML>

------_=_NextPart_001_01C6A3E7.3526584D--

Envelope-to: ccamp-data@psg.com
Delivery-date: Mon, 10 Jul 2006 03:05:00 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6A3CD.8D339B2D"
Subject: Comments on draft-li-ccamp-multinodes-gr-proc-00.txt, 
Date: Sun, 9 Jul 2006 23:04:23 -0400
Message-ID: <BABC859E6D0B9A4D8448CC7F41CD2B0702066437@xmb-rtp-203.amer.cisco.com>
Thread-Topic: Comments on draft-li-ccamp-multinodes-gr-proc-00.txt, 
Thread-Index: AcajzYu3Wna7e+MHRe2xxdCgls5b7A==
From: "Zafar Ali \(zali\)" <zali@cisco.com>
To: <danli@huawei.com>, <gjhhit@huawei.com>
Cc: "ccamp" <ccamp@ops.ietf.org>
DKIM-Signature: a=rsa-sha1; q=dns; l=4953; t=1152500666; x=1153364666; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=zali@cisco.com; z=From:=22Zafar=20Ali=20\(zali\)=22=20<zali@cisco.com> |Subject:Comments=20on=20draft-li-ccamp-multinodes-gr-proc-00.txt,=20 |To:<danli@huawei.com>,=20<gjhhit@huawei.com>; X=v=3Dcisco.com=3B=20h=3DlBipv95fPTUiCzc7qf0FNY9mZq4=3D; b=auMCWMHAgXSPPmb1nqqGIlyawn1wCevMFioSpVstjkYZV05PYDA8tiZhH9mgStYeed7XvPfU HZWb1lYPdyq5vzA9szzWmXZCI/BNGq7CmhGo8B3gX9ZSVnapZ+Ql0Fn8;
Authentication-Results: rtp-dkim-2.cisco.com; header.From=zali@cisco.com; dkim=pass ( 59 extraneous bytes; sig from cisco.com verified; );

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6A3CD.8D339B2D
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

Dear Authors,=20
=20
This is Deja-vu to me....=20
=20
Draft draft-ietf-ccamp-rsvp-restart-ext-05.txt actually had a section on
multiple node restart case and was rejected by the WG as addressing
multiple node restart case is NOT a goal (suffers from the law of
diminishing return). In other words the following statement in the ID-=20
=20
   "[GR-EXT] also extends the Hello message to exchange information
about=20
   the ability to support the RecoveryPath message.=20
   The examples and procedures in [GR-EXT] focus on the description of a

single node restart when adjacent network nodes are operative.=20
 Although the procedures are equally applicable to multi-node
restarts,=20
 no detailed explanation is provided."=20
=20
is not accurate. Please see section 4 on the earlier version of the
[GR-EXT],
http://www.faqs.org/ftp/pub/internet-drafts/draft-rahman-ccamp-rsvp-rest
art-extensions-00.txt
<http://www.faqs.org/ftp/pub/internet-drafts/draft-rahman-ccamp-rsvp-res
tart-extensions-00.txt> .=20
=20
Thanks
=20
Regards... Zafar=20
=20

------_=_NextPart_001_01C6A3CD.8D339B2D
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1543" name=3DGENERATOR></HEAD>
<BODY>
<DIV>Dear =
Authors,=20
</DIV>
<DIV><SPAN=20
class=3D986385202-10072006>&nbsp;</DIV>
<DIV>This =
is Deja-vu to=20
me.... </DIV>
<DIV><SPAN=20
class=3D986385202-10072006>&nbsp;</DIV>
<DIV>Draft=20
<SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'MS Mincho'; mso-ansi-language: EN-US; =
mso-fareast-language: JA; mso-bidi-language: =
AR-SA">draft-ietf-ccamp-rsvp-restart-ext-05.txt=20
actually had a section on multiple node restart case and was rejected by =
the WG=20
as addressing multiple node restart case is&nbsp;NOT a goal (suffers =
from the=20
law of diminishing return). In other words the following statement in =
the ID-=20
</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;&nbsp;=20
"[GR-EXT] also extends =
the Hello=20
message to exchange information about </DIV>
<DIV><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;the ability to =
support the=20
RecoveryPath message. </DIV>
<DIV>&nbsp;&nbsp;=20
The examples and procedures in [GR-EXT] focus on the description =
of a=20
</DIV>
<DIV><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;single node restart =
when=20
adjacent network nodes are operative. </DIV>
<DIV><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;Although the =
procedures are=20
equally applicable to multi-node restarts, </DIV>
<DIV><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;no detailed =
explanation is=20
provided." </DIV>
<DIV>&nbsp;</DIV>
<DIV>is not =
accurate.=20
Please see section 4 on the earlier version of the [GR-EXT], <A=20
href=3D"http://www.faqs.org/ftp/pub/internet-drafts/draft-rahman-ccamp-rs=
vp-restart-extensions-00.txt"><FONT=20
face=3DArial=20
size=3D2>http://www.faqs.org/ftp/pub/internet-drafts/draft-rahman-ccamp-r=
svp-restart-extensions-00.txt</A><FONT=20
face=3DArial size=3D2>. </DIV>
<DIV>&nbsp;</DIV>
<DIV>Thanks</DIV>
<DIV>&nbsp;</DIV>
<DIV>Regards... Zafar=20
</DIV>
<DIV><FONT=20
size=3D2>&nbsp;</DIV></BODY></HTML>

------_=_NextPart_001_01C6A3CD.8D339B2D--

Envelope-to: ccamp-data@psg.com
Delivery-date: Mon, 10 Jul 2006 02:41:02 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6A3CA.1397CB93"
Subject: High level comment on draft-li-ccamp-confirm-data-channel-status-00.txt, 
Date: Sun, 9 Jul 2006 22:39:32 -0400
Message-ID: <BABC859E6D0B9A4D8448CC7F41CD2B0702066428@xmb-rtp-203.amer.cisco.com>
Thread-Topic: High level comment on draft-li-ccamp-confirm-data-channel-status-00.txt, 
Thread-Index: AcajyhK/tBTLSTDlQnagl/WovUYgAw==
From: "Zafar Ali \(zali\)" <zali@cisco.com>
To: <xuhuiying@huawei.com>, <danli@huawei.com>
Cc: "ccamp" <ccamp@ops.ietf.org>
DKIM-Signature: a=rsa-sha1; q=dns; l=3214; t=1152499174; x=1153363174; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=zali@cisco.com; z=From:=22Zafar=20Ali=20\(zali\)=22=20<zali@cisco.com> |Subject:High=20level=20comment=20on=20draft-li-ccamp-confirm-data-channel-status -00.txt,=20 |To:<xuhuiying@huawei.com>,=20<danli@huawei.com>; X=v=3Dcisco.com=3B=20h=3DkHMWlOTnabTI0kLwNQTVzrwnX7I=3D; b=0SjUQ3E9wHzAlEZx2L24rG//WzGj9e+UbOvHWi5SbGTqMnLqS2PkJ3iJAvmk8zL2ywumJ+YC ferzeoJZgigdo7hjD/gI/YIVG/gWjYEWbbEFXQrFBsMS5da6iU+oa5KR;
Authentication-Results: rtp-dkim-2.cisco.com; header.From=zali@cisco.com; dkim=pass ( 59 extraneous bytes; sig from cisco.com verified; );

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6A3CA.1397CB93
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

Dear Authors,=20
=20
RSVP refreshes do this job, so I am not sure motivation for this draft/
LMP extensions.=20
=20
n.b. The draft state, "Although such a situation can be resolved through
the use of the Acceptable Label Set object in GMPLS signaling [RFC3473],
such a procedure is inefficient since it may require an additional
signaling exchange for each LSP that is set up", so I assume that RSVP
signaling is present (Although I did not understand the quoted statement
from the ID). Even if RSVP is not present, e.g., optical core is
completely controlled by a management entity, I would argue introduce
presence of LMP.=20
=20
Thanks
=20
Regards... Zafar=20

------_=_NextPart_001_01C6A3CA.1397CB93
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1543" name=3DGENERATOR></HEAD>
<BODY>
<DIV>Dear =
Authors,=20
</DIV>
<DIV><SPAN=20
class=3D839221802-10072006>&nbsp;</DIV>
<DIV>RSVP =
refreshes do=20
this job, so I am not sure motivation for this draft/ LMP=20
extensions.&nbsp;</DIV>
<DIV><SPAN=20
class=3D839221802-10072006>&nbsp;</DIV>
<DIV>n.b. The=20
draft state, "Although such a situation can be resolved through the use =
of=20
the&nbsp;<SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'MS Mincho'; mso-ansi-language: EN-US; =
mso-fareast-language: JA; mso-bidi-language: AR-SA">Acceptable=20
Label Set object in GMPLS signaling [RFC3473], such a&nbsp;procedure is=20
inefficient since it may require an additional signaling&nbsp;<SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'MS Mincho'; mso-ansi-language: EN-US; =
mso-fareast-language: JA; mso-bidi-language: AR-SA">exchange=20
for each LSP that is set up", so I assume that RSVP signaling is present =

(Although I did not understand the quoted statement from the ID). Even =
if RSVP=20
is not present, e.g., optical core is completely controlled by a =
management=20
entity, I would argue introduce presence of LMP.=20
</DIV>
<DIV><SPAN=20
class=3D839221802-10072006>&nbsp;</DIV>
<DIV><SPAN=20
class=3D839221802-10072006>Thanks</DIV>
<DIV><SPAN=20
class=3D839221802-10072006>&nbsp;</DIV>
<DIV>Regards... Zafar=20
</DIV></BODY></HTML>

------_=_NextPart_001_01C6A3CA.1397CB93--

Envelope-to: ccamp-data@psg.com
Delivery-date: Sun, 09 Jul 2006 15:59:24 +0000
Message-ID: <44B127BC.1030200@cisco.com>
Date: Sun, 09 Jul 2006 11:58:52 -0400
From: Acee Lindem <acee@cisco.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
MIME-Version: 1.0
To: "Ong, Lyndon" <Lyong@Ciena.com>
CC: Dimitri.Papadimitriou@alcatel.be, ccamp@ops.ietf.org, owner-ccamp@ops.ietf.org
Subject: Re: Comments on draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: a=rsa-sha1; q=dns; l=8698; t=1152460734; x=1153324734; c=relaxed/simple; s=sjdkim3001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acee@cisco.com; z=From:Acee=20Lindem=20<acee@cisco.com> |Subject:Re=3A=20Comments=20on=20draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.t xt; X=v=3Dcisco.com=3B=20h=3Dgo4Pb9+/SyFzptq1GgBjxsAHtqw=3D; b=sjgpwa6SaEQEJk/cYv1EmEzhkktLr3yyu4gl5t+pIunb7keL9fVMQAfhIJrHPAcVek8okF6I Kydtbe54SEWji6cALhNkib6P1u+KCG92szut00sZjobcUD9t6pFgtBqz;
Authentication-Results: sj-dkim-3.cisco.com; header.From=acee@cisco.com; dkim=pass ( sig from cisco.com verified; );

Hi Lyndon,
Ong, Lyndon wrote:

>hi dimitri,
>
>I agree regarding the existing LSA, it needs to retain the link_ID.
>I thought that Acee was perhaps suggesting a new LSA
>where link_id would not be mandatory.   
>  
>
I blieve you mean making the link_id optional when the new sub-TLV was 
advertised -
we certainly don't want a new LSA. But no, I was suggesting defining 
link_id as the
end point of the link rather than the advertising router (which I don't 
is contrary to
RFC 3630)
Thanks,
Acee

>Lyndon 
>
>-----Original Message-----
>From: Dimitri.Papadimitriou@alcatel.be
>[mailto:Dimitri.Papadimitriou@alcatel.be] 
>Sent: Friday, July 07, 2006 5:14 AM
>To: Ong, Lyndon
>Cc: Acee Lindem; ccamp@ops.ietf.org; owner-ccamp@ops.ietf.org
>Subject: RE: Comments on
>draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt
>
>hi lyndon
>
>the link_id remains the mandatory sub-tlv including the remote router_id
>from 3630 - 
>
>the link_id remains thus as defined in that rfc - translated into the
>terminology used in ason it represents the remote RC_ID
>
>does it change something in terms of TE/computation - in principle not -
>even if some engines where not able to process such mix of identifiers
>
>thanks,
>- dimitri.
>
>
>
>
>
>
>
>"Ong, Lyndon" <Lyong@Ciena.com>
>Sent by: owner-ccamp@ops.ietf.org
>06/07/2006 23:18
> 
>        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Acee Lindem" 
><acee@cisco.com>
>        cc:     <ccamp@ops.ietf.org>, <owner-ccamp@ops.ietf.org>
>        Subject:        RE: Comments on 
>draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt
>
>
>Hi Dimitri, Acee,
>
>Just a small comment on the Link_ID - I think Dimitri is right that the
>Link_ID and the Local/Remote TE_Router_ID have different meanings and
>must not be confused.  On the other hand, Acee may have a point that the
>Link_ID actually is no longer necessary once you have the Local/Remote
>TE_Router_ID - we found in some prototyping that with the separation of
>the Router_ID and TE_Router_ID that it became somewhat arbitrary as to
>what value you gave as the remote Router_ID, this was not used in path
>computation at all.
>
>Cheers,
>
>Lyndon 
>
>-----Original Message-----
>From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On
>Behalf Of Dimitri.Papadimitriou@alcatel.be
>Sent: Thursday, July 06, 2006 11:12 AM
>To: Acee Lindem
>Cc: ccamp@ops.ietf.org; owner-ccamp@ops.ietf.org
>Subject: Re: Comments on
>draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt
>
>acee - see inline
>
>
>
>
>Acee Lindem <acee@cisco.com>
>Sent by: owner-ccamp@ops.ietf.org
>06/07/2006 18:36
> 
>        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
>        cc:     ccamp@ops.ietf.org
>        Subject:        Re: Comments on 
>draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt
>
>  
>
>>Dimitri,
>>
>>Here are my comments on the subject document:
>>
>>  General - Describe the relationship of OSPF areas to ASON RAs.
>>  Section 6.1 references     OSPF area ID but the relationship
>>  is implied.
>>
>>[dp] point taken (i guess we did not do a sufficiently good job in RFC
>>4258 and in the eval doc. as still some questioning remains about 
>>information map)
>>
>>Section  3.2 - The length calculation is simply wrong.  You
>> really don't know how many prefixes you've got until you've
>> parsed them.
>>
>>[dp] which length are you referring to ? the prefix or the sub-TLV ?
>>
>>
>>    
>>
>The TLV length, the nonesense below:
>
>The Length is set to Sum[n][4 + #32-bit words/4] where n is the 
>   number of local prefixes included in the sub-TLV. 
>
>[dp] 4 x n as defined in the node i-d is ok - why not this one 
>
>  
>
>>Section 5.1 - RFC 3620 specifies that the Link-ID Sub-TLV
>> specifies the router-id. Why do you need the remote router-id
>> in this sub-TLV? Could the 5.2 sub-TLV satisfy the
>> requirement?
>>
>>[dp] it is not the router_id but the TE router_ID
>>    
>>
>
>  
>
>>[dp] the issue is that there is no more a there is no more a 1:1 
>>relationship between the Router_ID and the TE Router_ID in the present 
>>context
>>    
>>
>
>I surmised that. Why wouldn't the link ID be the remote TE router ID in
>this case? The advertising router seems irrelevant from a TE standpoint.
>
>[dp] because the router_id is not linked on a 1:1 basis to the TE
>router_id when space is per TE_router_id you need to seggregate this
>information
>
>  
>
>>Section 6.0 - You should NOT need to change OSPF flooding rules.
>> In other words, I don't see the need to specify the following:
>>
>> The Opaque TE LSA re-origination is governed as follows:
>>   - If the target interface is associated to the same area as the
>>     one associated with the receiving interface, the Opaque LSA MUST
>>     NOT be re-originated out that interface.
>>   - If a match is found between the Advertising Router ID in the
>>     header of the received Opaque TE LSA and one of the Router ID
>>     belonging to the area of the target interface, the Opaque LSA
>>     MUST NOT be re-originated out that interface.
>>   - If these two conditions are not met the Opaque TE LSA MAY be re-
>>     originated.
>>
>> Rather you should specify rules for importing/exporting  information 
>>between OSPF instances at different levels.
>>
>>[dp] your proposal is thus to revise these as import/export rules ?
>>in order to prevent having specific flooding rules between levels the 
>>point was to not expand too much on the communication process (inside 
>>the entity) between level adjacent RCs but if this makes you more 
>>confortable i can revise as import/export rules
>>    
>>
>
>The existing RFC 3620 TE opaque LSAs are area scoped LSAs. Area scoped
>LSAs have very well defined flooding rules and, IMHO, you should not be
>trying to roll-your-own flooding rules for this application. Just think
>what a mess we'd have if every party proposed an opaque LSA also
>proposed some flooding hack for their opaque LSA type.
>
>[dp] i don't have any issue to express LSA processing with import and
>export rules (even if there is nothing in 3640 to pass LSA between
>routing
>instance)
>
>  
>
>>Section 6.1 While an RA is completely contained within a single
>>  parent layer RA. A given    RA may have multiple child RAs. 
>>Hence, the election algorithm is broken. 
>>
>>[dp] to make it clear this is not an "election" process
>>
>>At a minimum,
>>  you must advertise all your child areas.  Also, you MUST state
>>  that reachability is a precondition for considering a router
>>  eligible to pass information between levels.
>>
>>[dp] upper not lower (it is a discovery from a given to an upper parent
>>    
>>
>
>  
>
>>viewpoint, where a child has a unique parent)
>>
>>
>>    
>>
>I get from RFC 4258 that a child RA will be contained within a single
>parent RA. However, no where do I that a parent RA can have a single
>child RA. So, if a single RC in a parent RA has multiple child RAs, you
>need to advertise more than one area ID.
>
>[dp] the parent is unique why multiple parent area id
>
>Also, you did not address the requirement for reachability. What if the
>RA becomes partitioned or the advertising RC goes down without
>withdrawing its advertisements. 
>You MUST deal
>this - it is simply broken the way it is.
>
>[dp] situation is the same as with a single ABR case, in case of
>multiple RC's you are expected to be aware of the broken RC -
>
>  
>
>>  Finally, since this is going to require advertisement of more
>>  than a single area-ID, please allocate a separate opaque LSA
>>  for ASON purposes.
>>
>>[dp] having clarified the above is that still needed ?
>>
>>
>>    
>>
>You only clarified that it is wrong.
>
>[dp] not sure to capture your point - but ok - 
>
>  
>
>>Section 6.2 - Are you suggesting a single area ID or an area ID
>>  path (similar to the BGP AS path)? 
>>
>>[dp] the former
>>
>>I guess this may work if you
>>  always advertise you own area ID when redistributing between
>>  areas (relying on the fact that a child area is completely
>>  contained by its parent). I'm going to think more about this
>>  encourage others to do the same.
>>
>>General: Have you considered aggregation?
>>
>>[dp] at which level - reachability can be aggregated for inst.
>>
>>
>>    
>>
>Than the rules for aggregation should be specified.
>
>[dp] can add base guidelines if needed
>
>Thanks,
>Acee
>
>  
>
>>Thanks,
>>Acee
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>    
>>
>
>
>  
>

Envelope-to: ccamp-data@psg.com
Delivery-date: Sun, 09 Jul 2006 15:49:12 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Comments on draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt
Date: Sun, 9 Jul 2006 11:44:23 -0400
Message-ID: <0901D1988E815341A0103206A834DA07E7CF39@mdmxm02.ciena.com>
Thread-Topic: Comments on draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt
Thread-Index: Acahvtd4/h8CF5sSQNGsk6dCcvRrrwAOlm2A
From: "Ong, Lyndon" <Lyong@Ciena.com>
To: <Dimitri.Papadimitriou@alcatel.be>
Cc: "Acee Lindem" <acee@cisco.com>, <ccamp@ops.ietf.org>, <owner-ccamp@ops.ietf.org>

hi dimitri,

I agree regarding the existing LSA, it needs to retain the link_ID.
I thought that Acee was perhaps suggesting a new LSA
where link_id would not be mandatory.  =20

Lyndon=20

-----Original Message-----
From: Dimitri.Papadimitriou@alcatel.be
[mailto:Dimitri.Papadimitriou@alcatel.be]=20
Sent: Friday, July 07, 2006 5:14 AM
To: Ong, Lyndon
Cc: Acee Lindem; ccamp@ops.ietf.org; owner-ccamp@ops.ietf.org
Subject: RE: Comments on
draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt

hi lyndon

the link_id remains the mandatory sub-tlv including the remote router_id
from 3630 -=20

the link_id remains thus as defined in that rfc - translated into the
terminology used in ason it represents the remote RC_ID

does it change something in terms of TE/computation - in principle not -
even if some engines where not able to process such mix of identifiers

thanks,
- dimitri.

"Ong, Lyndon" <Lyong@Ciena.com>
Sent by: owner-ccamp@ops.ietf.org
06/07/2006 23:18
=20
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Acee Lindem"=20
<acee@cisco.com>
        cc:     <ccamp@ops.ietf.org>, <owner-ccamp@ops.ietf.org>
        Subject:        RE: Comments on=20
draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt

Hi Dimitri, Acee,

Just a small comment on the Link_ID - I think Dimitri is right that the
Link_ID and the Local/Remote TE_Router_ID have different meanings and
must not be confused.  On the other hand, Acee may have a point that the
Link_ID actually is no longer necessary once you have the Local/Remote
TE_Router_ID - we found in some prototyping that with the separation of
the Router_ID and TE_Router_ID that it became somewhat arbitrary as to
what value you gave as the remote Router_ID, this was not used in path
computation at all.

Cheers,

Lyndon=20

-----Original Message-----
From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On
Behalf Of Dimitri.Papadimitriou@alcatel.be
Sent: Thursday, July 06, 2006 11:12 AM
To: Acee Lindem
Cc: ccamp@ops.ietf.org; owner-ccamp@ops.ietf.org
Subject: Re: Comments on
draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt

acee - see inline

Acee Lindem <acee@cisco.com>
Sent by: owner-ccamp@ops.ietf.org
06/07/2006 18:36
=20
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     ccamp@ops.ietf.org
        Subject:        Re: Comments on=20
draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt

>Dimitri,
>
>Here are my comments on the subject document:
>
>   General - Describe the relationship of OSPF areas to ASON RAs.
>   Section 6.1 references     OSPF area ID but the relationship
>   is implied.
>
>[dp] point taken (i guess we did not do a sufficiently good job in RFC
>4258 and in the eval doc. as still some questioning remains about=20
>information map)
>
>Section  3.2 - The length calculation is simply wrong.  You
>  really don't know how many prefixes you've got until you've
>  parsed them.
>
>[dp] which length are you referring to ? the prefix or the sub-TLV ?
>=20
>
The TLV length, the nonesense below:

The Length is set to Sum[n][4 + #32-bit words/4] where n is the=20
   number of local prefixes included in the sub-TLV.=20

[dp] 4 x n as defined in the node i-d is ok - why not this one=20

>Section 5.1 - RFC 3620 specifies that the Link-ID Sub-TLV
>  specifies the router-id. Why do you need the remote router-id
>  in this sub-TLV? Could the 5.2 sub-TLV satisfy the
>  requirement?
>
>[dp] it is not the router_id but the TE router_ID

>[dp] the issue is that there is no more a there is no more a 1:1=20
>relationship between the Router_ID and the TE Router_ID in the present=20
>context

I surmised that. Why wouldn't the link ID be the remote TE router ID in
this case? The advertising router seems irrelevant from a TE standpoint.

[dp] because the router_id is not linked on a 1:1 basis to the TE
router_id when space is per TE_router_id you need to seggregate this
information

>Section 6.0 - You should NOT need to change OSPF flooding rules.
>  In other words, I don't see the need to specify the following:
>
>  The Opaque TE LSA re-origination is governed as follows:
>    - If the target interface is associated to the same area as the
>      one associated with the receiving interface, the Opaque LSA MUST
>      NOT be re-originated out that interface.
>    - If a match is found between the Advertising Router ID in the
>      header of the received Opaque TE LSA and one of the Router ID
>      belonging to the area of the target interface, the Opaque LSA
>      MUST NOT be re-originated out that interface.
>    - If these two conditions are not met the Opaque TE LSA MAY be re-
>      originated.
>
>  Rather you should specify rules for importing/exporting  information=20
> between OSPF instances at different levels.
>
>[dp] your proposal is thus to revise these as import/export rules ?
>in order to prevent having specific flooding rules between levels the=20
>point was to not expand too much on the communication process (inside=20
>the entity) between level adjacent RCs but if this makes you more=20
>confortable i can revise as import/export rules

The existing RFC 3620 TE opaque LSAs are area scoped LSAs. Area scoped
LSAs have very well defined flooding rules and, IMHO, you should not be
trying to roll-your-own flooding rules for this application. Just think
what a mess we'd have if every party proposed an opaque LSA also
proposed some flooding hack for their opaque LSA type.

[dp] i don't have any issue to express LSA processing with import and
export rules (even if there is nothing in 3640 to pass LSA between
routing
instance)

>Section 6.1 While an RA is completely contained within a single
>   parent layer RA. A given    RA may have multiple child RAs.=20
>Hence, the election algorithm is broken.=20
>
>[dp] to make it clear this is not an "election" process
>
>At a minimum,
>   you must advertise all your child areas.  Also, you MUST state
>   that reachability is a precondition for considering a router
>   eligible to pass information between levels.
>
>[dp] upper not lower (it is a discovery from a given to an upper parent

>viewpoint, where a child has a unique parent)
>=20
>
I get from RFC 4258 that a child RA will be contained within a single
parent RA. However, no where do I that a parent RA can have a single
child RA. So, if a single RC in a parent RA has multiple child RAs, you
need to advertise more than one area ID.

[dp] the parent is unique why multiple parent area id

Also, you did not address the requirement for reachability. What if the
RA becomes partitioned or the advertising RC goes down without
withdrawing its advertisements.=20
You MUST deal
this - it is simply broken the way it is.

[dp] situation is the same as with a single ABR case, in case of
multiple RC's you are expected to be aware of the broken RC -

>   Finally, since this is going to require advertisement of more
>   than a single area-ID, please allocate a separate opaque LSA
>   for ASON purposes.
>
>[dp] having clarified the above is that still needed ?
>=20
>
You only clarified that it is wrong.

[dp] not sure to capture your point - but ok -=20

>Section 6.2 - Are you suggesting a single area ID or an area ID
>   path (similar to the BGP AS path)?=20
>
>[dp] the former
>
>I guess this may work if you
>   always advertise you own area ID when redistributing between
>   areas (relying on the fact that a child area is completely
>   contained by its parent). I'm going to think more about this
>   encourage others to do the same.
>
>General: Have you considered aggregation?
>
>[dp] at which level - reachability can be aggregated for inst.
>=20
>
Than the rules for aggregation should be specified.

[dp] can add base guidelines if needed

Thanks,
Acee

>
>Thanks,
>Acee
>
>
>
>
>
>
>
>=20
>

Envelope-to: ccamp-data@psg.com
Delivery-date: Fri, 07 Jul 2006 13:00:15 +0000
To: "Ong, Lyndon" <Lyong@Ciena.com>
Cc: "Acee Lindem" <acee@cisco.com>, ccamp@ops.ietf.org, owner-ccamp@ops.ietf.org
Subject: RE: Comments on draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt
MIME-Version: 1.0
Message-ID: <OFB536A769.EDD39B42-ONC12571A4.002B83E3-C12571A4.0043324A@netfr.alcatel.fr>
From: Dimitri.Papadimitriou@alcatel.be
Date: Fri, 7 Jul 2006 14:13:56 +0200
Content-Type: text/plain; charset="US-ASCII"

hi lyndon

the link_id remains the mandatory sub-tlv including the remote router_id 
from 3630 - 

the link_id remains thus as defined in that rfc - translated into the 
terminology 
used in ason it represents the remote RC_ID

does it change something in terms of TE/computation - in principle not - 
even if
some engines where not able to process such mix of identifiers

thanks,
- dimitri.

"Ong, Lyndon" <Lyong@Ciena.com>
Sent by: owner-ccamp@ops.ietf.org
06/07/2006 23:18

        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Acee Lindem" 
<acee@cisco.com>
        cc:     <ccamp@ops.ietf.org>, <owner-ccamp@ops.ietf.org>
        Subject:        RE: Comments on 
draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt

Hi Dimitri, Acee,

Just a small comment on the Link_ID - I think Dimitri is right that the
Link_ID and the Local/Remote TE_Router_ID have different meanings and
must not be confused.  On the other hand, Acee may have a point that the
Link_ID actually is no longer necessary once you have the Local/Remote
TE_Router_ID - we found in some prototyping that with the separation
of the Router_ID and TE_Router_ID that it became somewhat arbitrary as
to what value you gave as the remote Router_ID, this was not used in
path computation at all.

Cheers,

Lyndon 

-----Original Message-----
From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On
Behalf Of Dimitri.Papadimitriou@alcatel.be
Sent: Thursday, July 06, 2006 11:12 AM
To: Acee Lindem
Cc: ccamp@ops.ietf.org; owner-ccamp@ops.ietf.org
Subject: Re: Comments on
draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt

acee - see inline

Acee Lindem <acee@cisco.com>
Sent by: owner-ccamp@ops.ietf.org
06/07/2006 18:36

        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     ccamp@ops.ietf.org
        Subject:        Re: Comments on 
draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt

>Dimitri,
>
>Here are my comments on the subject document:
>
>   General - Describe the relationship of OSPF areas to ASON RAs.
>   Section 6.1 references     OSPF area ID but the relationship
>   is implied.
>
>[dp] point taken (i guess we did not do a sufficiently good job in RFC 
>4258 and in the eval doc. as still some questioning remains about 
>information map)
>
>Section  3.2 - The length calculation is simply wrong.  You
>  really don't know how many prefixes you've got until you've
>  parsed them.
>
>[dp] which length are you referring to ? the prefix or the sub-TLV ?
> 
>
The TLV length, the nonesense below:

The Length is set to Sum[n][4 + #32-bit words/4] where n is the 
   number of local prefixes included in the sub-TLV. 

[dp] 4 x n as defined in the node i-d is ok - why not this one 

>Section 5.1 - RFC 3620 specifies that the Link-ID Sub-TLV
>  specifies the router-id. Why do you need the remote router-id
>  in this sub-TLV? Could the 5.2 sub-TLV satisfy the
>  requirement?
>
>[dp] it is not the router_id but the TE router_ID

>[dp] the issue is that there is no more a there is no more a 1:1 
>relationship between the Router_ID and the TE Router_ID in the present 
>context

I surmised that. Why wouldn't the link ID be the remote TE router ID in
this case? The advertising router seems irrelevant from a TE standpoint.

[dp] because the router_id is not linked on a 1:1 basis to the TE
router_id when space is per TE_router_id you need to seggregate this
information

>Section 6.0 - You should NOT need to change OSPF flooding rules.
>  In other words, I don't see the need to specify the following:
>
>  The Opaque TE LSA re-origination is governed as follows:
>    - If the target interface is associated to the same area as the
>      one associated with the receiving interface, the Opaque LSA MUST
>      NOT be re-originated out that interface.
>    - If a match is found between the Advertising Router ID in the
>      header of the received Opaque TE LSA and one of the Router ID
>      belonging to the area of the target interface, the Opaque LSA
>      MUST NOT be re-originated out that interface.
>    - If these two conditions are not met the Opaque TE LSA MAY be re-
>      originated.
>
>  Rather you should specify rules for importing/exporting  information 
> between OSPF instances at different levels.
>
>[dp] your proposal is thus to revise these as import/export rules ?
>in order to prevent having specific flooding rules between levels the 
>point was to not expand too much on the communication process (inside 
>the entity) between level adjacent RCs but if this makes you more 
>confortable i can revise as import/export rules

The existing RFC 3620 TE opaque LSAs are area scoped LSAs. Area scoped
LSAs have very well defined flooding rules and, IMHO, you should not be
trying to roll-your-own flooding rules for this application. Just think
what a mess we'd have if every party proposed an opaque LSA also
proposed some flooding hack for their opaque LSA type.

[dp] i don't have any issue to express LSA processing with import and
export rules (even if there is nothing in 3640 to pass LSA between
routing
instance)

>Section 6.1 While an RA is completely contained within a single
>   parent layer RA. A given    RA may have multiple child RAs. 
>Hence, the election algorithm is broken. 
>
>[dp] to make it clear this is not an "election" process
>
>At a minimum,
>   you must advertise all your child areas.  Also, you MUST state
>   that reachability is a precondition for considering a router
>   eligible to pass information between levels.
>
>[dp] upper not lower (it is a discovery from a given to an upper parent

>viewpoint, where a child has a unique parent)
> 
>
I get from RFC 4258 that a child RA will be contained within a single
parent RA. However, no where do I that a parent RA can have a single
child RA. So, if a single RC in a parent RA has multiple child RAs, you
need to advertise more than one area ID.

[dp] the parent is unique why multiple parent area id

Also, you did not address the requirement for reachability. What if the
RA becomes partitioned or the advertising RC goes down without
withdrawing its advertisements. 
You MUST deal
this - it is simply broken the way it is.

[dp] situation is the same as with a single ABR case, in case of
multiple RC's you are expected to be aware of the broken RC -

>   Finally, since this is going to require advertisement of more
>   than a single area-ID, please allocate a separate opaque LSA
>   for ASON purposes.
>
>[dp] having clarified the above is that still needed ?
> 
>
You only clarified that it is wrong.

[dp] not sure to capture your point - but ok - 

>Section 6.2 - Are you suggesting a single area ID or an area ID
>   path (similar to the BGP AS path)? 
>
>[dp] the former
>
>I guess this may work if you
>   always advertise you own area ID when redistributing between
>   areas (relying on the fact that a child area is completely
>   contained by its parent). I'm going to think more about this
>   encourage others to do the same.
>
>General: Have you considered aggregation?
>
>[dp] at which level - reachability can be aggregated for inst.
> 
>
Than the rules for aggregation should be specified.

[dp] can add base guidelines if needed

Thanks,
Acee

>
>Thanks,
>Acee
>
>
>
>
>
>
>
> 
>

Envelope-to: ccamp-data@psg.com
Delivery-date: Thu, 06 Jul 2006 23:18:38 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Comments on draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt
Date: Thu, 6 Jul 2006 19:11:15 -0400
Message-ID: <0901D1988E815341A0103206A834DA07E7CE5E@mdmxm02.ciena.com>
Thread-Topic: Comments on draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt
Thread-Index: AcahQoaRZJdSoy3cQtubMsg75PGlrQAAIZqwAANdJSA=
From: "Ong, Lyndon" <Lyong@Ciena.com>
To: "Sadler, Jonathan B." <Jonathan.Sadler@tellabs.com>, "Acee Lindem" <acee@cisco.com>
Cc: <Dimitri.Papadimitriou@alcatel.be>, <ccamp@ops.ietf.org>, <owner-ccamp@ops.ietf.org>

Hi Jonathan,

This is a question of the right OSPF terminology where I would defer
to the experts.  The important thing from an ASON standpoint is to=20
distinguish the routing entity that generates the advertisement from
the data plane entities at either end of the link, or their control
plane=20
identifiers, since ASON allows separation between the two.

I think your point is that the data plane entities may not necessarily
be identified by reachable IP addresses, maybe just by a 32-bit number.

Cheers,

Lyndon

-----Original Message-----
From: Sadler, Jonathan B. [mailto:Jonathan.Sadler@tellabs.com]=20
Sent: Thursday, July 06, 2006 3:09 PM
To: Acee Lindem; Ong, Lyndon
Cc: Dimitri.Papadimitriou@alcatel.be; ccamp@ops.ietf.org;
owner-ccamp@ops.ietf.org
Subject: RE: Comments on
draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt

Hi Acee, Lyndon and Dimitri,

Actually, it would be better if the extension defined in Sec. 5.1 were
in terms of OSPF Router_ID, not TE_Router_ID...

The transport network elements being shown in the TE database are not
necessarily capable of receiving IP packets -- that's the function of
the control plane device working on behalf of the network element.
Using "a stable IP address of the advertising router that is always
reachable" (def'n for Router Address TLV in RFC3630) seems incorrect
given this lack of IP packet processing, not to mention a waste of
addresses for the IPv4 network.  Using a "32-bit number that uniquely
identifies the (data-plane device)" seems more appropriate.

It should be noted that the extension defined in Sec. 5.1 is necessary
not only to allow one control plane participant to announce the
existence of multiple network elements in the routing topology, but also
to allow multiple control plane instances to announce separate sets of
links on the same network element (i.e. allowing cardinality of Li:Pi:Ri
other than 1:1:1 as shown by the examples in Sec. 6 of
draft-ietf-ccamp-gmpls-ason-routing-eval).  This also would make use of
an address for the IPv4 network problematic as it is unclear which
address would be appropriate to use.

When cardinality of 1:1:1 does exist, certainly the Router_ID and
TE_Router_ID could be set to the same value to simplify operations.
However, implementations should recognize them as from two separate
name-spaces, and not interchangeable...

Jonathan Sadler

-----Original Message-----
From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On
Behalf Of Acee Lindem
Sent: Thursday, July 06, 2006 4:23 PM
To: Ong, Lyndon
Cc: Dimitri.Papadimitriou@alcatel.be; ccamp@ops.ietf.org;
owner-ccamp@ops.ietf.org
Subject: Re: Comments on
draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt

Ong, Lyndon wrote:

>Hi Dimitri, Acee,
>
>Just a small comment on the Link_ID - I think Dimitri is right that the

>Link_ID and the Local/Remote TE_Router_ID have different meanings and=20
>must not be confused.  On the other hand, Acee may have a point that
the
>Link_ID actually is no longer necessary once you have the Local/Remote=20
>TE_Router_ID - we found in some prototyping that with the separation of

>the Router_ID and TE_Router_ID that it became somewhat arbitrary as to=20
>what value you gave as the remote Router_ID, this was not used in
> =20
>

>path computation at all.
> =20
>
Hi Lyndon,

Exactly my point but I seemed to be getting into a circular argument.=20
 From the standpoint of TE,
you only care about the entity to which link actually connects.  Also,
is there any reason why the TE router ID space and router-id space
wouldn't overlapp? I don't see one.

Thanks,
Acee

>Cheers,
>
>Lyndon
>
>-----Original Message-----
>From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On=20
>Behalf Of Dimitri.Papadimitriou@alcatel.be
>Sent: Thursday, July 06, 2006 11:12 AM
>To: Acee Lindem
>Cc: ccamp@ops.ietf.org; owner-ccamp@ops.ietf.org
>Subject: Re: Comments on
>draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt
>
>acee - see inline
>
>
>
>
>Acee Lindem <acee@cisco.com>
>Sent by: owner-ccamp@ops.ietf.org
>06/07/2006 18:36
>=20
>        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
>        cc:     ccamp@ops.ietf.org
>        Subject:        Re: Comments on=20
>draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt
>
> =20
>
>>Dimitri,
>>
>>Here are my comments on the subject document:
>>
>>  General - Describe the relationship of OSPF areas to ASON RAs.
>>  Section 6.1 references     OSPF area ID but the relationship
>>  is implied.
>>
>>[dp] point taken (i guess we did not do a sufficiently good job in RFC

>>4258 and in the eval doc. as still some questioning remains about=20
>>information map)
>>
>>Section  3.2 - The length calculation is simply wrong.  You  really=20
>>don't know how many prefixes you've got until you've  parsed them.
>>
>>[dp] which length are you referring to ? the prefix or the sub-TLV ?
>>
>>
>>   =20
>>
>The TLV length, the nonesense below:
>
>The Length is set to Sum[n][4 + #32-bit words/4] where n is the=20
>   number of local prefixes included in the sub-TLV.=20
>
>[dp] 4 x n as defined in the node i-d is ok - why not this one
>
> =20
>
>>Section 5.1 - RFC 3620 specifies that the Link-ID Sub-TLV  specifies=20
>>the router-id. Why do you need the remote router-id  in this sub-TLV?=20
>>Could the 5.2 sub-TLV satisfy the  requirement?
>>
>>[dp] it is not the router_id but the TE router_ID
>>   =20
>>
>
> =20
>
>>[dp] the issue is that there is no more a there is no more a 1:1=20
>>relationship between the Router_ID and the TE Router_ID in the present

>>context
>>   =20
>>
>
>I surmised that. Why wouldn't the link ID be the remote TE router ID in

>this case? The advertising router seems irrelevant from a TE
standpoint.
>
>[dp] because the router_id is not linked on a 1:1 basis to the TE=20
>router_id when space is per TE_router_id you need to seggregate this=20
>information
>
> =20
>
>>Section 6.0 - You should NOT need to change OSPF flooding rules.
>> In other words, I don't see the need to specify the following:
>>
>> The Opaque TE LSA re-origination is governed as follows:
>>   - If the target interface is associated to the same area as the
>>     one associated with the receiving interface, the Opaque LSA MUST
>>     NOT be re-originated out that interface.
>>   - If a match is found between the Advertising Router ID in the
>>     header of the received Opaque TE LSA and one of the Router ID
>>     belonging to the area of the target interface, the Opaque LSA
>>     MUST NOT be re-originated out that interface.
>>   - If these two conditions are not met the Opaque TE LSA MAY be re-
>>     originated.
>>
>> Rather you should specify rules for importing/exporting  information=20
>>between OSPF instances at different levels.
>>
>>[dp] your proposal is thus to revise these as import/export rules ?
>>in order to prevent having specific flooding rules between levels the=20
>>point was to not expand too much on the communication process (inside=20
>>the entity) between level adjacent RCs but if this makes you more=20
>>confortable i can revise as import/export rules
>>   =20
>>
>
>The existing RFC 3620 TE opaque LSAs are area scoped LSAs. Area scoped=20
>LSAs have very well defined flooding rules and, IMHO, you should not be

>trying to roll-your-own flooding rules for this application. Just think

>what a mess we'd have if every party proposed an opaque LSA also=20
>proposed some flooding hack for their opaque LSA type.
>
>[dp] i don't have any issue to express LSA processing with import and=20
>export rules (even if there is nothing in 3640 to pass LSA between=20
>routing
>instance)
>
> =20
>
>>Section 6.1 While an RA is completely contained within a single
>>  parent layer RA. A given    RA may have multiple child RAs.=20
>>Hence, the election algorithm is broken.=20
>>
>>[dp] to make it clear this is not an "election" process
>>
>>At a minimum,
>>  you must advertise all your child areas.  Also, you MUST state
>>  that reachability is a precondition for considering a router
>>  eligible to pass information between levels.
>>
>>[dp] upper not lower (it is a discovery from a given to an upper
parent
>>   =20
>>
>
> =20
>
>>viewpoint, where a child has a unique parent)
>>
>>
>>   =20
>>
>I get from RFC 4258 that a child RA will be contained within a single=20
>parent RA. However, no where do I that a parent RA can have a single=20
>child RA. So, if a single RC in a parent RA has multiple child RAs, you

>need to advertise more than one area ID.
>
>[dp] the parent is unique why multiple parent area id
>
>Also, you did not address the requirement for reachability. What if the

>RA becomes partitioned or the advertising RC goes down without=20
>withdrawing its advertisements.
>You MUST deal
>this - it is simply broken the way it is.
>
>[dp] situation is the same as with a single ABR case, in case of=20
>multiple RC's you are expected to be aware of the broken RC -
>
> =20
>
>>  Finally, since this is going to require advertisement of more  than=20
>> a single area-ID, please allocate a separate opaque LSA  for ASON=20
>> purposes.
>>
>>[dp] having clarified the above is that still needed ?
>>
>>
>>   =20
>>
>You only clarified that it is wrong.
>
>[dp] not sure to capture your point - but ok -
>
> =20
>
>>Section 6.2 - Are you suggesting a single area ID or an area ID
>>  path (similar to the BGP AS path)?=20
>>
>>[dp] the former
>>
>>I guess this may work if you
>>  always advertise you own area ID when redistributing between
>>  areas (relying on the fact that a child area is completely
>>  contained by its parent). I'm going to think more about this
>>  encourage others to do the same.
>>
>>General: Have you considered aggregation?
>>
>>[dp] at which level - reachability can be aggregated for inst.
>>
>>
>>   =20
>>
>Than the rules for aggregation should be specified.
>
>[dp] can add base guidelines if needed
>
>Thanks,
>Acee
>
> =20
>
>>Thanks,
>>Acee
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>   =20
>>
>
>
> =20
>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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

Envelope-to: ccamp-data@psg.com
Delivery-date: Thu, 06 Jul 2006 22:13:34 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: Comments on draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt
Date: Thu, 6 Jul 2006 17:08:55 -0500
Message-ID: <A1A52203CA93634BA1748887B9993AEA02DE8C7C@USNVEX1.tellabs-west.tellabsinc.net>
Thread-Topic: Comments on draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt
Thread-Index: AcahQoaRZJdSoy3cQtubMsg75PGlrQAAIZqw
From: "Sadler, Jonathan B." <Jonathan.Sadler@tellabs.com>
To: "Acee Lindem" <acee@cisco.com>, "Ong, Lyndon" <Lyong@Ciena.com>
Cc: <Dimitri.Papadimitriou@alcatel.be>, <ccamp@ops.ietf.org>, <owner-ccamp@ops.ietf.org>
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="us-ascii"

Hi Acee, Lyndon and Dimitri,

Actually, it would be better if the extension defined in Sec. 5.1 were
in terms of OSPF Router_ID, not TE_Router_ID...

The transport network elements being shown in the TE database are not
necessarily capable of receiving IP packets -- that's the function of
the control plane device working on behalf of the network element.
Using "a stable IP address of the advertising router that is always
reachable" (def'n for Router Address TLV in RFC3630) seems incorrect
given this lack of IP packet processing, not to mention a waste of
addresses for the IPv4 network.  Using a "32-bit number that uniquely
identifies the (data-plane device)" seems more appropriate.

It should be noted that the extension defined in Sec. 5.1 is necessary
not only to allow one control plane participant to announce the
existence of multiple network elements in the routing topology, but also
to allow multiple control plane instances to announce separate sets of
links on the same network element (i.e. allowing cardinality of Li:Pi:Ri
other than 1:1:1 as shown by the examples in Sec. 6 of
draft-ietf-ccamp-gmpls-ason-routing-eval).  This also would make use of
an address for the IPv4 network problematic as it is unclear which
address would be appropriate to use.

When cardinality of 1:1:1 does exist, certainly the Router_ID and
TE_Router_ID could be set to the same value to simplify operations.
However, implementations should recognize them as from two separate
name-spaces, and not interchangeable...

Jonathan Sadler

-----Original Message-----
From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On
Behalf Of Acee Lindem
Sent: Thursday, July 06, 2006 4:23 PM
To: Ong, Lyndon
Cc: Dimitri.Papadimitriou@alcatel.be; ccamp@ops.ietf.org;
owner-ccamp@ops.ietf.org
Subject: Re: Comments on
draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt

Ong, Lyndon wrote:

>Hi Dimitri, Acee,
>
>Just a small comment on the Link_ID - I think Dimitri is right that the
>Link_ID and the Local/Remote TE_Router_ID have different meanings and
>must not be confused.  On the other hand, Acee may have a point that
the
>Link_ID actually is no longer necessary once you have the Local/Remote
>TE_Router_ID - we found in some prototyping that with the separation
>of the Router_ID and TE_Router_ID that it became somewhat arbitrary as
>to what value you gave as the remote Router_ID, this was not used in
> =20
>

>path computation at all.
> =20
>
Hi Lyndon,

Exactly my point but I seemed to be getting into a circular argument.=20
 From the standpoint of TE,
you only care about the entity to which link actually connects.  Also,=20
is there any reason why
the TE router ID space and router-id space wouldn't overlapp? I don't=20
see one.

Thanks,
Acee

>Cheers,
>
>Lyndon=20
>
>-----Original Message-----
>From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On
>Behalf Of Dimitri.Papadimitriou@alcatel.be
>Sent: Thursday, July 06, 2006 11:12 AM
>To: Acee Lindem
>Cc: ccamp@ops.ietf.org; owner-ccamp@ops.ietf.org
>Subject: Re: Comments on
>draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt
>
>acee - see inline
>
>
>
>
>Acee Lindem <acee@cisco.com>
>Sent by: owner-ccamp@ops.ietf.org
>06/07/2006 18:36
>=20
>        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
>        cc:     ccamp@ops.ietf.org
>        Subject:        Re: Comments on=20
>draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt
>
> =20
>
>>Dimitri,
>>
>>Here are my comments on the subject document:
>>
>>  General - Describe the relationship of OSPF areas to ASON RAs.
>>  Section 6.1 references     OSPF area ID but the relationship
>>  is implied.
>>
>>[dp] point taken (i guess we did not do a sufficiently good job in RFC

>>4258 and in the eval doc. as still some questioning remains about=20
>>information map)
>>
>>Section  3.2 - The length calculation is simply wrong.  You
>> really don't know how many prefixes you've got until you've
>> parsed them.
>>
>>[dp] which length are you referring to ? the prefix or the sub-TLV ?
>>
>>
>>   =20
>>
>The TLV length, the nonesense below:
>
>The Length is set to Sum[n][4 + #32-bit words/4] where n is the=20
>   number of local prefixes included in the sub-TLV.=20
>
>[dp] 4 x n as defined in the node i-d is ok - why not this one=20
>
> =20
>
>>Section 5.1 - RFC 3620 specifies that the Link-ID Sub-TLV
>> specifies the router-id. Why do you need the remote router-id
>> in this sub-TLV? Could the 5.2 sub-TLV satisfy the
>> requirement?
>>
>>[dp] it is not the router_id but the TE router_ID
>>   =20
>>
>
> =20
>
>>[dp] the issue is that there is no more a there is no more a 1:1=20
>>relationship between the Router_ID and the TE Router_ID in the present

>>context
>>   =20
>>
>
>I surmised that. Why wouldn't the link ID be the remote TE router ID in
>this case? The advertising router seems irrelevant from a TE
standpoint.
>
>[dp] because the router_id is not linked on a 1:1 basis to the TE
>router_id when space is per TE_router_id you need to seggregate this
>information
>
> =20
>
>>Section 6.0 - You should NOT need to change OSPF flooding rules.
>> In other words, I don't see the need to specify the following:
>>
>> The Opaque TE LSA re-origination is governed as follows:
>>   - If the target interface is associated to the same area as the
>>     one associated with the receiving interface, the Opaque LSA MUST
>>     NOT be re-originated out that interface.
>>   - If a match is found between the Advertising Router ID in the
>>     header of the received Opaque TE LSA and one of the Router ID
>>     belonging to the area of the target interface, the Opaque LSA
>>     MUST NOT be re-originated out that interface.
>>   - If these two conditions are not met the Opaque TE LSA MAY be re-
>>     originated.
>>
>> Rather you should specify rules for importing/exporting  information=20
>>between OSPF instances at different levels.
>>
>>[dp] your proposal is thus to revise these as import/export rules ?
>>in order to prevent having specific flooding rules between levels the=20
>>point was to not expand too much on the communication process (inside=20
>>the entity) between level adjacent RCs but if this makes you more=20
>>confortable i can revise as import/export rules
>>   =20
>>
>
>The existing RFC 3620 TE opaque LSAs are area scoped LSAs. Area scoped
>LSAs have very well defined flooding rules and, IMHO, you should not be
>trying to roll-your-own flooding rules for this application. Just think
>what a mess we'd have if every party proposed an opaque LSA also
>proposed some flooding hack for their opaque LSA type.
>
>[dp] i don't have any issue to express LSA processing with import and
>export rules (even if there is nothing in 3640 to pass LSA between
>routing
>instance)
>
> =20
>
>>Section 6.1 While an RA is completely contained within a single
>>  parent layer RA. A given    RA may have multiple child RAs.=20
>>Hence, the election algorithm is broken.=20
>>
>>[dp] to make it clear this is not an "election" process
>>
>>At a minimum,
>>  you must advertise all your child areas.  Also, you MUST state
>>  that reachability is a precondition for considering a router
>>  eligible to pass information between levels.
>>
>>[dp] upper not lower (it is a discovery from a given to an upper
parent
>>   =20
>>
>
> =20
>
>>viewpoint, where a child has a unique parent)
>>
>>
>>   =20
>>
>I get from RFC 4258 that a child RA will be contained within a single
>parent RA. However, no where do I that a parent RA can have a single
>child RA. So, if a single RC in a parent RA has multiple child RAs, you
>need to advertise more than one area ID.
>
>[dp] the parent is unique why multiple parent area id
>
>Also, you did not address the requirement for reachability. What if the
>RA becomes partitioned or the advertising RC goes down without
>withdrawing its advertisements.=20
>You MUST deal
>this - it is simply broken the way it is.
>
>[dp] situation is the same as with a single ABR case, in case of
>multiple RC's you are expected to be aware of the broken RC -
>
> =20
>
>>  Finally, since this is going to require advertisement of more
>>  than a single area-ID, please allocate a separate opaque LSA
>>  for ASON purposes.
>>
>>[dp] having clarified the above is that still needed ?
>>
>>
>>   =20
>>
>You only clarified that it is wrong.
>
>[dp] not sure to capture your point - but ok -=20
>
> =20
>
>>Section 6.2 - Are you suggesting a single area ID or an area ID
>>  path (similar to the BGP AS path)?=20
>>
>>[dp] the former
>>
>>I guess this may work if you
>>  always advertise you own area ID when redistributing between
>>  areas (relying on the fact that a child area is completely
>>  contained by its parent). I'm going to think more about this
>>  encourage others to do the same.
>>
>>General: Have you considered aggregation?
>>
>>[dp] at which level - reachability can be aggregated for inst.
>>
>>
>>   =20
>>
>Than the rules for aggregation should be specified.
>
>[dp] can add base guidelines if needed
>
>Thanks,
>Acee
>
> =20
>
>>Thanks,
>>Acee
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>   =20
>>
>
>
> =20
>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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

Envelope-to: ccamp-data@psg.com
Delivery-date: Thu, 06 Jul 2006 21:23:57 +0000
Message-ID: <44AD7F42.6070302@cisco.com>
Date: Thu, 06 Jul 2006 17:23:14 -0400
From: Acee Lindem <acee@cisco.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
MIME-Version: 1.0
To: "Ong, Lyndon" <Lyong@Ciena.com>
CC: Dimitri.Papadimitriou@alcatel.be, ccamp@ops.ietf.org, owner-ccamp@ops.ietf.org
Subject: Re: Comments on draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: a=rsa-sha1; q=dns; l=7408; t=1152220999; x=1153084999; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acee@cisco.com; z=From:Acee=20Lindem=20<acee@cisco.com> |Subject:Re=3A=20Comments=20on=20draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.t xt |To:=22Ong,=20Lyndon=22=20<Lyong@Ciena.com>; X=v=3Dcisco.com=3B=20h=3Dgo4Pb9+/SyFzptq1GgBjxsAHtqw=3D; b=LF01BwWPenY3imsJ/EpeERAde8lBhYwuw05kzgiNYK44T7qEnF4mCkW3HkvdbWHgBPZd7kIb QynD2P50GRbun7NQq5hJ/WbaS6qPY0vb/gP7EVPoKA2W6P43jC7XNibY;
Authentication-Results: rtp-dkim-1.cisco.com; header.From=acee@cisco.com; dkim=pass ( sig from cisco.com verified; );

Ong, Lyndon wrote:

>Hi Dimitri, Acee,
>
>Just a small comment on the Link_ID - I think Dimitri is right that the
>Link_ID and the Local/Remote TE_Router_ID have different meanings and
>must not be confused.  On the other hand, Acee may have a point that the
>Link_ID actually is no longer necessary once you have the Local/Remote
>TE_Router_ID - we found in some prototyping that with the separation
>of the Router_ID and TE_Router_ID that it became somewhat arbitrary as
>to what value you gave as the remote Router_ID, this was not used in
>  
>

>path computation at all.
>  
>
Hi Lyndon,

Exactly my point but I seemed to be getting into a circular argument. 
 From the standpoint of TE,
you only care about the entity to which link actually connects.  Also, 
is there any reason why
the TE router ID space and router-id space wouldn't overlapp? I don't 
see one.

Thanks,
Acee

>Cheers,
>
>Lyndon 
>
>-----Original Message-----
>From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On
>Behalf Of Dimitri.Papadimitriou@alcatel.be
>Sent: Thursday, July 06, 2006 11:12 AM
>To: Acee Lindem
>Cc: ccamp@ops.ietf.org; owner-ccamp@ops.ietf.org
>Subject: Re: Comments on
>draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt
>
>acee - see inline
>
>
>
>
>Acee Lindem <acee@cisco.com>
>Sent by: owner-ccamp@ops.ietf.org
>06/07/2006 18:36
> 
>        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
>        cc:     ccamp@ops.ietf.org
>        Subject:        Re: Comments on 
>draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt
>
>  
>
>>Dimitri,
>>
>>Here are my comments on the subject document:
>>
>>  General - Describe the relationship of OSPF areas to ASON RAs.
>>  Section 6.1 references     OSPF area ID but the relationship
>>  is implied.
>>
>>[dp] point taken (i guess we did not do a sufficiently good job in RFC 
>>4258 and in the eval doc. as still some questioning remains about 
>>information map)
>>
>>Section  3.2 - The length calculation is simply wrong.  You
>> really don't know how many prefixes you've got until you've
>> parsed them.
>>
>>[dp] which length are you referring to ? the prefix or the sub-TLV ?
>>
>>
>>    
>>
>The TLV length, the nonesense below:
>
>The Length is set to Sum[n][4 + #32-bit words/4] where n is the 
>   number of local prefixes included in the sub-TLV. 
>
>[dp] 4 x n as defined in the node i-d is ok - why not this one 
>
>  
>
>>Section 5.1 - RFC 3620 specifies that the Link-ID Sub-TLV
>> specifies the router-id. Why do you need the remote router-id
>> in this sub-TLV? Could the 5.2 sub-TLV satisfy the
>> requirement?
>>
>>[dp] it is not the router_id but the TE router_ID
>>    
>>
>
>  
>
>>[dp] the issue is that there is no more a there is no more a 1:1 
>>relationship between the Router_ID and the TE Router_ID in the present 
>>context
>>    
>>
>
>I surmised that. Why wouldn't the link ID be the remote TE router ID in
>this case? The advertising router seems irrelevant from a TE standpoint.
>
>[dp] because the router_id is not linked on a 1:1 basis to the TE
>router_id when space is per TE_router_id you need to seggregate this
>information
>
>  
>
>>Section 6.0 - You should NOT need to change OSPF flooding rules.
>> In other words, I don't see the need to specify the following:
>>
>> The Opaque TE LSA re-origination is governed as follows:
>>   - If the target interface is associated to the same area as the
>>     one associated with the receiving interface, the Opaque LSA MUST
>>     NOT be re-originated out that interface.
>>   - If a match is found between the Advertising Router ID in the
>>     header of the received Opaque TE LSA and one of the Router ID
>>     belonging to the area of the target interface, the Opaque LSA
>>     MUST NOT be re-originated out that interface.
>>   - If these two conditions are not met the Opaque TE LSA MAY be re-
>>     originated.
>>
>> Rather you should specify rules for importing/exporting  information 
>>between OSPF instances at different levels.
>>
>>[dp] your proposal is thus to revise these as import/export rules ?
>>in order to prevent having specific flooding rules between levels the 
>>point was to not expand too much on the communication process (inside 
>>the entity) between level adjacent RCs but if this makes you more 
>>confortable i can revise as import/export rules
>>    
>>
>
>The existing RFC 3620 TE opaque LSAs are area scoped LSAs. Area scoped
>LSAs have very well defined flooding rules and, IMHO, you should not be
>trying to roll-your-own flooding rules for this application. Just think
>what a mess we'd have if every party proposed an opaque LSA also
>proposed some flooding hack for their opaque LSA type.
>
>[dp] i don't have any issue to express LSA processing with import and
>export rules (even if there is nothing in 3640 to pass LSA between
>routing
>instance)
>
>  
>
>>Section 6.1 While an RA is completely contained within a single
>>  parent layer RA. A given    RA may have multiple child RAs. 
>>Hence, the election algorithm is broken. 
>>
>>[dp] to make it clear this is not an "election" process
>>
>>At a minimum,
>>  you must advertise all your child areas.  Also, you MUST state
>>  that reachability is a precondition for considering a router
>>  eligible to pass information between levels.
>>
>>[dp] upper not lower (it is a discovery from a given to an upper parent
>>    
>>
>
>  
>
>>viewpoint, where a child has a unique parent)
>>
>>
>>    
>>
>I get from RFC 4258 that a child RA will be contained within a single
>parent RA. However, no where do I that a parent RA can have a single
>child RA. So, if a single RC in a parent RA has multiple child RAs, you
>need to advertise more than one area ID.
>
>[dp] the parent is unique why multiple parent area id
>
>Also, you did not address the requirement for reachability. What if the
>RA becomes partitioned or the advertising RC goes down without
>withdrawing its advertisements. 
>You MUST deal
>this - it is simply broken the way it is.
>
>[dp] situation is the same as with a single ABR case, in case of
>multiple RC's you are expected to be aware of the broken RC -
>
>  
>
>>  Finally, since this is going to require advertisement of more
>>  than a single area-ID, please allocate a separate opaque LSA
>>  for ASON purposes.
>>
>>[dp] having clarified the above is that still needed ?
>>
>>
>>    
>>
>You only clarified that it is wrong.
>
>[dp] not sure to capture your point - but ok - 
>
>  
>
>>Section 6.2 - Are you suggesting a single area ID or an area ID
>>  path (similar to the BGP AS path)? 
>>
>>[dp] the former
>>
>>I guess this may work if you
>>  always advertise you own area ID when redistributing between
>>  areas (relying on the fact that a child area is completely
>>  contained by its parent). I'm going to think more about this
>>  encourage others to do the same.
>>
>>General: Have you considered aggregation?
>>
>>[dp] at which level - reachability can be aggregated for inst.
>>
>>
>>    
>>
>Than the rules for aggregation should be specified.
>
>[dp] can add base guidelines if needed
>
>Thanks,
>Acee
>
>  
>
>>Thanks,
>>Acee
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>    
>>
>
>
>  
>

Envelope-to: ccamp-data@psg.com
Delivery-date: Thu, 06 Jul 2006 21:18:43 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Comments on draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt
Date: Thu, 6 Jul 2006 17:18:15 -0400
Message-ID: <0901D1988E815341A0103206A834DA07E7CE46@mdmxm02.ciena.com>
Thread-Topic: Comments on draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt
Thread-Index: AcahL8Q9zYBkCC26TVuY32a3RhnsBQAENeYQ
From: "Ong, Lyndon" <Lyong@Ciena.com>
To: <Dimitri.Papadimitriou@alcatel.be>, "Acee Lindem" <acee@cisco.com>
Cc: <ccamp@ops.ietf.org>, <owner-ccamp@ops.ietf.org>

Hi Dimitri, Acee,

Just a small comment on the Link_ID - I think Dimitri is right that the
Link_ID and the Local/Remote TE_Router_ID have different meanings and
must not be confused.  On the other hand, Acee may have a point that the
Link_ID actually is no longer necessary once you have the Local/Remote
TE_Router_ID - we found in some prototyping that with the separation
of the Router_ID and TE_Router_ID that it became somewhat arbitrary as
to what value you gave as the remote Router_ID, this was not used in
path computation at all.

Cheers,

Lyndon=20

-----Original Message-----
From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On
Behalf Of Dimitri.Papadimitriou@alcatel.be
Sent: Thursday, July 06, 2006 11:12 AM
To: Acee Lindem
Cc: ccamp@ops.ietf.org; owner-ccamp@ops.ietf.org
Subject: Re: Comments on
draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt

acee - see inline

Acee Lindem <acee@cisco.com>
Sent by: owner-ccamp@ops.ietf.org
06/07/2006 18:36
=20
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     ccamp@ops.ietf.org
        Subject:        Re: Comments on=20
draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt

>Dimitri,
>
>Here are my comments on the subject document:
>
>   General - Describe the relationship of OSPF areas to ASON RAs.
>   Section 6.1 references     OSPF area ID but the relationship
>   is implied.
>
>[dp] point taken (i guess we did not do a sufficiently good job in RFC=20
>4258 and in the eval doc. as still some questioning remains about=20
>information map)
>
>Section  3.2 - The length calculation is simply wrong.  You
>  really don't know how many prefixes you've got until you've
>  parsed them.
>
>[dp] which length are you referring to ? the prefix or the sub-TLV ?
>=20
>
The TLV length, the nonesense below:

The Length is set to Sum[n][4 + #32-bit words/4] where n is the=20
   number of local prefixes included in the sub-TLV.=20

[dp] 4 x n as defined in the node i-d is ok - why not this one=20

>Section 5.1 - RFC 3620 specifies that the Link-ID Sub-TLV
>  specifies the router-id. Why do you need the remote router-id
>  in this sub-TLV? Could the 5.2 sub-TLV satisfy the
>  requirement?
>
>[dp] it is not the router_id but the TE router_ID

>[dp] the issue is that there is no more a there is no more a 1:1=20
>relationship between the Router_ID and the TE Router_ID in the present=20
>context

I surmised that. Why wouldn't the link ID be the remote TE router ID in
this case? The advertising router seems irrelevant from a TE standpoint.

[dp] because the router_id is not linked on a 1:1 basis to the TE
router_id when space is per TE_router_id you need to seggregate this
information

>Section 6.0 - You should NOT need to change OSPF flooding rules.
>  In other words, I don't see the need to specify the following:
>
>  The Opaque TE LSA re-origination is governed as follows:
>    - If the target interface is associated to the same area as the
>      one associated with the receiving interface, the Opaque LSA MUST
>      NOT be re-originated out that interface.
>    - If a match is found between the Advertising Router ID in the
>      header of the received Opaque TE LSA and one of the Router ID
>      belonging to the area of the target interface, the Opaque LSA
>      MUST NOT be re-originated out that interface.
>    - If these two conditions are not met the Opaque TE LSA MAY be re-
>      originated.
>
>  Rather you should specify rules for importing/exporting  information=20
> between OSPF instances at different levels.
>
>[dp] your proposal is thus to revise these as import/export rules ?
>in order to prevent having specific flooding rules between levels the=20
>point was to not expand too much on the communication process (inside=20
>the entity) between level adjacent RCs but if this makes you more=20
>confortable i can revise as import/export rules

The existing RFC 3620 TE opaque LSAs are area scoped LSAs. Area scoped
LSAs have very well defined flooding rules and, IMHO, you should not be
trying to roll-your-own flooding rules for this application. Just think
what a mess we'd have if every party proposed an opaque LSA also
proposed some flooding hack for their opaque LSA type.

[dp] i don't have any issue to express LSA processing with import and
export rules (even if there is nothing in 3640 to pass LSA between
routing
instance)

>Section 6.1 While an RA is completely contained within a single
>   parent layer RA. A given    RA may have multiple child RAs.=20
>Hence, the election algorithm is broken.=20
>
>[dp] to make it clear this is not an "election" process
>
>At a minimum,
>   you must advertise all your child areas.  Also, you MUST state
>   that reachability is a precondition for considering a router
>   eligible to pass information between levels.
>
>[dp] upper not lower (it is a discovery from a given to an upper parent

>viewpoint, where a child has a unique parent)
>=20
>
I get from RFC 4258 that a child RA will be contained within a single
parent RA. However, no where do I that a parent RA can have a single
child RA. So, if a single RC in a parent RA has multiple child RAs, you
need to advertise more than one area ID.

[dp] the parent is unique why multiple parent area id

Also, you did not address the requirement for reachability. What if the
RA becomes partitioned or the advertising RC goes down without
withdrawing its advertisements.=20
You MUST deal
this - it is simply broken the way it is.

[dp] situation is the same as with a single ABR case, in case of
multiple RC's you are expected to be aware of the broken RC -

>   Finally, since this is going to require advertisement of more
>   than a single area-ID, please allocate a separate opaque LSA
>   for ASON purposes.
>
>[dp] having clarified the above is that still needed ?
>=20
>
You only clarified that it is wrong.

[dp] not sure to capture your point - but ok -=20

>Section 6.2 - Are you suggesting a single area ID or an area ID
>   path (similar to the BGP AS path)?=20
>
>[dp] the former
>
>I guess this may work if you
>   always advertise you own area ID when redistributing between
>   areas (relying on the fact that a child area is completely
>   contained by its parent). I'm going to think more about this
>   encourage others to do the same.
>
>General: Have you considered aggregation?
>
>[dp] at which level - reachability can be aggregated for inst.
>=20
>
Than the rules for aggregation should be specified.

[dp] can add base guidelines if needed

Thanks,
Acee

>
>Thanks,
>Acee
>
>
>
>
>
>
>
>=20
>

Envelope-to: ccamp-data@psg.com
Delivery-date: Thu, 06 Jul 2006 21:12:38 +0000
Message-ID: <002e01c6a140$bb2fd1d0$7d1810ac@movaz.com>
From: "Igor Bryskin" <ibryskin@movaz.com>
To: "Lou Berger" <lberger@labn.net>, "Yakov Rekhter" <yakov@juniper.net>
Cc: "Rahul Aggarwal" <rahul@juniper.net>, <p2mp@labn.net>, <mpls@ietf.org>, <ccamp@ops.ietf.org>
Subject: Re: draft-ietf-mpls-rsvp-te-p2mp-06.txt [P2MP ID] 
Date: Thu, 6 Jul 2006 17:11:21 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Yakov,

Let's discuss some practical issues.

Suppose, I (as a operator or a management application) decided to change a
root of an existing P2MP tunnel (perhaps, because it has crashed) while
maintaining the same set of receivers. Rather than re-signaling entire
tunnel, I'd rather issue a P2MP Path message from a new root that will
modify the head of the tunnel- the rest of the tunnel will see this
operation as a MBB procedure with no modifications in the data plane. Note
that this would be possible with the P2MP tunnel identification suggested by
the draft and won't be possible with your scheme.

Furthermore, a P2MP tunnel could be built of multiple P2MP LSPs originated
not necessarily on the tunnel root. Once we discussed with Kireeti a
hierarchical P2MP tunnel. Suppose a tunnel needs to support 10000 leaves.
The root of the tunnel can originate a P2MP LSP to 100 (intermediate)
leaves, each of which could originate a P2MP LSP of it's own to 100  leaves.
It should be a very scalable approach because the root does not need to know
about all 10000 leaves (neither a leaf needs to know about the identity of
the tunnel root). In order to make this work we need to identify the tunnel
independently from the root.

So, I vote to keep the tunnel identification as it is described in the
draft.

Igor

----- Original Message ----- 
From: "Yakov Rekhter" <yakov@juniper.net>
To: "Lou Berger" <lberger@labn.net>
Cc: "Rahul Aggarwal" <rahul@juniper.net>; <p2mp@labn.net>; <mpls@ietf.org>;
<ccamp@ops.ietf.org>
Sent: Wednesday, July 05, 2006 3:18 PM
Subject: Re: draft-ietf-mpls-rsvp-te-p2mp-06.txt [P2MP ID]

> Lou,
>
> > At 10:39 AM 7/5/2006, Yakov Rekhter wrote:
> > >Could you please provide *technical* reason(s) that would explain why
> > >a combination of P2MP ID and Extended Tunnel ID is not sufficient ?
> > >
> > >Yakov.
> >
> > Yakov,
> >          Simply, because that's the way MPLS and GMPLS is specified
> > today and works in running code.
> >
> > If you want to change something from the way it works today, i.e, in
> > RFC3209 and 3473 (and really 2205), IMO it's incumbent on you to
> > justify why what's there needs to be changed.  The case has been made
> > for why the session object must use a P2MP ID rather than a
> > destination IP address.  The case has not been made for changing the
> > definition or semantics of Tunnel ID.
> >
> > Can provide the justification of why we need to deviate from current
> > specs on definition of Tunnel ID?
>
> Are you saying that the only reason we have to use Tunnel ID as
> part of a p2mp tunnel identifier is because Tunnel ID is used as
> part of a p2p tunnel identifier ?
>
> Yakov.
>

Envelope-to: ccamp-data@psg.com
Delivery-date: Thu, 06 Jul 2006 19:57:25 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: draft-fedyk-gmpls-ethernet-pbt-00.txt
Date: Thu, 6 Jul 2006 15:56:36 -0400
Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA409551F7D@zrtphxm2.corp.nortel.com>
Thread-Topic: draft-fedyk-gmpls-ethernet-pbt-00.txt
Thread-Index: AcaZLe5yO/C0CMCSQuC/mY0ecCDxpAACFi0QAMp1WpAAYDN3sACXBtLQADazIoA=
From: "Don Fedyk" <dwfedyk@nortel.com>
To: <alan.mcguire@bt.com>, <ccamp@ops.ietf.org>, <gels@rtg.ietf.org>

Hi Alan=20

> -----Original Message-----
> From: owner-ccamp@ops.ietf.org=20
> [mailto:owner-ccamp@ops.ietf.org] On Behalf Of alan.mcguire@bt.com
> =20
> Don,
> I think that you and your co-authors have produced a very=20
> good draft. It provides a concise description of the PBT=20
> concept and how the control plane can be employed. It also=20
> covers the main areas that need to be addressed
>=20
> Some observations and comments.=20
>=20
> For the protection options it would be useful to indicate if=20
> the schemes are undirectional, bidirectional, with APS or=20
> without, or whether there are any restrictions on use of=20
> these. It might also be useful to indicate how the VID's are=20
> allocated in each scheme, e.g. different VLAN Ids for each path in 1:1
These are bi-directional. The plans is OAM and protection is
bidirectional.  We should clarify in the document if it is APS.  My
opinion is it is close to APS.=20
>=20
> There are a number of minor typo's (can send you a list) but=20
> the following one should be clarified for the group in=20
> relation to section 8.1:
You can send me any typo fixes.=20

> "In the case of CCM OAM cells the detection time is a=20
> typically 3.5 the CCM interval + the propagation delay from=20
> the fault" Are you refering to the fast detection interval=20
> for CCM frames?
Yes

> In which case this should be in ms. Also think it should be=20
> 3.3 ms, though would suggest you check latest version of=20
> Y.1731. Or do you mean something else?
We will clarify, Yes Milliseconds, Yes Y.1731.=20

>=20
> You state that the OAM parameters are tunable. I would expect=20
> that in most cases for the same service the OAM parameters=20
> would be the same (though potentially different for different=20
> services).
Yes on a service basis but also based on an any protection coordination
requirements (underlying capability).=20

> Would you anticiptate that when a network operator sets up a=20
> path that the OAM parameters for that type of path are=20
> already known when the path is setup so that the OAM is=20
> immediately active, rather than being post setup activated?=20
Immediate activation would be the normal approach.=20
> Similarly deactivated when reoved so that there are no false alarms.
This requirement is for a graceful shutdown mode?  GMPLS does have
administrative signals but we have not looked to see if these would be
appropriate for this particular case.=20

>=20
> It would be helpful to add something about CAC and traffic=20
> engineering.
> When there is no over-subscription or partitioning of the=20
> VLAN space there is really nothing new to add. However, if=20
> the VID space is partitioned it would be useful to make some=20
> observations about how bandwidth is allocated/enforced=20
> between the different schemes.
We could look at this and describe it.=20

>=20
> VLAN IDs are allocated to PBT or for other purposes. Would be=20
> useful to explicitly indicate if there any VLAN IDs that=20
> cannot be used in PBT.
> E.g. VLAN zero, VLAN 4095. When VLAN ID ranges are allocated=20
> to PBT are there any rules regarding this allocation on a per=20
> end point basis. For example can different endpoints have=20
> different VLAN ranges. If not then some scheme is required to=20
> achieve this, e.g. management.
Good points we should clarify this policy.=20

Thanks,
Don=20

>=20
> Regards,
> Alan=20
>=20
>=20
>=20

Envelope-to: ccamp-data@psg.com
Delivery-date: Thu, 06 Jul 2006 19:06:53 +0000
To: Acee Lindem <acee@cisco.com>
Cc: ccamp@ops.ietf.org, owner-ccamp@ops.ietf.org
Subject: Re: Comments on draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt
MIME-Version: 1.0
Message-ID: <OF33D55062.F7C216B5-ONC12571A3.005C6576-C12571A3.0063FC54@netfr.alcatel.fr>
From: Dimitri.Papadimitriou@alcatel.be
Date: Thu, 6 Jul 2006 20:12:04 +0200
Content-Type: text/plain; charset="US-ASCII"

acee - see inline

Acee Lindem <acee@cisco.com>
Sent by: owner-ccamp@ops.ietf.org
06/07/2006 18:36

        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     ccamp@ops.ietf.org
        Subject:        Re: Comments on 
draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt

>Dimitri,
>
>Here are my comments on the subject document:
>
>   General - Describe the relationship of OSPF areas to ASON RAs.
>   Section 6.1 references     OSPF area ID but the relationship
>   is implied.
>
>[dp] point taken (i guess we did not do a sufficiently good
>job in RFC 4258 and in the eval doc. as still some questioning
>remains about information map)
>
>Section  3.2 - The length calculation is simply wrong.  You
>  really don't know how many prefixes you've got until you've
>  parsed them.
>
>[dp] which length are you referring to ? the prefix or the sub-TLV ?
> 
>
The TLV length, the nonesense below:

The Length is set to Sum[n][4 + #32-bit words/4] where n is the 
   number of local prefixes included in the sub-TLV. 

[dp] 4 x n as defined in the node i-d is ok - why not this one 

>Section 5.1 - RFC 3620 specifies that the Link-ID Sub-TLV
>  specifies the router-id. Why do you need the remote router-id
>  in this sub-TLV? Could the 5.2 sub-TLV satisfy the
>  requirement?
>
>[dp] it is not the router_id but the TE router_ID

>[dp] the issue is that there is no more a there is no 
>more a 1:1 relationship between the Router_ID and the TE 
>Router_ID in the present context

I surmised that. Why wouldn't the link ID be the remote TE router ID in 
this
case? The advertising router seems irrelevant from a TE standpoint.

[dp] because the router_id is not linked on a 1:1 basis to the TE 
router_id
when space is per TE_router_id you need to seggregate this information

>Section 6.0 - You should NOT need to change OSPF flooding rules.
>  In other words, I don't see the need to specify the following:
>
>  The Opaque TE LSA re-origination is governed as follows:
>    - If the target interface is associated to the same area as the
>      one associated with the receiving interface, the Opaque LSA MUST
>      NOT be re-originated out that interface.
>    - If a match is found between the Advertising Router ID in the
>      header of the received Opaque TE LSA and one of the Router ID
>      belonging to the area of the target interface, the Opaque LSA
>      MUST NOT be re-originated out that interface.
>    - If these two conditions are not met the Opaque TE LSA MAY be re-
>      originated.
>
>  Rather you should specify rules for importing/exporting
>  information between OSPF instances at different levels.
>
>[dp] your proposal is thus to revise these as import/export rules ?
>in order to prevent having specific flooding rules between levels
>the point was to not expand too much on the communication process
>(inside the entity) between level adjacent RCs but if this makes
>you more confortable i can revise as import/export rules

The existing RFC 3620 TE opaque LSAs are area scoped LSAs. Area scoped 
LSAs
have very well defined flooding rules and, IMHO, you should not be trying 
to
roll-your-own flooding rules for this application. Just think what a 
mess we'd have
if every party proposed an opaque LSA also proposed some flooding hack for
their opaque LSA type.

[dp] i don't have any issue to express LSA processing with import and 
export
rules (even if there is nothing in 3640 to pass LSA between routing 
instance)

>Section 6.1 While an RA is completely contained within a single
>   parent layer RA. A given    RA may have multiple child RAs. 
>Hence, the election algorithm is broken. 
>
>[dp] to make it clear this is not an "election" process
>
>At a minimum,
>   you must advertise all your child areas.  Also, you MUST state
>   that reachability is a precondition for considering a router
>   eligible to pass information between levels.
>
>[dp] upper not lower (it is a discovery from a given to an upper
>parent viewpoint, where a child has a unique parent)
> 
>
I get from RFC 4258 that a child RA will be contained within a single 
parent RA. However,
no where do I that a parent RA can have a single child RA. So, if a 
single RC in a parent
RA has multiple child RAs, you need to advertise more than one area ID.

[dp] the parent is unique why multiple parent area id

Also, you did not address the requirement for reachability. What if the 
RA becomes partitioned
or the advertising RC goes down without withdrawing its advertisements. 
You MUST deal
this - it is simply broken the way it is.

[dp] situation is the same as with a single ABR case, in case of 
multiple RC's you are expected to be aware of the broken RC -

>   Finally, since this is going to require advertisement of more
>   than a single area-ID, please allocate a separate opaque LSA
>   for ASON purposes.
>
>[dp] having clarified the above is that still needed ?
> 
>
You only clarified that it is wrong.

[dp] not sure to capture your point - but ok - 

>Section 6.2 - Are you suggesting a single area ID or an area ID
>   path (similar to the BGP AS path)? 
>
>[dp] the former
>
>I guess this may work if you
>   always advertise you own area ID when redistributing between
>   areas (relying on the fact that a child area is completely
>   contained by its parent). I'm going to think more about this
>   encourage others to do the same.
>
>General: Have you considered aggregation?
>
>[dp] at which level - reachability can be aggregated for inst.
> 
>
Than the rules for aggregation should be specified.

[dp] can add base guidelines if needed

Thanks,
Acee

>
>Thanks,
>Acee
>
>
>
>
>
>
>
> 
>

Envelope-to: ccamp-data@psg.com
Delivery-date: Thu, 06 Jul 2006 16:37:12 +0000
Message-ID: <44AD3C07.7080702@cisco.com>
Date: Thu, 06 Jul 2006 12:36:23 -0400
From: Acee Lindem <acee@cisco.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
MIME-Version: 1.0
To: Dimitri.Papadimitriou@alcatel.be
CC: ccamp@ops.ietf.org
Subject: Re: Comments on draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: a=rsa-sha1; q=dns; l=5326; t=1152203785; x=1153067785; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acee@cisco.com; z=From:Acee=20Lindem=20<acee@cisco.com> |Subject:Re=3A=20Comments=20on=20draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.t xt |To:Dimitri.Papadimitriou@alcatel.be; X=v=3Dcisco.com=3B=20h=3Dgo4Pb9+/SyFzptq1GgBjxsAHtqw=3D; b=tFAw9pB2fzQAD5AdHXPbBpR324gseNFznl0aFFGE/42hAj9NGSyBU7lK6AWX4c9f6tqltiMU FD09PXd/D1nWYyo99P86RcQARM8388KgKMonVO+P9d7ywXHlxNItGb6r;
Authentication-Results: rtp-dkim-2.cisco.com; header.From=acee@cisco.com; dkim=pass ( sig from cisco.com verified; );

Dimitri.Papadimitriou@alcatel.be wrote:

>hi acee - thanks for commenting 
>  
>
Hi Dimitri,
Please see inline.

>one or two hints below such as to clarify some point you mentioned here 
>below
>
>
>
>
>Acee Lindem <acee@cisco.com>
>Sent by: owner-ccamp@ops.ietf.org
>06/07/2006 03:12
> 
>        To:     ccamp@ops.ietf.org
>        cc: 
>        Subject:        Comments on 
>draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt
>
>
>Dimitri,
>
>Here are my comments on the subject document:
>
>General - Describe the relationship of OSPF areas to ASON RAs.
>   Section 6.1 references     OSPF area ID but the relationship
>   is implied.
>
>[dp] point taken (i guess we did not do a sufficiently good
>job in RFC 4258 and in the eval doc. as still some questioning
>remains about information map)
>
>Section  3.2 - The length calculation is simply wrong.  You
>  really don't know how many prefixes you've got until you've
>  parsed them.
>
>[dp] which length are you referring to ? the prefix or the sub-TLV ?
>  
>
The TLV length, the nonesense below:

The Length is set to Sum[n][4 + #32-bit words/4] where n is the 
   number of local prefixes included in the sub-TLV. 

>Section 5.1 - RFC 3620 specifies that the Link-ID Sub-TLV
>  specifies the router-id. Why do you need the remote router-id
>  in this sub-TLV? Could the 5.2 sub-TLV satisfy the
>  requirement?
>
>[dp] it is not the router_id but the TE router_ID
>  
>

>[dp] the issue is that there is no more a there is no 
>more a 1:1 relationship between the Router_ID and the TE 
>Router_ID in the present context
>  
>
I surmised that. Why wouldn't the link ID be the remote TE router ID in this
case? The advertising router seems irrelevant from a TE standpoint.

>Section 6.0 - You should NOT need to change OSPF flooding rules.
>  In other words, I don't see the need to specify the following:
>
>  The Opaque TE LSA re-origination is governed as follows:
>    - If the target interface is associated to the same area as the
>      one associated with the receiving interface, the Opaque LSA MUST
>      NOT be re-originated out that interface.
>    - If a match is found between the Advertising Router ID in the
>      header of the received Opaque TE LSA and one of the Router ID
>      belonging to the area of the target interface, the Opaque LSA
>      MUST NOT be re-originated out that interface.
>    - If these two conditions are not met the Opaque TE LSA MAY be re-
>      originated.
>
>  Rather you should specify rules for importing/exporting
>  information between OSPF instances at different levels.
>
>[dp] your proposal is thus to revise these as import/export rules ?
>in order to prevent having specific flooding rules between levels
>the point was to not expand too much on the communication process
>(inside the entity) between level adjacent RCs but if this makes
>you more confortable i can revise as import/export rules
>  
>
The existing RFC 3620 TE opaque LSAs are area scoped LSAs. Area scoped LSAs
have very well defined flooding rules and, IMHO, you should not be trying to
roll-your-own flooding rules for this application. Just think what a 
mess we'd have
if every party proposed an opaque LSA also proposed some flooding hack for
their opaque LSA type.

>Section 6.1 While an RA is completely contained within a single
>   parent layer RA. A given    RA may have multiple child RAs. 
>Hence, the election algorithm is broken. 
>
>[dp] to make it clear this is not an "election" process
>
>At a minimum,
>   you must advertise all your child areas.  Also, you MUST state
>   that reachability is a precondition for considering a router
>   eligible to pass information between levels.
>
>[dp] upper not lower (it is a discovery from a given to an upper
>parent viewpoint, where a child has a unique parent)
>  
>
I get from RFC 4258 that a child RA will be contained within a single 
parent RA. However,
no where do I that a parent RA can have a single child RA. So, if a 
single RC in a parent
RA has multiple child RAs, you need to advertise more than one area ID.

Also, you did not address the requirement for reachability. What if the 
RA becomes partitioned
or the advertising RC goes down without withdrawing its advertisements. 
You MUST deal
this - it is simply broken the way it is.

>   Finally, since this is going to require advertisement of more
>   than a single area-ID, please allocate a separate opaque LSA
>   for ASON purposes.
>
>[dp] having clarified the above is that still needed ?
>  
>
You only clarified that it is wrong.

>Section 6.2 - Are you suggesting a single area ID or an area ID
>   path (similar to the BGP AS path)? 
>
>[dp] the former
>
>I guess this may work if you
>   always advertise you own area ID when redistributing between
>   areas (relying on the fact that a child area is completely
>   contained by its parent). I'm going to think more about this
>   encourage others to do the same.
>
>General: Have you considered aggregation?
>
>[dp] at which level - reachability can be aggregated for inst.
>  
>
Than the rules for aggregation should be specified.

Thanks,
Acee

>
>Thanks,
>Acee
>
>
>
>
>
>
>
>  
>

Envelope-to: ccamp-data@psg.com
Delivery-date: Thu, 06 Jul 2006 14:57:52 +0000
Message-Id: <7.0.1.0.2.20060706105207.06501858@labn.net>
Date: Thu, 06 Jul 2006 10:57:04 -0400
To: Yakov Rekhter <yakov@juniper.net>
From: Lou Berger <lberger@labn.net>
Subject: Re: draft-ietf-mpls-rsvp-te-p2mp-06.txt [P2MP ID] 
Cc: Lou Berger <lberger@labn.net>,Rahul Aggarwal <rahul@juniper.net>, p2mp@labn.net,mpls@ietf.org,ccamp@ops.ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Yakov,

At 03:18 PM 7/5/2006, Yakov Rekhter wrote:

>Lou,
>
> > At 10:39 AM 7/5/2006, Yakov Rekhter wrote:
> > >Could you please provide *technical* reason(s) that would explain why
> > >a combination of P2MP ID and Extended Tunnel ID is not sufficient ?
> > >
> > >Yakov.
> >
> > Yakov,
> >          Simply, because that's the way MPLS and GMPLS is specified
> > today and works in running code.
> >
> > If you want to change something from the way it works today, i.e, in
> > RFC3209 and 3473 (and really 2205), IMO it's incumbent on you to
> > justify why what's there needs to be changed.  The case has been made
> > for why the session object must use a P2MP ID rather than a
> > destination IP address.  The case has not been made for changing the
> > definition or semantics of Tunnel ID.
> >
> > Can provide the justification of why we need to deviate from current
> > specs on definition of Tunnel ID?
>
>Are you saying that the only reason we have to use Tunnel ID as
>part of a p2mp tunnel identifier is because Tunnel ID is used as
>part of a p2p tunnel identifier ?

I didn't say that.  What I said is the same thing that George said: 
That the onus is on you to state why we should deviate from current 
spec and practice.

If you care to, can you articulate any reason to justify this 
change?  If not, we should leave the definition unchanged and move on.

Lou

>Yakov.

Envelope-to: ccamp-data@psg.com
Delivery-date: Thu, 06 Jul 2006 14:45:41 +0000
Message-ID: <0679BA70A2F59E49B186858B47F4595C4E001D@viper.sycamorenet.com>
From: "Pandian, Vijay" <Vijay.Pandian@sycamorenet.com>
To: "'Dimitri.Papadimitriou@alcatel.be'" <Dimitri.Papadimitriou@alcatel.be>
Cc: "'ospf@ietf.org'" <ospf@ietf.org>, "'mpls@ietf.org'" <mpls@ietf.org>,  "'ccamp@ops.ietf.org'" <ccamp@ops.ietf.org>
Subject: RE: RFC3630 - Local and Remote Interface IP address
Date: Thu, 6 Jul 2006 10:44:25 -0400 
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"

Hi Dimitri,

Section 2.4.2 of rfc3630 says: "The Link TLV describes a single link."

Section 2.5.3 of rfc3630 says: "The Local Interface IP Address sub-TLV
specifies the IP address(es) of the interface corresponding to this link."

Section 2.5.4 of rfc3630 says: "The Remote Interface IP Address sub-TLV
specifies the IP address(es) of the neighbor's interface corresponding to
this link."

Doesn't this mean the Local and Remote Interface IP Address sub-TLV
corresponds to just ONE TE-Link?

There is no mention of "components" anywhere in this document. Even in
rfc4201, it is not clear that when multiple (component) TE-Links are
aggregated as a single numbered bundled link, there can be more than one
Interface IP address used for Local and Remote Interface IP Address.

Could you please provide a reference where this is clarified as the mean for
advertising multiple components at once. 

Thanks and best regards,

Vijay

-----Original Message-----
From: Dimitri.Papadimitriou@alcatel.be
[mailto:Dimitri.Papadimitriou@alcatel.be]
Sent: Thursday, July 06, 2006 1:57 AM
To: Pandian, Vijay
Subject: Re: RFC3630 - Local and Remote Interface IP address

hi vijay - this was meant for advertizing multiple components at once

"Pandian, Vijay" <Vijay.Pandian@sycamorenet.com>
Sent by: owner-ccamp@ops.ietf.org
06/07/2006 02:56

        To:     ospf@ietf.org
        cc:     mpls@ietf.org, ccamp@ops.ietf.org
        Subject:        RFC3630 - Local and Remote Interface IP address

Section 2.5.3 indicates that there can be more than one Local Interface IP 
address assigned to a (numbered) TE-Link. Similarly, section 2.5.4 
indicates that there can be more than one Remote Interface IP Address 
assigned to a (numbered) TE-Link.

Is there any requirement that the number of Local Interface IP address 
assigned to a given TE-link match the number of Remote Interface IP 
address.

Specifically, can a TE-Link have just one Local Interface IP address but 
multiple Remote Interface IP Address or vice-versa?

Best regards,

Vijay

Envelope-to: ccamp-data@psg.com
Delivery-date: Thu, 06 Jul 2006 10:18:02 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: draft-fedyk-gmpls-ethernet-pbt-00.txt
Date: Thu, 6 Jul 2006 11:15:55 +0100
Message-ID: <91A1302378CDCE41A2B8229D0BA7E5D50712E0B6@I2KM11-UKBR.domain1.systemhost.net>
Thread-Topic: draft-fedyk-gmpls-ethernet-pbt-00.txt
Thread-Index: AcaZLe5yO/C0CMCSQuC/mY0ecCDxpAACFi0QAMp1WpAAYDN3sACXBtLQ
From: <alan.mcguire@bt.com>
To: <ccamp@ops.ietf.org>, <gels@rtg.ietf.org>, <dwfedyk@nortel.com>

=20
Don,
I think that you and your co-authors have produced a very good draft. It
provides a concise description of the PBT concept and how the control
plane can be employed. It also covers the main areas that need to be
addressed

Some observations and comments.=20

For the protection options it would be useful to indicate if the schemes
are undirectional, bidirectional, with APS or without, or whether there
are any restrictions on use of these. It might also be useful to
indicate how the VID's are allocated in each scheme, e.g. different VLAN
Ids for each path in 1:1

There are a number of minor typo's (can send you a list) but the
following one should be clarified
for the group in relation to section 8.1:
"In the case of CCM OAM cells the detection time is a typically 3.5 the
CCM
interval + the propagation delay from the fault" Are you refering to the
fast detection interval for CCM frames?
In which case this should be in ms. Also think it should be 3.3 ms,
though would suggest you check latest version of Y.1731. Or do you mean
something else?

You state that the OAM parameters are tunable. I would expect that in
most cases for the same service the OAM parameters
would be the same (though potentially different for different services).
Would you anticiptate that when a network operator sets up a path that
the OAM parameters for that type of path are already known when the path
is setup so that the OAM is immediately active, rather than being post
setup activated? Similarly deactivated when reoved so that there are no
false alarms.

It would be helpful to add something about CAC and traffic engineering.
When there is no over-subscription or partitioning of the VLAN space
there is really nothing new to add. However, if the VID space is
partitioned it would be useful to make some observations about how
bandwidth is allocated/enforced between the different schemes.

VLAN IDs are allocated to PBT or for other purposes. Would be useful to
explicitly indicate if there any VLAN IDs that cannot be used in PBT.
E.g. VLAN zero, VLAN 4095. When VLAN ID ranges are allocated to PBT are
there any rules regarding this allocation on a per end point basis. For
example can different endpoints have different VLAN ranges. If not then
some scheme is required to achieve this, e.g. management.

Regards,
Alan=20

Envelope-to: ccamp-data@psg.com
Delivery-date: Thu, 06 Jul 2006 05:55:33 +0000
To: Acee Lindem <acee@cisco.com>
Cc: ccamp@ops.ietf.org, owner-ccamp@ops.ietf.org
Subject: Re: Comments on draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt
MIME-Version: 1.0
Message-ID: <OFDDAE9089.10A9690D-ONC12571A3.001CFEBB-C12571A3.001F3492@netfr.alcatel.fr>
From: Dimitri.Papadimitriou@alcatel.be
Date: Thu, 6 Jul 2006 07:40:49 +0200
Content-Type: text/plain; charset="US-ASCII"

hi acee - thanks for commenting 

one or two hints below such as to clarify some point you mentioned here 
below

Acee Lindem <acee@cisco.com>
Sent by: owner-ccamp@ops.ietf.org
06/07/2006 03:12

        To:     ccamp@ops.ietf.org
        cc: 
        Subject:        Comments on 
draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt

Dimitri,

Here are my comments on the subject document:

General - Describe the relationship of OSPF areas to ASON RAs.
   Section 6.1 references     OSPF area ID but the relationship
   is implied.

[dp] point taken (i guess we did not do a sufficiently good
job in RFC 4258 and in the eval doc. as still some questioning
remains about information map)

Section  3.2 - The length calculation is simply wrong.  You
  really don't know how many prefixes you've got until you've
  parsed them.

[dp] which length are you referring to ? the prefix or the sub-TLV ?

Section 5.1 - RFC 3620 specifies that the Link-ID Sub-TLV
  specifies the router-id. Why do you need the remote router-id
  in this sub-TLV? Could the 5.2 sub-TLV satisfy the
  requirement?

[dp] it is not the router_id but the TE router_ID

[dp] the issue is that there is no more a there is no 
more a 1:1 relationship between the Router_ID and the TE 
Router_ID in the present context

Section 6.0 - You should NOT need to change OSPF flooding rules.
  In other words, I don't see the need to specify the following:

  The Opaque TE LSA re-origination is governed as follows:
    - If the target interface is associated to the same area as the
      one associated with the receiving interface, the Opaque LSA MUST
      NOT be re-originated out that interface.
    - If a match is found between the Advertising Router ID in the
      header of the received Opaque TE LSA and one of the Router ID
      belonging to the area of the target interface, the Opaque LSA
      MUST NOT be re-originated out that interface.
    - If these two conditions are not met the Opaque TE LSA MAY be re-
      originated.

  Rather you should specify rules for importing/exporting
  information between OSPF instances at different levels.

[dp] your proposal is thus to revise these as import/export rules ?
in order to prevent having specific flooding rules between levels
the point was to not expand too much on the communication process
(inside the entity) between level adjacent RCs but if this makes
you more confortable i can revise as import/export rules

Section 6.1 While an RA is completely contained within a single
   parent layer RA. A given    RA may have multiple child RAs. 
Hence, the election algorithm is broken. 

[dp] to make it clear this is not an "election" process

At a minimum,
   you must advertise all your child areas.  Also, you MUST state
   that reachability is a precondition for considering a router
   eligible to pass information between levels.

[dp] upper not lower (it is a discovery from a given to an upper
parent viewpoint, where a child has a unique parent)

   Finally, since this is going to require advertisement of more
   than a single area-ID, please allocate a separate opaque LSA
   for ASON purposes.

[dp] having clarified the above is that still needed ?

Section 6.2 - Are you suggesting a single area ID or an area ID
   path (similar to the BGP AS path)? 

[dp] the former

I guess this may work if you
   always advertise you own area ID when redistributing between
   areas (relying on the fact that a child area is completely
   contained by its parent). I'm going to think more about this
   encourage others to do the same.

General: Have you considered aggregation?

[dp] at which level - reachability can be aggregated for inst.

Thanks,
Acee

Envelope-to: ccamp-data@psg.com
Delivery-date: Thu, 06 Jul 2006 01:12:28 +0000
Message-ID: <44AC636A.809@cisco.com>
Date: Wed, 05 Jul 2006 21:12:10 -0400
From: Acee Lindem <acee@cisco.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
MIME-Version: 1.0
To: ccamp@ops.ietf.org
Subject: Comments on draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: a=rsa-sha1; q=dns; l=2356; t=1152148331; x=1153012331; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acee@cisco.com; z=From:Acee=20Lindem=20<acee@cisco.com> |Subject:Comments=20on=20draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt |To:ccamp@ops.ietf.org; X=v=3Dcisco.com=3B=20h=3DUr9YgkDVcEBC0QDPaWzwpQbIYYM=3D; b=ThJiXQnTBTVnDJmQL1qH/Mhfkq4JjhhzEiAsI+LoRizTSU+evnrgjQlQU1qKACZe2ZakHoaD cCYlpdMDtST5iCoS29gcxvX+wc48IEA68meLrHCN7E4DzjOdln2NkY8b;
Authentication-Results: rtp-dkim-2.cisco.com; header.From=acee@cisco.com; dkim=pass ( sig from cisco.com verified; );

Dimitri,

Here are my comments on the subject document:

General - Describe the relationship of OSPF areas to ASON RAs.
   Section 6.1 references     OSPF area ID but the relationship
   is implied.

Section  3.2 - The length calculation is simply wrong.  You
  really don't know how many prefixes you've got until you've
  parsed them.

Section 5.1 - RFC 3620 specifies that the Link-ID Sub-TLV
  specifies the router-id. Why do you need the remote router-id
  in this sub-TLV? Could the 5.2 sub-TLV satisfy the
  requirement?

Section 6.0 - You should NOT need to change OSPF flooding rules.
  In other words, I don't see the need to specify the following:

  The Opaque TE LSA re-origination is governed as follows:
    - If the target interface is associated to the same area as the
      one associated with the receiving interface, the Opaque LSA MUST
      NOT be re-originated out that interface.
    - If a match is found between the Advertising Router ID in the
      header of the received Opaque TE LSA and one of the Router ID
      belonging to the area of the target interface, the Opaque LSA
      MUST NOT be re-originated out that interface.
    - If these two conditions are not met the Opaque TE LSA MAY be re-
      originated.

  Rather you should specify rules for importing/exporting
  information between OSPF instances at different levels.

Section 6.1 While an RA is completely contained within a single
   parent layer RA. A given    RA may have multiple child RAs. Hence,
   the election algorithm is broken.  At a minimum,
   you must advertise all your child areas.  Also, you MUST state
   that reachability is a precondition for considering a router
   eligible to pass information between levels.

   Finally, since this is going to require advertisement of more
   than a single area-ID, please allocate a separate opaque LSA
   for ASON purposes.

Section 6.2 - Are you suggesting a single area ID or an area ID
   path (similar to the BGP AS path)? I guess this may work if you
   always advertise you own area ID when redistributing between
   areas (relying on the fact that a child area is completely
   contained by its parent). I'm going to think more about this
   encourage others to do the same.

General: Have you considered aggregation?

Thanks,
Acee

Envelope-to: ccamp-data@psg.com
Delivery-date: Thu, 06 Jul 2006 00:57:23 +0000
Message-ID: <0679BA70A2F59E49B186858B47F4595C4E0014@viper.sycamorenet.com>
From: "Pandian, Vijay" <Vijay.Pandian@sycamorenet.com>
To: ospf@ietf.org
Cc: mpls@ietf.org, ccamp@ops.ietf.org
Subject: RFC3630 - Local and Remote Interface IP address
Date: Wed, 5 Jul 2006 20:56:06 -0400 
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6A096.F699C238"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C6A096.F699C238
Content-Type: text/plain;
	charset="iso-8859-1"

Section 2.5.3 indicates that there can be more than one Local Interface IP
address assigned to a (numbered) TE-Link. Similarly, section 2.5.4 indicates
that there can be more than one Remote Interface IP Address assigned to a
(numbered) TE-Link.

Is there any requirement that the number of Local Interface IP address
assigned to a given TE-link match the number of Remote Interface IP address.

Specifically, can a TE-Link have just one Local Interface IP address but
multiple Remote Interface IP Address or vice-versa?

Best regards,

Vijay

------_=_NextPart_001_01C6A096.F699C238
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">

<META content="MSHTML 6.00.2800.1543" name=GENERATOR></HEAD>
<BODY>
<DIV>Section 
2.5.3&nbsp;indicates that there can be more than one Local Interface IP address 
assigned to a (numbered) TE-Link. Similarly, section 2.5.4 indicates that there 
can be&nbsp;more than one Remote Interface IP Address assigned to a (numbered) 
TE-Link.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Is there any 
requirement that the number of Local Interface IP address assigned to a given 
TE-link match the number of Remote Interface IP address.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Specifically, can a 
TE-Link have just one Local Interface IP address but multiple Remote Interface 
IP Address or vice-versa?</DIV>
<DIV>&nbsp;</DIV>
<DIV>Best 
regards,</DIV>
<DIV>&nbsp;</DIV>
<DIV>Vijay</DIV></BODY></HTML>

------_=_NextPart_001_01C6A096.F699C238--

Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 05 Jul 2006 22:54:43 +0000
Date: Wed, 05 Jul 2006 17:56:39 -0500
From: YongLucy 73674 <lucyyong@huawei.com>
Subject: Re: RE: draft-fedyk-gmpls-ethernet-pbt-00.txt
To: Don Fedyk <dwfedyk@nortel.com>
Cc: Igor Bryskin <ibryskin@movaz.com>, ccamp@ops.ietf.org, gels@rtg.ietf.org
Message-id: <14ac1c147646.14764614ac1c@huawei.com>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline

Don,

Thank you for the response.
You bring the right points. A network needs to serve long term and short term connections. Thus, some connections need to plan ahead and some can be requested on demand. Current network seems to maintain two TEs for the purpose.
PCE based architecture brings an oppurtunity to hybrid them into one. However, this is out of scope of PCE WG job now. Maybe the PBT control plane is a good place to develop this hybrid structure.

When and where will your draft be discussed. I did not see on the agendas.
Hope we can discuss more on this in the meeting.

Best Regards,
Lucy Yong

*******************************************************************************************
 This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!
 *******************************************************************************************

----- Original Message -----
From: Don Fedyk <dwfedyk@nortel.com>
Date: Friday, June 30, 2006 2:44 pm
Subject: RE: draft-fedyk-gmpls-ethernet-pbt-00.txt

> Hi Lucy 
> 
> <snip>
> > > 
> > > Which model do you pursue for PBT, why?
> > Either model is appropriate. It comes down to a Network 
> > providers requirements to manage the network and the 
> > resources. For many reasons initial PBT services are static 
> > from a source/destination view point.
> > In some cases we will be starting from a centralized 
> > management system.
> > However, the aspects of GMPLS signaling and control allow a 
> > range of static to dynamic paths even though the endpoints 
> > are static. The real issues related to dynamic control are 
> > much like L1VPNs and some of Igor's comments.  If the service 
> > has an identifiable UNI a more dynamic model may be developed 
> > but right now we specifying the provider operations. 
> > 
> > [Lucy] On demand request from customer space could be 
> > implemented in two ways also, embedded network intelligence 
> > or management plane driven.
> > Somehow, I think this is the architecture design issue not 
> > strictly related to on demand request from customer. 
> > Basically, how we want to build an end to end forwarding 
> > path, rely on network intelligence or network management system?
> 
> Let me paraphrase your comment. Does the network have the intelligence
> for path creation or does the intelligent lie in the management 
> system? 
> I assume by network intelligence you meant he typical TE database? 
> Well, this is just my opinion, we know when path holding times are 
> longand network fill is a concern that centralized management 
> systems can
> add extra policy type operations that we do not have in today's 
> typicalTE network database.   
> We also know that when path turnaround times are short or there is 
> amplebandwidth that any reasonable path will do network 
> intelligence of today
> TE database is quite adequate. This leads me to believe that initial
> path requests will have  more centralized path control but path
> maintenance operations are logically handled be the network (eg
> rerouting, reversion etc). BTW centralized path control  may need 
> a PCE
> system not necessarily a management system. 
> 
> Of course the other interpretation of your question is do we 
> augment the
> network with more intelligence? In some ways we proposed to do 
> this for
> optical systems but uptake on augmenting the TE database has been slow
> going.  
> 
> I don't think that PBT is special in this regard I think that 
> generallythese questions are applicable to any of the GMPLS 
> systems. 
> 
> Regards,
> Don 
> > 
> > Regards,
> > Don 
> > 
> > > 
> > > Best Regards,
> > > Lucy Yong
> > >  
> > 
> > 
> > 
> > 
> > 
> > 
> 
> 

Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 05 Jul 2006 19:19:08 +0000
Message-Id: <200607051918.k65JID504310@merlot.juniper.net>
To: Lou Berger <lberger@labn.net>
cc: Rahul Aggarwal <rahul@juniper.net>, p2mp@labn.net, mpls@ietf.org, ccamp@ops.ietf.org
Subject: Re: draft-ietf-mpls-rsvp-te-p2mp-06.txt [P2MP ID] 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <71340.1152127093.1@juniper.net>
Date: Wed, 05 Jul 2006 12:18:13 -0700
From: Yakov Rekhter <yakov@juniper.net>

Lou,

> At 10:39 AM 7/5/2006, Yakov Rekhter wrote:
> >Could you please provide *technical* reason(s) that would explain why
> >a combination of P2MP ID and Extended Tunnel ID is not sufficient ?
> >
> >Yakov.
> 
> Yakov,
>          Simply, because that's the way MPLS and GMPLS is specified 
> today and works in running code.
>
> If you want to change something from the way it works today, i.e, in 
> RFC3209 and 3473 (and really 2205), IMO it's incumbent on you to 
> justify why what's there needs to be changed.  The case has been made 
> for why the session object must use a P2MP ID rather than a 
> destination IP address.  The case has not been made for changing the 
> definition or semantics of Tunnel ID.
> 
> Can provide the justification of why we need to deviate from current 
> specs on definition of Tunnel ID?

Are you saying that the only reason we have to use Tunnel ID as
part of a p2mp tunnel identifier is because Tunnel ID is used as
part of a p2p tunnel identifier ?

Yakov.

Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 05 Jul 2006 16:08:04 +0000
To: Lou Berger <lberger@labn.net>
Cc: Yakov Rekhter <yakov@juniper.net>, Rahul Aggarwal <rahul@juniper.net>, p2mp@labn.net, mpls@ietf.org, ccamp@ops.ietf.org
Cc: swallow@cisco.com
Subject: Re: draft-ietf-mpls-rsvp-te-p2mp-06.txt [P2MP ID] 
From: George Swallow <swallow@cisco.com>
Date: Wed, 05 Jul 2006 12:08:40 -0400
Message-Id: <20060705160840.43C1921D67D@SwallowPB.local>

>          Simply, because that's the way MPLS and GMPLS is specified
> today and works in running code.
> 
> If you want to change something from the way it works today, i.e, in
> RFC3209 and 3473 (and really 2205), IMO it's incumbent on you to
> justify why what's there needs to be changed.  The case has been made
> for why the session object must use a P2MP ID rather than a
> destination IP address.  The case has not been made for changing the
> definition or semantics of Tunnel ID.
> 
> Can provide the justification of why we need to deviate from current
> specs on definition of Tunnel ID?

Absolutely.  We didn't start with a blank piece of paper.  We're
building on existing things.  So the onus for argument, should you
choose to pursue it, is in your court.

...George

========================================================================
George Swallow             Cisco Systems                  (978) 936-1398
                           1414 Massachusetts Avenue
                           Boxborough, MA 01719

Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 05 Jul 2006 15:10:13 +0000
Message-Id: <7.0.1.0.2.20060705110255.05d5bd48@labn.net>
Date: Wed, 05 Jul 2006 11:09:44 -0400
To: Yakov Rekhter <yakov@juniper.net>
From: Lou Berger <lberger@labn.net>
Subject: Re: draft-ietf-mpls-rsvp-te-p2mp-06.txt [P2MP ID] 
Cc: Lou Berger <lberger@labn.net>,Rahul Aggarwal <rahul@juniper.net>, p2mp@labn.net,mpls@ietf.org,ccamp@ops.ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 10:39 AM 7/5/2006, Yakov Rekhter wrote:
>Could you please provide *technical* reason(s) that would explain why
>a combination of P2MP ID and Extended Tunnel ID is not sufficient ?
>
>Yakov.

Yakov,
         Simply, because that's the way MPLS and GMPLS is specified 
today and works in running code.

If you want to change something from the way it works today, i.e, in 
RFC3209 and 3473 (and really 2205), IMO it's incumbent on you to 
justify why what's there needs to be changed.  The case has been made 
for why the session object must use a P2MP ID rather than a 
destination IP address.  The case has not been made for changing the 
definition or semantics of Tunnel ID.

Can provide the justification of why we need to deviate from current 
specs on definition of Tunnel ID?

Lou 

Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 05 Jul 2006 14:59:18 +0000
Message-Id: <200607051458.k65Ewu527140@merlot.juniper.net>
To: George Swallow <swallow@cisco.com>
cc: Lou Berger <lberger@labn.net>, Rahul Aggarwal <rahul@juniper.net>, p2mp@labn.net, mpls@ietf.org, ccamp@ops.ietf.org
Subject: Re: draft-ietf-mpls-rsvp-te-p2mp-06.txt [P2MP ID] 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <53555.1152111536.1@juniper.net>
Date: Wed, 05 Jul 2006 07:58:56 -0700
From: Yakov Rekhter <yakov@juniper.net>

George,

> >       A combination of this address and P2MP ID
> >       provides a globally unique identifier for the P2MP tunnel.
> 
> I want this to be the full tuple:
> 
> <P2MP ID, Tunnel ID, Extended Tunnel ID>

That would be fine, *as long as* you provide *technical* justification(s)
on why <P2MP ID, Extended Tunnel ID> is not sufficient.

> Further we should only be calling this a globally unique identifier of a
> tunnel since the set of endpoint can change over the lifetime of the
> tunnel.

On that I certainly agree with you.

Yakov.

Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 05 Jul 2006 14:41:00 +0000
Message-Id: <200607051439.k65Edi519749@merlot.juniper.net>
To: Lou Berger <lberger@labn.net>
cc: Rahul Aggarwal <rahul@juniper.net>, p2mp@labn.net, mpls@ietf.org, ccamp@ops.ietf.org
Subject: Re: draft-ietf-mpls-rsvp-te-p2mp-06.txt [P2MP ID] 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <52992.1152110384.1@juniper.net>
Date: Wed, 05 Jul 2006 07:39:44 -0700
From: Yakov Rekhter <yakov@juniper.net>

Lou,

> >[clipped...]
> >
> > > > > > > >    The P2MP ID provides an identifier for the set of
> > > > > > > >    destinations of the P2MP TE Tunnel.
> > > > > > > >
> > > > > > > >The last sentence above has to be deleted.
> > > > > > >
> > > > > > > why, what's incorrect about it?
> > > > > >
> > > > > >To begin with, the last sentence states that the P2MP ID, *by itself*
> > > > > >"provides an identifier for the set of destinations of a given P2MP
> > > > > >TE Tunnel". However, since a given P2MP ID, *by itself*, may not
> > > > > >be unique, how could it unambiguously identify the set of 
> > > > > >destinations of such tunnel ?
> > > > >
> > > > > You are 100% correct, how about fixing it by saying:
> > > > > "The P2MP ID together with Tunnel ID, Extended Tunnel ID provide an
> > > > > identifier for the set of destinations of the P2MP TE Tunnel."
> > > >
> > > >Given that P2MP ID is unique within the scope of the root, why a
> > > >tuple <Extended Tunnel ID, P2MP ID> is not sufficient to identify
> > > >the set of destinations of a P2MP tunnel ? After all, you agreed
> > > >further down that such a tuple identifies a P2MP tunnel.
> > >
> > > Because this would preclude the use of tunnel ID to further partition
> > > the session space (as is done today for P2P-TE.)  The tuple I
> > > mentioned included all three.
> >
> >You, yourself agreed that "A combination of this address and P2MP
> >ID provides a globally unique identifier for the P2MP tunnel."
> 
> Well actually my point was: "... the uniqueness of the tuple <P2MP 
> ID, Tunnel ID, Extended Tunnel ID>. "
>
> >Since the set of destinations of a P2MP tunnel is just a part of
> >the tunnel, identifying the tunnel should be sufficient in order
> >to identify the set of destinations.
> 
> right, and all three fields are needed.

Could you please provide *technical* reason(s) that would explain why 
a combination of P2MP ID and Extended Tunnel ID is not sufficient ?

Yakov.

Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 05 Jul 2006 07:05:46 +0000
Date: Wed, 05 Jul 2006 15:03:49 +0800
From: Zheng Hewen <hwzheng@huawei.com>
Subject: I made a foolish mistake, I am sorry for the inconvenience about a wrong Email .
To: 'LE ROUX Jean-Louis RD-CORE-LAN' <jeanlouis.leroux@orange-ft.com>, ccamp@ops.ietf.org
Message-id: <000201c6a001$2a7749b0$3e05a40a@china.huawei.com>
MIME-version: 1.0
Content-type: TEXT/PLAIN
Content-transfer-encoding: 7BIT
Thread-index: AcabBaJ7VqHu4d2ySSSgGYpdBIIJAgDtGaKgAFGrsQA=

Hi,

    I made a foolish mistake, I am sorry for the inconvenience about a wrong Email .
    I sent one mail to wrong receivers just now, please ignore it.

Best regards,
Hewen

Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 05 Jul 2006 06:56:20 +0000
Date: Wed, 05 Jul 2006 14:52:25 +0800
From: Zheng Hewen <hwzheng@huawei.com>
Subject: Are you interested at forming requirments about MPLS P2MP membership discovery and distribution?
To: 'LE ROUX Jean-Louis RD-CORE-LAN' <jeanlouis.leroux@orange-ft.com>, ccamp@ops.ietf.org
Message-id: <000001c69fff$92d690d0$3e05a40a@china.huawei.com>
MIME-version: 1.0
Content-type: TEXT/PLAIN
Content-transfer-encoding: 7BIT
Thread-index: AcabBaJ7VqHu4d2ySSSgGYpdBIIJAgDtGaKgAFESgTA=

Hi,

    First, thanks for your many constructive comments first about MPLS P2MP membership discovery and distribution.
    Today I cannot find your draft and my draft about this topic in MPLS WG website. In fact, there were some drafts about
the topic, but they disappeared.
    It is desired to form requirements about MPLS P2MP membership discovery and distributions for MPLS WG.
    Are you interested at this point?

   I am looking forward to your cooperation. Any advice is appreciated.

Best regards,
Hewen

Envelope-to: ccamp-data@psg.com
Delivery-date: Mon, 03 Jul 2006 23:37:10 +0000
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0
To: Greg jones <greg.jones@itu.int>
Cc: Loa Andersson <loa@pi.se>, George Swallow <swallow@cisco.com>, Deborah Brungard <dbrungard@att.com>, Ross Callon <rcallon@juniper.net>, Bill Fenner <fenner@rearch.att.com>, Stewart Bryant <stbryant@cisco.com>, Danny McPherson <danny@arbor.net>, Mark Townsley <townsley@cisco.com>, IESG <iesg@ietf.org>, IAB <iab@ietf.org>, Steve Trowbridge <sjtrowbridge@lucent.com>, Malcolm Betts <betts01@nortel.com>, Ghani Abbas <ghani.abbas@marconi.com>, Houlin Zhao <houlin.zhao@itu.int>, Yoichi Maeda  <maeda@ansl.ntt.co.jp>, Jari Arkko <jari.arkko@piuha.net>, Scott Bradner <sob@harvard.edu>, Scott Brim <sbrim@cisco.com>, CCAMP mailing list <ccamp@ops.ietf.org>, MPLS mailing list <mpls@lists.ietf.org>, PWE3 mailing list <pwe3@ietf.org>, Adrian Farrel <adrian@olddog.co.uk>, Ross Callon <rcallon@juniper.net>, Stewart Bryant <stbryant@cisco.com>, Loa Andersson <loa@pi.se>
From: Adrian Farrel(IETF CCAMP WG) <adrian@olddog.co.uk>
Subject: New Liaison Statement, "Continued IETF / SG15 Cooperation on T-MPLS  and other MPLS Issues" 
reply-to: Adrian Farrel <adrian@olddog.co.uk>
Message-Id: <E1FxXwc-0006us-SF@ietf.org>
Date: Mon, 03 Jul 2006 19:35:10 -0400

Title: Continued IETF / SG15 Cooperation on T-MPLS and other MPLS Issues
Submission Date: 2006-07-03
URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=241 
Please reply by 2006-09-25

From: Adrian Farrel(IETF CCAMP WG) <adrian@olddog.co.uk>
To: ITU-T SG15(Greg jones <greg.jones@itu.int>)
Cc: Loa Andersson <loa@pi.se>
George Swallow <swallow@cisco.com>
Deborah Brungard <dbrungard@att.com>
Ross Callon <rcallon@juniper.net>
Bill Fenner <fenner@rearch.att.com>
Stewart Bryant <stbryant@cisco.com>
Danny McPherson < danny@arbor.net>
Mark Townsley <townsley@cisco.com>
IESG <iesg@ietf.org>
IAB <iab@ietf.org>
Steve Trowbridge <sjtrowbridge@lucent.com>
Malcolm Betts <betts01@nortel.com>
Ghani Abbas <ghani.abbas@marconi.com>
Houlin Zhao <houlin.zhao@itu.int>
Yoichi Maeda  <maeda@ansl.ntt.co.jp>
Jari Arkko <jari.arkko@piuha.net>
Scott Bradner <sob@harvard.edu>
Scott Brim <sbrim@cisco.com>
CCAMP mailing list <ccamp@ops.ietf.org>
MPLS mailing list <mpls@lists.ietf.org>
PWE3 mailing list <pwe3@ietf.org>
Reponse Contact: Adrian Farrel <adrian@olddog.co.uk>
Ross Callon <rcallon@juniper.net>
Technical Contact: Stewart Bryant <stbryant@cisco.com>
Loa Andersson <loa@pi.se>
Purpose: For action 
Body: From: Adrian Farrel (IETF Liaison to SG15, CCAMP WG Chair, adrian@olddog.co.uk)
      Loa Andersson (IETF MPLS WG Chair; loa@pi.se)
      George Swallow (IETF MPLS WG Chair; swallow@cisco.com)
      Deborah Brungard  (IETF CCAMP WG Chair, dbrungard@att.com)
      Ross Callon (IETF Routing Area Director; rcallon@juniper.net)
      Bill Fenner (IETF Routing Area Director; fenner@rearch.att.com)
      Stewart Bryant (IETF PWE3 WG Chair; stbryant@cisco.com)
      Danny McPherson  (IETF PWE3 WG Chair, danny@arbor.net)
      Mark Townsley (IETF Internet Area Director, townsley@cisco.com)

To:   ITU-T Study Group 15; Greg Jones  (greg.jones@itu.int)

CC:   IESG  (iesg@ietf.org)
      IAB  (iab@ietf.org)
      Steve Trowbridge  (sjtrowbridge@lucent.com)
      Malcolm Betts  (betts01@nortel.com)
      Ghani Abbas  (ghani.abbas@marconi.com)
      Houlin Zhao  (houlin.zhao@itu.int)
      Yoichi Maeda   (maeda@ansl.ntt.co.jp)
      Jari Arkko (jari.arkko@piuha.net)
      Scott Bradner  (sob@harvard.edu)
      Scott Brim  (sbrim@cisco.com)
      CCAMP mailing list (ccamp@ops.ietf.org)
      MPLS mailing list (mpls@lists.ietf.org)
      PWE3 mailing list (pwe3@ietf.org)

Subject: Continued IETF / SG15 Cooperation on T-MPLS and other MPLS Issues

We would like to thank you for the invitation to allow IETF experts to attend the recent SG15 Rapporteurâs meeting in Ottawa. We were particularly interested in contributing to the SG15, Question 12 meeting considering T-MPLS specifications. We note that multiple IETF experts attended, including Ross Callon (Routing AD), Loa Andersson (MPLS WG Chair), and Stewart Bryant (PWE3 WG Chair). We also note that this meeting resulted in a very cooperative and productive discussion, which resulted in significantly improved mutual understanding of issues as well as substantial detailed discussion. This included detailed technical discussion as well as detailed text editing. 

During the Rapporteurâs meeting, extensive technical updates were proposed and agreed to for G.8110.1 (Architecture of Transport MPLS (T-MPLS) Layer Network ). These discussions identified issues, errors, and omissions in G.8110.1, and also came up with a significant amount of new text which allows very substantial improvements to this document. These discussions also identified areas for further consideration and where additional improvements, clarifications and/or discussions are warranted, such as the need for specification of the requirements for T-MPLS, as well as for specification of the scope of applicability.

We would like to strongly recommend that G.8110.1 not be published in the form that was consented prior to the Ottawa meeting, and that the substantial improvements that were agreed in the Ottawa meeting be incorporated in the text prior to publication. Furthermore, due to the extensive nature of these important improvements, and due to the existence of some further issues that warrant additional consideration, we also strongly recommend that time be allowed for review of the updated document by SG15 and IETF experts, including an additional round of liaison of this document to the IETF, and particularly to the MPLS, CCAMP, and PWE3 working groups for further review and comment. 

We are aware that a further Rapporteur's meeting is planned for Sophia Antipolis in the week commencing 18th September 2006, and we hope that it will be possible to facilitate attendance by non-ITU IETF experts in order to continue the excellent cooperative progress made in Ottawa. We request that any updates made to, or proposed for, the text of G.8110.1 be liaised to the IETF after the September meeting to allow us to make comments in advance of the SG15 Plenary in October/November this year.

We would like to thank you and SG15 participants for the very positive interaction at the Ottawa Rapporteurâs meeting, and we look forward to continued positive interaction between ITU and IETF experts. 

Sincerely,

Adrian Farrel
Loa Andersson
George Swallow
Deborah Brungard
Ross Callon
Bill Fenner
Steward Bryant
Danny McPherson
Mark Townsley
Attachment(s):
No document has been attached

Envelope-to: ccamp-data@psg.com
Delivery-date: Mon, 03 Jul 2006 16:14:29 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: I-D ACTION:draft-ietf-ccamp-gmpls-mln-eval-01.txt 
Date: Mon, 3 Jul 2006 18:12:36 +0200
Message-ID: <D109C8C97C15294495117745780657AE05491332@ftrdmel1.rd.francetelecom.fr>
Thread-Topic: I-D ACTION:draft-ietf-ccamp-gmpls-mln-eval-01.txt 
Thread-Index: AcabBaJ7VqHu4d2ySSSgGYpdBIIJAgDtGaKg
From: "LE ROUX Jean-Louis RD-CORE-LAN" <jeanlouis.leroux@orange-ft.com>
To: <ccamp@ops.ietf.org>

Hi all,

Here are the major changes in this revision:
- Introduction aligned with the requirement doc.
- The section 4.1.1.1 (control of VNT) has been updated. It now clearly =
distinguishes elementary functional components (collection of traffic =
demand, VNT policing/scheduling, VNT computation...) and the =
relationship between these components.
- The analysis of the virtual TE-link function (4.1.1.2) has been =
detailed. Two approaches are discussed and compared: The soft FA =
approach and the remote association approach.

We are waiting for your comments on this new version.

Regards,

JL

> -----Message d'origine-----
> De : owner-ccamp@ops.ietf.org=20
> [mailto:owner-ccamp@ops.ietf.org] De la part de=20
> Internet-Drafts@ietf.org
> Envoy=E9 : jeudi 29 juin 2006 00:50
> =C0 : i-d-announce@ietf.org
> Cc : ccamp@ops.ietf.org
> Objet : I-D ACTION:draft-ietf-ccamp-gmpls-mln-eval-01.txt=20
>=20
> A New Internet-Draft is available from the on-line=20
> Internet-Drafts directories.
> This draft is a work item of the Common Control and=20
> Measurement Plane Working Group of the IETF.
>=20
> 	Title		: Evaluation of existing GMPLS=20
> Protocols against Multi Layer and Multi Region Networks (MLN/MRN)
> 	Author(s)	: J. Le Roux, et al.
> 	Filename	: draft-ietf-ccamp-gmpls-mln-eval-01.txt
> 	Pages		: 16
> 	Date		: 2006-6-28
> =09
> This document provides an evaluation of Generalized=20
> Multi-Protocol Label Switching (GMPLS) protocols and=20
> mechanisms against the requirements for Multi-Layer Networks=20
> (MLN) and Multi-Region Networks (MRN). In addition, this=20
> document identifies areas where additional protocol=20
> extensions or procedures are needed to satisfy these=20
> requirements, and provides guidelines for potential extensions.
>=20
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-mln
> -eval-01.txt
>=20
> To remove yourself from the I-D Announcement list, send a=20
> message to i-d-announce-request@ietf.org with the word=20
> unsubscribe in the body of the message. =20
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
>=20
>=20
> Internet-Drafts are also available by anonymous FTP. Login=20
> with the username "anonymous" and a password of your e-mail=20
> address. After logging in, type "cd internet-drafts" and then
> 	"get draft-ietf-ccamp-gmpls-mln-eval-01.txt".
>=20
> A list of Internet-Drafts directories can be found in=20
> http://www.ietf.org/shadow.html or=20
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>=20
>=20
> Internet-Drafts can also be obtained by e-mail.
>=20
> Send a message to:
> 	mailserv@ietf.org.
> In the body type:
> 	"FILE /internet-drafts/draft-ietf-ccamp-gmpls-mln-eval-01.txt".
> =09
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant=20
> mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 	=09
> 	=09
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>=20

Envelope-to: ccamp-data@psg.com
Delivery-date: Sun, 02 Jul 2006 22:20:35 +0000
Message-ID: <064101c69e25$8d522fb0$9a6d5ec2@your029b8cecfe>
Reply-To: "Adrian Farrel" <adrian@olddog.co.uk>
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: <ccamp@ops.ietf.org>
Subject: Time for your slides, please
Date: Sun, 2 Jul 2006 23:19:01 +0100
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Hi,

CCAMP is at 9am on Monday morning, so Deborah and I could really use your 
slides *before* we travel.

Can you please check the agenda to see if you are leading a discussion, and 
send us your slides during the week.

Thanks,
Adrian 

Envelope-to: ccamp-data@psg.com
Delivery-date: Sun, 02 Jul 2006 13:51:33 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: draft-fedyk-gmpls-ethernet-pbt-00.txt
Date: Sun, 2 Jul 2006 16:47:31 +0200
Message-ID: <347D74C07C4F924091F863CBC284F41202BABC8F@dove.seabridge.co.il>
Thread-Topic: draft-fedyk-gmpls-ethernet-pbt-00.txt
Thread-Index: AcaZLe5yO/C0CMCSQuC/mY0ecCDxpAACFi0QAMp1WpAAYDN3sA==
From: "Nurit Sprecher" <nurit.sprecher@SeabridgeNetworks.com>
To: "Lucy Yong" <lucyyong@huawei.com>
Cc: "Don Fedyk" <dwfedyk@nortel.com>, "Igor Bryskin" <ibryskin@movaz.com>, <ccamp@ops.ietf.org>, <gels@rtg.ietf.org>, "Nurit Sprecher" <nurit.sprecher@SeabridgeNetworks.com>

=20
Hi Lucy Yong,
PBT is almost the data plane of Ethernet, with some modifications, as
follows:
1. Flooding is disabled for the range of PBT VIDs.=20
2. Broadcast and multicast are disabled for the range of PBT VIDs.=20
3. Unknown frames are discarded.=20
4. PBT VIDs must be related to an STP instance and the STP state of the
port must always be enabled to allow data plane forwarding of frames.
Please note that this must be done, because with the current
specifications any VID must relate to an STP instance.
Best regards,
Nurit

-----Original Message-----
From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On
Behalf Of Lucy Yong
Sent: Friday, June 30, 2006 18:31
To: 'Don Fedyk'; 'Igor Bryskin'; ccamp@ops.ietf.org; gels@rtg.ietf.org
Subject: RE: draft-fedyk-gmpls-ethernet-pbt-00.txt

Don,

Thank you for writing this draft. It is very informative.

PBT is simply the data plane of Ethernet (802.1Q and 8021.ah) without a
Spanning tree control plane.  As a result, this data plane does not have
knowledge of how to forwarding the traffic anymore. The purpose of the
draft is to suggest building a new control plane which can build
forwarding path for all kinds of service requests as mentioned in
document.

Building a new control plane for Ethernet network sounds great!! The
draft mentions in several places a desire of some level of
administrative management in building forwarding path. I would like to
ask a basic
question:

The network with this new control plane should have the intelligence of
routing and traffic engineering to allow the network building forwarding
path automatically; or The network should not have that intelligence,
forwarding path should be selected by the network management system,
network only needs signaling capability to build forwarding path.

Which model do you pursue for PBT, why?

Best Regards,
Lucy Yong
=20

-----Original Message-----
From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On
Behalf Of Don Fedyk
Sent: Monday, June 26, 2006 10:50 AM
To: Igor Bryskin; ccamp@ops.ietf.org; gels@rtg.ietf.org
Subject: RE: draft-fedyk-gmpls-ethernet-pbt-00.txt

=20

> -----Original Message-----
> From: owner-ccamp@ops.ietf.org
> [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Igor Bryskin
>
> Thanks Don,
>=20
> See in-line.
>=20
> Igor
>=20
> ----- Original Message -----
> From: "Don Fedyk" <dwfedyk@nortel.com>
>=20
<snip>
>=20
> So you have two questions: Do we need Auto-discovery; and if so should

> it be IGP based or BGP based.
> In the simple mode we have specified so far MAC Learning on the edge=20
> is all we need.  So no auto discovery.
>=20
>=20
> IB>> Well, MAC Learning tells edge switch which port an
> Ethernet packet
> destined to a particular D-MAC should be sent out. However, it does=20
> not tell the TE name of the edge switch (on the opposite side of the=20
> network) supporting this D-MAC. So how the ingress switch can tell=20
> (without auto-discovery or configuration) which of (new or existing)=20
> Eth-LSPs could be used for the packet forwarding?
>=20
> Thanks,
> Igor
>=20
To be clear on this the association is made statically up front in the
current document. No new Eth-LSPs are set up due to the arrival of an
new D-MAC. There is a static binding of a Customer Port to a Ethernet
LSP. There is a static binding of the Eth-LSP to a destination switch.
At the ingress provider node and a destination provider node typically a
PW identifier or a PPB I-SID is used to mux/demux the packet on the
Eth-LSP. You could also have a dedicated Eth-LSP with no multiplexer.

Regards,
Don=20

(text below is consistent with this if we do what you are alluding to in
the future)

> However if we ever get to on demand
> signaling on the connections from the customer space then an auto=20
> discovery function would be desirable.
>=20
> As to IGP or BGP, very similar to the L1VPN case. We have discussed=20
> keeping the Optical code base and the Ethernet code base development=20
> based on the same architecture.  I don't see much difference here we=20
> could develop either it depends on customer demand for such a feature.
> Currently out of scope for us.
>=20
> Regards,
> Don
>=20
> >
> > It would be good if your draft would provide some of your views on=20
> > such mechanism and, more generally, on which routing protocols=20
> > should be supported by GMPLS controllers managing Ethernet switches.

> > Obviously, IGP-TE is going to be required to enable path=20
> > computation. But how about BGP?
> >
> > Thanks,
> > Igor
> >
> <snip>
>=20
>=20
>=20
>=20

Envelope-to: ccamp-data@psg.com
Delivery-date: Sat, 01 Jul 2006 22:39:00 +0000
To: "Don Fedyk" <dwfedyk@nortel.com>
Cc: ccamp@ops.ietf.org, gels@rtg.ietf.org, gels-bounces@rtg.ietf.org, Igor Bryskin <ibryskin@movaz.com>, Lucy Yong <lucyyong@huawei.com>
Subject: RE: draft-fedyk-gmpls-ethernet-pbt-00.txt
MIME-Version: 1.0
Message-ID: <OF6B72C218.A0D810BE-ONC125719E.007C0F05-C125719E.007C36AB@netfr.alcatel.fr>
From: Dimitri.Papadimitriou@alcatel.be
Date: Sun, 2 Jul 2006 00:36:44 +0200
Content-Type: text/plain; charset="US-ASCII"

hi don

in the below sentence, "latter" was referring to VPN not to the second 
case

on the reference, i was pointing to the GELS framework (that needs some 
refresh anyway)

hope this clarifies
- dimitri.

"Don Fedyk" <dwfedyk@nortel.com>
Sent by: gels-bounces@rtg.ietf.org
01/07/2006 05:54

        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     ccamp@ops.ietf.org, gels@rtg.ietf.org, Lucy Yong 
<lucyyong@huawei.com>, gels-bounces@rtg.ietf.org, Igor Bryskin 
<ibryskin@movaz.com>
        Subject:        RE: draft-fedyk-gmpls-ethernet-pbt-00.txt

Hi Dimitri

It escapes me why the second case cannot be related to a VPN service as
viewed by the provider.  I'm not trying to link the current draft to a
VPN BTW.  There are no references to anything but the edge to edge model
in the draft.

Regards,
Don 

> -----Original Message-----
> From: Dimitri.Papadimitriou@alcatel.be 
> [mailto:Dimitri.Papadimitriou@alcatel.be] 
> hi don - i would say that the GELS models are of two categories
> 
> o) edge to edge (SPC or SPVC model)
> 
> o) end-to-end (SC or SVC model) with two sub flavors one 
> where the end-node is not Ethernet device and one where the 
> end-node is an Ethernet device
> 
> i would not make any direct relationship between these models 
> and any VPN model simply because the latter refers to the 
> service while GELS is specifically linked to the "network 
> connectivity"
> 
> much thanks,
> - dimitri.
> 
> 
<snip>

_______________________________________________
gels mailing list
gels@rtg.ietf.org
https://rtg.ietf.org/mailman/listinfo/gels

Envelope-to: ccamp-data@psg.com
Delivery-date: Sat, 01 Jul 2006 03:55:19 +0000
Content-class: urn:content-classes:message
Subject: RE: draft-fedyk-gmpls-ethernet-pbt-00.txt
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 30 Jun 2006 23:54:14 -0400
Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA4093E23C3@zrtphxm2.corp.nortel.com>
Thread-Topic: draft-fedyk-gmpls-ethernet-pbt-00.txt
Thread-Index: Acacka7UWYn2iUcWQtCqHBEhOv3sBAAL7FGg
From: "Don Fedyk" <dwfedyk@nortel.com>
To: <Dimitri.Papadimitriou@alcatel.be>
Cc: <ccamp@ops.ietf.org>, <gels@rtg.ietf.org>, <gels-bounces@rtg.ietf.org>, "Igor Bryskin" <ibryskin@movaz.com>, "Lucy Yong" <lucyyong@huawei.com>

Hi Dimitri

It escapes me why the second case cannot be related to a VPN service as
viewed by the provider.  I'm not trying to link the current draft to a
VPN BTW.  There are no references to anything but the edge to edge model
in the draft.

Regards,
Don=20

=20

> -----Original Message-----
> From: Dimitri.Papadimitriou@alcatel.be=20
> [mailto:Dimitri.Papadimitriou@alcatel.be]=20
> hi don - i would say that the GELS models are of two categories
>=20
> o) edge to edge (SPC or SPVC model)
>=20
> o) end-to-end (SC or SVC model) with two sub flavors one=20
> where the end-node is not Ethernet device and one where the=20
> end-node is an Ethernet device
>=20
> i would not make any direct relationship between these models=20
> and any VPN model simply because the latter refers to the=20
> service while GELS is specifically linked to the "network=20
> connectivity"
>=20
> much thanks,
> - dimitri.
> =20
>=20
<snip>

Envelope-to: ccamp-data@psg.com
Delivery-date: Sat, 01 Jul 2006 03:49:49 +0000
Content-class: urn:content-classes:message
Subject: RE: draft-fedyk-gmpls-ethernet-pbt-00.txt
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 30 Jun 2006 23:47:53 -0400
Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA4093E23C2@zrtphxm2.corp.nortel.com>
Thread-Topic: draft-fedyk-gmpls-ethernet-pbt-00.txt
Thread-Index: AcackF2k2hjTleTMTgiYXmw5elL+OgAMGXIQ
From: "Don Fedyk" <dwfedyk@nortel.com>
To: <Dimitri.Papadimitriou@alcatel.be>
Cc: <ccamp@ops.ietf.org>, <gels@rtg.ietf.org>, "Igor Bryskin" <ibryskin@movaz.com>, "Lucy Yong" <lucyyong@huawei.com>, <owner-ccamp@ops.ietf.org>

Hi Dimitri=20

Yes I used control loosely I agree with your more specific definitions.=20

Don=20
> -----Original Message-----
> From: Dimitri.Papadimitriou@alcatel.be=20
> [mailto:Dimitri.Papadimitriou@alcatel.be]=20
> hi don
>=20
> when you write
>=20
> > BTW centralized path control may need a PCE system not necessarily a
> management system.=20
>=20
> Path Control and Path Computation - are two different functions -=20
>=20
> i know that the acronym PCx could be misleading but hope not=20
> until that=20
> point
>=20
> thanks;
> - dimitri.
<snip>