Subject: OSPF ASON Routing Solution

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 12 Jul 2006 20:10:05 +0100

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.

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 19 Jul 2006 14:27:17 +0100

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" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, July 12, 2006 8:10 PM
Subject: OSPF ASON Routing Solution

> 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.
>
> NB, this is a charter item and we have an obligation to work on this for 
> the ITU-T.
>
> Thanks,
> Adrian
>

---

From: [email-masked]
Date: Wed, 19 Jul 2006 19:53:53 +0200

Adrian,

I am all in favour of making this a WG I-D,

@+ mannu

                      "Adrian Farrel"                                                                                                
                      <[email-masked]         To:      <[email-masked]>                                                         
                      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"                                                                                                        

Adrian

---

From: Richard Rabbat <[email-masked]>
Date: Wed, 19 Jul 2006 10:58:28 -0700

bien au contraire. fully support this becoming a WG document.
Richard.

Adrian Farrel wrote:
> ----- Original Message ----- From: "Adrian Farrel" <[email-masked]>
> To: <[email-masked]>
>> draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt the solutions 
>> draft for OSPF in ASON routing.
>>
>> 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.
>>
>>
>>
>>
>>
>
>
>

---

From: "Igor Bryskin" <[email-masked]>
Date: Wed, 19 Jul 2006 15:17:36 -0400

I am interested in this work and support becoming it a WG document.

Igor

---

From: "Ong, Lyndon" <[email-masked]>
Date: Wed, 19 Jul 2006 14:50:39 -0400

Support this being WG as well (no objections).

Cheers,
Lyndon 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Richard Rabbat
Sent: Wednesday, July 19, 2006 10:58 AM
To: Adrian Farrel
Cc: [email-masked]
Subject: Re: OSPF ASON Routing Solution

---

From: "Rajiv Papneja" <[email-masked]>
Date: Wed, 19 Jul 2006 15:59:47 -0400

Adrian,

I support this draft becoming a WG document.

/R

> From: Adrian Farrel [mailto:[email-masked]]
> Sent: Wednesday, July 12, 2006 3:10 PM
> To: [email-masked]
toes,
> the

---

From: Gert Grammel <[email-masked]>
Date: Thu, 20 Jul 2006 10:41:50 +0200

Adrian,

I am supporting this draft becoming a WG document.

Gert

---

From: "Igor Bryskin" <[email-masked]>
Date: Thu, 20 Jul 2006 18:05:51 -0400

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" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>
Cc: <[email-masked]>
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:

---

From: [email-masked]
Date: Fri, 21 Jul 2006 02:05:45 +0200

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" <[email-masked]>
Sent by: [email-masked]
21/07/2006 00:05
 
        To:     "Acee Lindem" <[email-masked]>, "Adrian Farrel" 
<[email-masked]>
        cc:     <[email-masked]>
        Subject:        Re: OSPF ASON Routing Solution

Hi Acee,

but, otherwise, have 0 in common. In particular, I believe ASON OSPF 
should

Igor

---

From: Acee Lindem <[email-masked]>
Date: Thu, 20 Jul 2006 21:44:12 -0400

Hi Igor,

> 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

---

From: "Igor Bryskin" <[email-masked]>
Date: Fri, 21 Jul 2006 10:09:39 -0400

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" <[email-masked]>
To: "Igor Bryskin" <[email-masked]>
Cc: "Adrian Farrel" <[email-masked]>; <[email-masked]>
Sent: Thursday, July 20, 2006 9:44 PM
Subject: Re: OSPF ASON Routing Solution

should

---

From: "Igor Bryskin" <[email-masked]>
Date: Fri, 21 Jul 2006 10:04:56 -0400

Dimitri,

Please, see in line.

Igor

----- Original Message ----- 
From: <[email-masked]>
To: "Igor Bryskin" <[email-masked]>
Cc: "Acee Lindem" <[email-masked]>; "Adrian Farrel" <[email-masked]>;
<[email-masked]>; <[email-masked]>
Sent: Thursday, July 20, 2006 8:05 PM
Subject: Re: OSPF ASON Routing Solution

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

> 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

---

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

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" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, July 19, 2006 2:27 PM
Subject: Re: OSPF ASON Routing Solution

>> draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt the solutions draft 
>> for OSPF in ASON routing.
>>

---

From: "Igor Bryskin" <[email-masked]>
Date: Fri, 28 Jul 2006 10:36:38 -0400

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" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>; <[email-masked]>
Sent: Wednesday, July 26, 2006 9:52 AM
Subject: Re: OSPF ASON Routing Solution

> Dimitri, please re-submit as
draft-ietf-ccamp-gmpls-ason-routing-ospf-00.txt
> >> So a this is a quick poll to see if anyone objects to this becoming a
WG
> >> NB, this is a charter item and we have an obligation to work on this
for

---

From: "Igor Bryskin" <[email-masked]>
Date: Fri, 28 Jul 2006 16:09:03 -0400

Dimitri,

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

Igor

----- Original Message ----- 
From: <[email-masked]>
To: "Igor Bryskin" <[email-masked]>
Cc: "Adrian Farrel" <[email-masked]>; <[email-masked]>
Sent: Friday, July 28, 2006 3:34 PM
Subject: Re: OSPF ASON Routing Solution

> hi igor - see in-line
> 28/07/2006 16:36
>         To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
>         cc:     <[email-masked]>, "Adrian Farrel"
> <[email-masked]>
> [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.
>
> [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

---

From: [email-masked]
Date: Fri, 28 Jul 2006 21:34:19 +0200

hi igor - see in-line

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" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>; <[email-masked]>
Sent: Wednesday, July 26, 2006 9:52 AM
Subject: Re: OSPF ASON Routing Solution

> >> draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt the solutions 
draft
WG
for
WG

---

From: Snigdho Bardalai <[email-masked]>
Date: Mon, 31 Jul 2006 10:57:16 -0500

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

Delivery-date: Mon, 31 Jul 2006 15:59:38 +0000
Date: Mon, 31 Jul 2006 10:57:16 -0500
From: Snigdho Bardalai <[email-masked]>
Organization: Fujitsu Network Communications
To: [email-masked]
CC: Adrian Farrel <[email-masked]>, [email-masked]
Subject: 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

Delivery-date: Sun, 30 Jul 2006 12:56:57 +0000
From: "Jim Jones" <[email-masked]>
To: "'Brungard, Deborah A, ALABS'" <[email-masked]>
Cc: <[email-masked]>, "'Adrian Farrel'" <[email-masked]>, "'Ross Callon'" <[email-masked]>, "'Fenner, William C \(Bill\), ALABS'" <[email-masked]>
Subject: RE: Response to OIF on OSPF ENNI
Date: Sun, 30 Jul 2006 07:54:38 -0500

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: [email-masked] [mailto:[email-masked]] On Behalf
Of Brungard, Deborah A, ALABS
Sent: Friday, July 28, 2006 4:09 PM
To: Jim Jones
Cc: [email-masked]; 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><SPAN class=3D309385212-30072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Dear Deborah and Adrian,</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D309385212-30072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D309385212-30072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>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.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D309385212-30072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D309385212-30072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Best Regards,</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D309385212-30072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Jim Jones</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D309385212-30072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>OIF Technical Committee =
Chair</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> [email-masked]=20
[mailto:[email-masked]] <B>On Behalf Of </B>Brungard, Deborah =
A,=20
ALABS<BR><B>Sent:</B> Friday, July 28, 2006 4:09 PM<BR><B>To:</B> Jim=20
Jones<BR><B>Cc:</B> [email-masked]; Adrian Farrel; Ross Callon; =
Fenner,=20
William C (Bill), ALABS<BR><B>Subject:</B> Response to OIF on OSPF=20
ENNI<BR></FONT><BR></DIV>
<DIV></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D694204621-27072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT face=3D"Times =
New Roman"=20
color=3D#000000 size=3D3>Dear Jim,</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 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.</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>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, =
</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" 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.</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>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 color=3D#000000><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></FONT></SPAN></SPAN><FONT face=3D"Times New Roman" =
color=3D#000000=20
size=3D3>What is the intent of this document? Will it be published as an =

Implementation Agreement (IA)?<BR>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></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 color=3D#000000><FONT =
size=3D3>2.</FONT><SPAN=20
style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></FONT></SPAN></SPAN></I><FONT size=3D3><FONT color=3D#000000>The =
list of=20
changes from the previous version (listed under the Table of Contents) =
includes=20
&#8220;<I><SPAN style=3D"mso-bidi-font-weight: bold">removed =
&#8220;intra-carrier&#8221;=20
limitation</SPAN></I><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.<I><o:p></o:p></I></SPAN></FONT></FONT></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 color=3D#000000><FONT =
size=3D3>3.</FONT><SPAN=20
style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></FONT></SPAN></SPAN></I><SPAN=20
style=3D"mso-bidi-font-weight: bold; mso-bidi-font-style: italic"><FONT=20
size=3D3><FONT color=3D#000000>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.<I><o:p></o:p></I></FONT></FONT></SPAN></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"><SPAN=20
style=3D"mso-fareast-font-family: 'Times New Roman'"><SPAN=20
style=3D"mso-list: Ignore"><FONT color=3D#000000><FONT =
size=3D3>4.</FONT><SPAN=20
style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></FONT></SPAN></SPAN><FONT color=3D#000000 size=3D3>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; </SPAN>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></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"><SPAN=20
style=3D"mso-fareast-font-family: 'Times New Roman'"><SPAN=20
style=3D"mso-list: Ignore"><FONT color=3D#000000><FONT =
size=3D3>5.</FONT><SPAN=20
style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></FONT></SPAN></SPAN><FONT color=3D#000000 size=3D3>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=20
co-chairs</FONT></P></FONT></SPAN></DIV></BODY></HTML>

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

Delivery-date: Fri, 28 Jul 2006 21:09:32 +0000
Content-class: urn:content-classes:message
Subject: Response to OIF on OSPF ENNI
Date: Fri, 28 Jul 2006 16:08:34 -0500
From: "Brungard, Deborah A, ALABS" <[email-masked]>
To: "Jim Jones" <[email-masked]>
Cc: <[email-masked]>, "Adrian Farrel" <[email-masked]>, "Ross Callon" <[email-masked]>, "Fenner, William C \(Bill\), ALABS" <[email-masked]>

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><SPAN class=3D694204621-27072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT face=3D"Times =
New Roman"=20
color=3D#000000 size=3D3>Dear Jim,</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 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.</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>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, =
</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" 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.</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>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 color=3D#000000><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></FONT></SPAN></SPAN><FONT face=3D"Times New Roman" =
color=3D#000000=20
size=3D3>What is the intent of this document? Will it be published as an =

Implementation Agreement (IA)?<BR>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></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 color=3D#000000><FONT =
size=3D3>2.</FONT><SPAN=20
style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></FONT></SPAN></SPAN></I><FONT size=3D3><FONT color=3D#000000>The =
list of=20
changes from the previous version (listed under the Table of Contents) =
includes=20
&#8220;<I><SPAN style=3D"mso-bidi-font-weight: bold">removed =
&#8220;intra-carrier&#8221;=20
limitation</SPAN></I><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.<I><o:p></o:p></I></SPAN></FONT></FONT></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 color=3D#000000><FONT =
size=3D3>3.</FONT><SPAN=20
style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></FONT></SPAN></SPAN></I><SPAN=20
style=3D"mso-bidi-font-weight: bold; mso-bidi-font-style: italic"><FONT=20
size=3D3><FONT color=3D#000000>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.<I><o:p></o:p></I></FONT></FONT></SPAN></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"><SPAN=20
style=3D"mso-fareast-font-family: 'Times New Roman'"><SPAN=20
style=3D"mso-list: Ignore"><FONT color=3D#000000><FONT =
size=3D3>4.</FONT><SPAN=20
style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></FONT></SPAN></SPAN><FONT color=3D#000000 size=3D3>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; </SPAN>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></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"><SPAN=20
style=3D"mso-fareast-font-family: 'Times New Roman'"><SPAN=20
style=3D"mso-list: Ignore"><FONT color=3D#000000><FONT =
size=3D3>5.</FONT><SPAN=20
style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></FONT></SPAN></SPAN><FONT color=3D#000000 size=3D3>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=20
co-chairs</FONT></P></FONT></SPAN></DIV></BODY></HTML>

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

Delivery-date: Fri, 28 Jul 2006 20:09:32 +0000
From: "Igor Bryskin" <[email-masked]>
To: <[email-masked]>
Cc: "Adrian Farrel" <[email-masked]>, <[email-masked]>
Subject: Re: OSPF ASON Routing Solution
Date: Fri, 28 Jul 2006 16:09:03 -0400

Dimitri,

Igor

----- Original Message ----- 
From: <[email-masked]>
To: "Igor Bryskin" <[email-masked]>
Cc: "Adrian Farrel" <[email-masked]>; <[email-masked]>
Sent: Friday, July 28, 2006 3:34 PM
Subject: Re: OSPF ASON Routing Solution

Igor

> > >> PS Note that a solution does not have to be 100% perfect to become a

Delivery-date: Fri, 28 Jul 2006 19:50:07 +0000
Content-class: urn:content-classes:message
Subject: RE: Proposed response to OIF on OSPF ENNI
Date: Fri, 28 Jul 2006 14:49:25 -0500
From: "Brungard, Deborah A, ALABS" <[email-masked]>
To: "Ong, Lyndon" <[email-masked]>, <[email-masked]>
Cc: "Adrian Farrel" <[email-masked]>

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:[email-masked]]=20
Sent: Friday, July 28, 2006 12:28 PM
To: Brungard, Deborah A, ALABS; [email-masked]
Cc: Adrian Farrel
Subject: RE: Proposed response to OIF on OSPF ENNI

Hi Deborah, Adrian,
=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: [email-masked] [mailto:[email-masked]] On
Behalf Of Brungard, Deborah A, ALABS
Sent: Thursday, July 27, 2006 2:59 PM
To: [email-masked]
Cc: Adrian Farrel
Subject: RE: Proposed response to OIF on OSPF ENNI

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

Hi,
=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><SPAN class=3D986270119-28072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>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.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D986270119-28072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D986270119-28072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>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.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D986270119-28072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D986270119-28072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Thanks Lyndon for your mails - Good=20
weekend-</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D986270119-28072006><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:[email-masked]]=20
<BR><B>Sent:</B> Friday, July 28, 2006 12:28 PM<BR><B>To:</B> Brungard, =
Deborah=20
A, ALABS; [email-masked]<BR><B>Cc:</B> Adrian =
Farrel<BR><B>Subject:</B> RE:=20
Proposed response to OIF on OSPF ENNI<BR></FONT><BR></DIV>
<DIV></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D427151216-28072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Hi Deborah, Adrian,</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D427151216-28072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D427151216-28072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>I am still not happy with the tone of the =
liaison and some=20
nits (still don't see why an</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D427151216-28072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>OIF document cannot reflect OIF work over the =
last several=20
years, for example),</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D427151216-28072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>but it is probably best to get a liaison out =
now since OIF=20
meets next week.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D427151216-28072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D427151216-28072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Just for the record, I think many if not all of =
the=20
specific text points can be addressed, but</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D427151216-28072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>disagree with a number of the broader =
conclusions,=20
particularly on the relative</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D427151216-28072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>roles of OIF and IETF.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D427151216-28072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D427151216-28072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Cheers,</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D427151216-28072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D427151216-28072006><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> [email-masked]=20
[mailto:[email-masked]] <B>On Behalf Of </B>Brungard, Deborah =
A,=20
ALABS<BR><B>Sent:</B> Thursday, July 27, 2006 2:59 PM<BR><B>To:</B>=20
[email-masked]<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 dir=3Dltr align=3Dleft><SPAN class=3D694204621-27072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Thanks all for the discussion. I've updated to=20
include:</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D694204621-27072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>- our discussion on "alignment" --&gt; amended =
to say "does=20
not appear to be aligned"</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D694204621-27072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>- 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</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D694204621-27072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>- 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)</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D694204621-27072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D694204621-27072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>We'll target COB (EST) tomorrow for=20
finalizing-</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D694204621-27072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Deborah</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D694204621-27072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D694204621-27072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>=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</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D694204621-27072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D694204621-27072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT face=3D"Times =
New Roman"=20
color=3D#000000 size=3D3>Dear Jim,</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 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.</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>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, =
</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" 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.</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>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 color=3D#000000><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></FONT></SPAN></SPAN><FONT face=3D"Times New Roman" =
color=3D#000000=20
size=3D3>What is the intent of this document? Will it be published as an =

Implementation Agreement (IA)?<BR>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></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 color=3D#000000><FONT =
size=3D3>2.</FONT><SPAN=20
style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></FONT></SPAN></SPAN></I><FONT size=3D3><FONT color=3D#000000>The =
list of=20
changes from the previous version (listed under the Table of Contents) =
includes=20
&#8220;<I><SPAN style=3D"mso-bidi-font-weight: bold">removed =
&#8220;intra-carrier&#8221;=20
limitation</SPAN></I><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.<I><o:p></o:p></I></SPAN></FONT></FONT></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 color=3D#000000><FONT =
size=3D3>3.</FONT><SPAN=20
style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></FONT></SPAN></SPAN></I><SPAN=20
style=3D"mso-bidi-font-weight: bold; mso-bidi-font-style: italic"><FONT=20
size=3D3><FONT color=3D#000000>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.<I><o:p></o:p></I></FONT></FONT></SPAN></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"><SPAN=20
style=3D"mso-fareast-font-family: 'Times New Roman'"><SPAN=20
style=3D"mso-list: Ignore"><FONT color=3D#000000><FONT =
size=3D3>4.</FONT><SPAN=20
style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></FONT></SPAN></SPAN><FONT color=3D#000000 size=3D3>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; </SPAN>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></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"><SPAN=20
style=3D"mso-fareast-font-family: 'Times New Roman'"><SPAN=20
style=3D"mso-list: Ignore"><FONT color=3D#000000><FONT =
size=3D3>5.</FONT><SPAN=20
style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></FONT></SPAN></SPAN><FONT color=3D#000000 size=3D3>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> [email-masked]=20
[mailto:[email-masked]] <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
[email-masked]<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></I></FONT></FONT><SPAN=20
style=3D"mso-bidi-font-weight: bold; mso-bidi-font-style: italic"><FONT=20
size=3D3><FONT face=3D"Times New Roman">&#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><o:p></o:p></I></FONT></FONT></SPAN></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"><SPAN=20
style=3D"mso-fareast-font-family: 'Times New Roman'"><SPAN=20
style=3D"mso-list: Ignore"><FONT size=3D3>3.</FONT><SPAN=20
style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></SPAN></SPAN><FONT size=3D3>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.</FONT></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 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.</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>Best regards,</FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT size=3D3><FONT=20
face=3D"Times New Roman"><st1:PersonName w:st=3D"on">Adrian =
Farrel</st1:PersonName>=20
and Deborah Brungard,</FONT></FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT face=3D"Times =
New Roman"=20
size=3D3>CCAMP co-chairs</FONT></P></FONT></DIV></BODY></HTML>

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

Delivery-date: Fri, 28 Jul 2006 19:36:15 +0000
To: "Igor Bryskin" <[email-masked]>
Cc: "Adrian Farrel" <[email-masked]>, [email-masked]
Subject: Re: OSPF ASON Routing Solution
From: [email-masked]
Date: Fri, 28 Jul 2006 21:34:19 +0200

hi igor - see in-line

Dimitri,

Thanks,
Igor

----- Original Message ----- 
From: "Adrian Farrel" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>; <[email-masked]>
Sent: Wednesday, July 26, 2006 9:52 AM
Subject: Re: OSPF ASON Routing Solution

draft
WG
for
WG
> >> draft.

Delivery-date: Fri, 28 Jul 2006 16:36:29 +0000
Content-class: urn:content-classes:message
Subject: RE: Proposed response to OIF on OSPF ENNI
Date: Fri, 28 Jul 2006 12:27:48 -0400
From: "Ong, Lyndon" <[email-masked]>
To: "Brungard, Deborah A, ALABS" <[email-masked]>, <[email-masked]>
Cc: "Adrian Farrel" <[email-masked]>

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

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

Hi,
=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><SPAN class=3D427151216-28072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Hi Deborah, Adrian,</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D427151216-28072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D427151216-28072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>I am still not happy with the tone of the =
liaison and some=20
nits (still don't see why an</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D427151216-28072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>OIF document cannot reflect OIF work over the =
last several=20
years, for example),</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D427151216-28072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>but it is probably best to get a liaison out =
now since OIF=20
meets next week.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D427151216-28072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D427151216-28072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Just for the record, I think many if not all of =
the=20
specific text points can be addressed, but</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D427151216-28072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>disagree with a number of the broader =
conclusions,=20
particularly on the relative</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D427151216-28072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>roles of OIF and IETF.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D427151216-28072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D427151216-28072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Cheers,</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D427151216-28072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D427151216-28072006><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> [email-masked]=20
[mailto:[email-masked]] <B>On Behalf Of </B>Brungard, Deborah =
A,=20
ALABS<BR><B>Sent:</B> Thursday, July 27, 2006 2:59 PM<BR><B>To:</B>=20
[email-masked]<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 dir=3Dltr align=3Dleft><SPAN class=3D694204621-27072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Thanks all for the discussion. I've updated to=20
include:</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D694204621-27072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>- our discussion on "alignment" --&gt; amended =
to say "does=20
not appear to be aligned"</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D694204621-27072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>- 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</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D694204621-27072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>- 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)</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D694204621-27072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D694204621-27072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>We'll target COB (EST) tomorrow for=20
finalizing-</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D694204621-27072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Deborah</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D694204621-27072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D694204621-27072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>=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</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D694204621-27072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D694204621-27072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT face=3D"Times =
New Roman"=20
color=3D#000000 size=3D3>Dear Jim,</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 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.</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>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, =
</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" 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.</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>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 color=3D#000000><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></FONT></SPAN></SPAN><FONT face=3D"Times New Roman" =
color=3D#000000=20
size=3D3>What is the intent of this document? Will it be published as an =

Implementation Agreement (IA)?<BR>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></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 color=3D#000000><FONT =
size=3D3>2.</FONT><SPAN=20
style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></FONT></SPAN></SPAN></I><FONT size=3D3><FONT color=3D#000000>The =
list of=20
changes from the previous version (listed under the Table of Contents) =
includes=20
&#8220;<I><SPAN style=3D"mso-bidi-font-weight: bold">removed =
&#8220;intra-carrier&#8221;=20
limitation</SPAN></I><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.<I><o:p></o:p></I></SPAN></FONT></FONT></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 color=3D#000000><FONT =
size=3D3>3.</FONT><SPAN=20
style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></FONT></SPAN></SPAN></I><SPAN=20
style=3D"mso-bidi-font-weight: bold; mso-bidi-font-style: italic"><FONT=20
size=3D3><FONT color=3D#000000>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.<I><o:p></o:p></I></FONT></FONT></SPAN></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"><SPAN=20
style=3D"mso-fareast-font-family: 'Times New Roman'"><SPAN=20
style=3D"mso-list: Ignore"><FONT color=3D#000000><FONT =
size=3D3>4.</FONT><SPAN=20
style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></FONT></SPAN></SPAN><FONT color=3D#000000 size=3D3>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; </SPAN>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></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"><SPAN=20
style=3D"mso-fareast-font-family: 'Times New Roman'"><SPAN=20
style=3D"mso-list: Ignore"><FONT color=3D#000000><FONT =
size=3D3>5.</FONT><SPAN=20
style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></FONT></SPAN></SPAN><FONT color=3D#000000 size=3D3>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> [email-masked]=20
[mailto:[email-masked]] <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
[email-masked]<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></I></FONT></FONT><SPAN=20
style=3D"mso-bidi-font-weight: bold; mso-bidi-font-style: italic"><FONT=20
size=3D3><FONT face=3D"Times New Roman">&#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><o:p></o:p></I></FONT></FONT></SPAN></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"><SPAN=20
style=3D"mso-fareast-font-family: 'Times New Roman'"><SPAN=20
style=3D"mso-list: Ignore"><FONT size=3D3>3.</FONT><SPAN=20
style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></SPAN></SPAN><FONT size=3D3>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.</FONT></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 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.</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>Best regards,</FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT size=3D3><FONT=20
face=3D"Times New Roman"><st1:PersonName w:st=3D"on">Adrian =
Farrel</st1:PersonName>=20
and Deborah Brungard,</FONT></FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT face=3D"Times =
New Roman"=20
size=3D3>CCAMP co-chairs</FONT></P></FONT></DIV></BODY></HTML>

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

Delivery-date: Fri, 28 Jul 2006 14:39:06 +0000
From: "Igor Bryskin" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, "Adrian Farrel" <[email-masked]>
Subject: Re: OSPF ASON Routing Solution
Date: Fri, 28 Jul 2006 10:36:38 -0400

Dimitri,

Thanks,
Igor

----- Original Message ----- 
From: "Adrian Farrel" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>; <[email-masked]>
Sent: Wednesday, July 26, 2006 9:52 AM
Subject: Re: OSPF ASON Routing Solution

WG
for
> >> PS Note that a solution does not have to be 100% perfect to become a WG

Delivery-date: Thu, 27 Jul 2006 23:09:54 +0000
Content-class: urn:content-classes:message
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
From: "Sadler, Jonathan B." <[email-masked]>
To: "Adrian Farrel" <[email-masked]>
Cc: <[email-masked]>

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:[email-masked]]=20

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

To: Sadler, Jonathan B.

Cc: [email-masked]

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>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span style=3D'=
font-size:
10.0pt'>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></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 style=3D'margin-left:9.0pt'><font size=3D2 face=3D"=
Courier New"><span
style=3D'font-size:10.0pt'>&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></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'>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:[email-masked]] <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: [email-masked]<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>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span style=3D'=
font-size:
10.0pt'>evaluation document meet the needs of OIF. You say you are unable to
make <o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span style=3D'=
font-size:
10.0pt'>this personal evaluation. That is surprising. One would expect that=
 you
<o:p></o:p></span></font></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--

Delivery-date: Thu, 27 Jul 2006 22:01:03 +0000
Content-class: urn:content-classes:message
Subject: RE: Proposed response to OIF on OSPF ENNI
Date: Thu, 27 Jul 2006 16:59:29 -0500
From: "Brungard, Deborah A, ALABS" <[email-masked]>
To: <[email-masked]>
Cc: "Adrian Farrel" <[email-masked]>

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

Hi,
=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><SPAN class=3D694204621-27072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Thanks all for the discussion. I've updated to=20
include:</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D694204621-27072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>- our discussion on "alignment" --&gt; amended =
to say "does=20
not appear to be aligned"</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D694204621-27072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>- 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</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D694204621-27072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>- 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)</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D694204621-27072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D694204621-27072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>We'll target COB (EST) tomorrow for=20
finalizing-</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D694204621-27072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Deborah</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D694204621-27072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D694204621-27072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>=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</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D694204621-27072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D694204621-27072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT face=3D"Times =
New Roman"=20
color=3D#000000 size=3D3>Dear Jim,</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 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.</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>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, =
</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" 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.</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>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 color=3D#000000><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></FONT></SPAN></SPAN><FONT face=3D"Times New Roman" =
color=3D#000000=20
size=3D3>What is the intent of this document? Will it be published as an =

Implementation Agreement (IA)?<BR>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></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 color=3D#000000><FONT =
size=3D3>2.</FONT><SPAN=20
style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></FONT></SPAN></SPAN></I><FONT size=3D3><FONT color=3D#000000>The =
list of=20
changes from the previous version (listed under the Table of Contents) =
includes=20
&#8220;<I><SPAN style=3D"mso-bidi-font-weight: bold">removed =
&#8220;intra-carrier&#8221;=20
limitation</SPAN></I><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.<I><o:p></o:p></I></SPAN></FONT></FONT></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 color=3D#000000><FONT =
size=3D3>3.</FONT><SPAN=20
style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></FONT></SPAN></SPAN></I><SPAN=20
style=3D"mso-bidi-font-weight: bold; mso-bidi-font-style: italic"><FONT=20
size=3D3><FONT color=3D#000000>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.<I><o:p></o:p></I></FONT></FONT></SPAN></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"><SPAN=20
style=3D"mso-fareast-font-family: 'Times New Roman'"><SPAN=20
style=3D"mso-list: Ignore"><FONT color=3D#000000><FONT =
size=3D3>4.</FONT><SPAN=20
style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></FONT></SPAN></SPAN><FONT color=3D#000000 size=3D3>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; </SPAN>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></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"><SPAN=20
style=3D"mso-fareast-font-family: 'Times New Roman'"><SPAN=20
style=3D"mso-list: Ignore"><FONT color=3D#000000><FONT =
size=3D3>5.</FONT><SPAN=20
style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></FONT></SPAN></SPAN><FONT color=3D#000000 size=3D3>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> [email-masked]=20
[mailto:[email-masked]] <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
[email-masked]<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></I></FONT></FONT><SPAN=20
style=3D"mso-bidi-font-weight: bold; mso-bidi-font-style: italic"><FONT=20
size=3D3><FONT face=3D"Times New Roman">&#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><o:p></o:p></I></FONT></FONT></SPAN></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"><SPAN=20
style=3D"mso-fareast-font-family: 'Times New Roman'"><SPAN=20
style=3D"mso-list: Ignore"><FONT size=3D3>3.</FONT><SPAN=20
style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></SPAN></SPAN><FONT size=3D3>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.</FONT></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 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.</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>Best regards,</FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT size=3D3><FONT=20
face=3D"Times New Roman"><st1:PersonName w:st=3D"on">Adrian =
Farrel</st1:PersonName>=20
and Deborah Brungard,</FONT></FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT face=3D"Times =
New Roman"=20
size=3D3>CCAMP co-chairs</FONT></P></FONT></DIV></BODY></HTML>

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

Delivery-date: Thu, 27 Jul 2006 18:32:43 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Mack-Crane, T. Benjamin" <[email-masked]>
Cc: <[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>
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

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

Delivery-date: Thu, 27 Jul 2006 18:32:36 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Jim Jones" <[email-masked]>
Cc: <[email-masked]>
Subject: New CCAMP I-D of interest to OIF
Date: Thu, 27 Jul 2006 18:31:38 +0100
Organization: Old Dog Consulting

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: [email-masked]
Delivery-date: Thu, 27 Jul 2006 03:27:19 +0000
To: IETF-Announce <[email-masked]>
From: The IESG <[email-masked]>
Subject: Last Call: 'GMPLS - Communication of Alarm Information' to Proposed  Standard (draft-ietf-ccamp-gmpls-alarm-spec) 
Reply-to: [email-masked]
CC: <[email-masked]>
Message-Id: <[email-masked]>
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
[email-masked] or [email-masked] 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: [email-masked]
Delivery-date: Thu, 27 Jul 2006 03:24:33 +0000
To: IETF-Announce <[email-masked]>
From: The IESG <[email-masked]>
Subject: Last Call: 'Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE'  to Proposed Standard (draft-ietf-ccamp-crankback) 
Reply-to: [email-masked]
CC: <[email-masked]>
Message-Id: <[email-masked]>
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
[email-masked] or [email-masked] mailing lists by 2006-08-09.

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

Delivery-date: Wed, 26 Jul 2006 21:25:02 +0000
Content-class: urn:content-classes:message
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
From: "Mack-Crane, T. Benjamin" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>
Cc: <[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>

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

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

Delivery-date: Wed, 26 Jul 2006 19:56:01 +0000
From: "Jim Jones" <[email-masked]>
To: "'Adrian Farrel'" <[email-masked]>
Cc: "'Brungard, Deborah A, ALABS'" <[email-masked]>, <[email-masked]>
Subject: RE: Ethernet Traffic Parameters for Use in RSVP-TE Signaling
Date: Wed, 26 Jul 2006 14:55:41 -0500

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:[email-masked]] 
Sent: Wednesday, July 26, 2006 11:23 AM
To: Jim Jones
Cc: Brungard, Deborah A, ALABS; [email-masked]
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

Delivery-date: Wed, 26 Jul 2006 19:51:39 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-ason-routing-ospf-00.txt 
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 
[email-masked] 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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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:	<[email-masked]>

--OtherAccess--

--NextPart--

Delivery-date: Wed, 26 Jul 2006 17:19:38 +0000
Date: Wed, 26 Jul 2006 19:17:53 +0200
From: Loa Andersson <[email-masked]>
Organization: Acreo AB
To: Adrian Farrel <[email-masked]>
CC: Jonathan Sadler <[email-masked]>, [email-masked], IAB <[email-masked]>
Subject: An IETF / OIF liaison relationship Was: (Re: Proposed response to OIF on OSPF ENNI)

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:  [email-masked]
                                           [email-masked]

Delivery-date: Wed, 26 Jul 2006 16:36:58 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Jim Jones" <[email-masked]>
Cc: "Brungard, Deborah A, ALABS" <[email-masked]>, <[email-masked]>
Subject: Ethernet Traffic Parameters for Use in RSVP-TE Signaling
Date: Wed, 26 Jul 2006 17:23:16 +0100
Organization: Old Dog Consulting

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

Delivery-date: Wed, 26 Jul 2006 16:20:39 +0000
Content-class: urn:content-classes:message
Subject: RE: Proposed response to OIF on OSPF ENNI
Date: Wed, 26 Jul 2006 09:20:10 -0700
From: "Drake, John E" <[email-masked]>
To: "Ong, Lyndon" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

Lyndon,

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

Thanks,

John

> From: Ong, Lyndon [mailto:[email-masked]]=20
> Sent: Wednesday, July 26, 2006 9:10 AM
> To: [email-masked]
> Cc: [email-masked]; Drake, John E; [email-masked]
> 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
> From: [email-masked]=20
> [mailto:[email-masked]]=20
> Sent: Wednesday, July 26, 2006 12:53 AM
> To: Ong, Lyndon
> Cc: [email-masked]; Drake, John E; [email-masked]
> 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" <[email-masked]>
> 26/07/2006 00:22
> =20
>         To:     "Drake, John E" <[email-masked]>,=20
> <[email-masked]>
>         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: [email-masked]=20
> [mailto:[email-masked]] On Behalf=20
> Of Drake, John E
> Sent: Tuesday, July 25, 2006 3:08 PM
> To: [email-masked]
> Subject: RE: Proposed response to OIF on OSPF ENNI
>=20
> =20
> From: Ong, Lyndon [mailto:[email-masked]]=20
> Sent: Tuesday, July 25, 2006 2:39 PM
> To: Drake, John E; [email-masked]
> 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: [email-masked]=20
> [mailto:[email-masked]] On Behalf=20
> Of Drake, John E
> Sent: Tuesday, July 25, 2006 2:28 PM
> To: [email-masked]
> 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

Delivery-date: Wed, 26 Jul 2006 16:11:51 +0000
Content-class: urn:content-classes:message
Subject: RE: Proposed response to OIF on OSPF ENNI
Date: Wed, 26 Jul 2006 12:09:48 -0400
From: "Ong, Lyndon" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, "Drake, John E" <[email-masked]>, <[email-masked]>

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: [email-masked]
[mailto:[email-masked]]=20
Sent: Wednesday, July 26, 2006 12:53 AM
To: Ong, Lyndon
Cc: [email-masked]; Drake, John E; [email-masked]
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" <[email-masked]>
Sent by: [email-masked]
26/07/2006 00:22
=20
        To:     "Drake, John E" <[email-masked]>,=20
<[email-masked]>
        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: [email-masked] [mailto:[email-masked]] On
Behalf=20
Of Drake, John E
Sent: Tuesday, July 25, 2006 3:08 PM
To: [email-masked]
Subject: RE: Proposed response to OIF on OSPF ENNI

=20
-----Original Message-----
From: Ong, Lyndon [mailto:[email-masked]]=20
Sent: Tuesday, July 25, 2006 2:39 PM
To: Drake, John E; [email-masked]
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: [email-masked] [mailto:[email-masked]] On
Behalf=20
Of Drake, John E
Sent: Tuesday, July 25, 2006 2:28 PM
To: [email-masked]
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

Delivery-date: Wed, 26 Jul 2006 13:54:02 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>, <[email-masked]>
Subject: Re: OSPF ASON Routing Solution
Date: Wed, 26 Jul 2006 14:52:26 +0100
Organization: Old Dog Consulting

Thanks,
Adrian
----- Original Message ----- 
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, July 19, 2006 2:27 PM
Subject: Re: OSPF ASON Routing Solution

>> PS Note that a solution does not have to be 100% perfect to become a WG 

Delivery-date: Wed, 26 Jul 2006 13:45:27 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Richard Rabbat" <[email-masked]>, "Sadler, Jonathan B." <[email-masked]>
Cc: "Brungard, Deborah A, ALABS" <[email-masked]>, "Ong, Lyndon" <[email-masked]>, <[email-masked]>, "Richard Rabbat" <[email-masked]>
Subject: Addressing draft [Was: Proposed response to OIF on OSPF ENNI]
Date: Wed, 26 Jul 2006 14:43:42 +0100
Organization: Old Dog Consulting

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

Delivery-date: Wed, 26 Jul 2006 13:40:04 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Jonathan Sadler" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Proposed response to OIF on OSPF ENNI
Date: Wed, 26 Jul 2006 14:39:30 +0100
Organization: Old Dog Consulting

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 

Delivery-date: Wed, 26 Jul 2006 13:35:13 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: "Scott Bradner" <[email-masked]>
Subject: Statements about liaison relationship with ITU-T SG15
Date: Wed, 26 Jul 2006 14:32:14 +0100
Organization: Old Dog Consulting

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

Delivery-date: Wed, 26 Jul 2006 13:05:08 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Sadler, Jonathan B." <[email-masked]>
Cc: <[email-masked]>
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

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

Delivery-date: Wed, 26 Jul 2006 08:49:24 +0000
Content-class: urn:content-classes:message
Subject: RE: Proposed response to OIF on OSPF ENNI
Date: Wed, 26 Jul 2006 10:48:04 +0200
From: "MEURIC Julien RD-CORE-LAN" <[email-masked]>
To: "Brungard, Deborah A, ALABS" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

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: [email-masked] [mailto:[email-masked]] 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:[email-masked]]=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

Delivery-date: Wed, 26 Jul 2006 07:53:27 +0000
To: "Ong, Lyndon" <[email-masked]>
Cc: [email-masked], "Drake, John E" <[email-masked]>, [email-masked]
Subject: RE: Proposed response to OIF on OSPF ENNI
From: [email-masked]
Date: Wed, 26 Jul 2006 09:52:37 +0200

Delivery-date: Wed, 26 Jul 2006 07:07:20 +0000
Date: Wed, 26 Jul 2006 16:05:21 +0900
To: [email-masked], [email-masked], [email-masked], [email-masked]
From: Ken Nagami <[email-masked]>
Subject: comments for draft-ietf-ccamp-gmpls-ospf-mib-00.txt
Cc: [email-masked]

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

Delivery-date: Tue, 25 Jul 2006 23:24:51 +0000
To: "Payam Torab" <[email-masked]>
Cc: [email-masked], "'Dave Walters'" <[email-masked]>, [email-masked]
Subject: RE: shared mesh restoration - e2e recovery signaling draft
From: [email-masked]
Date: Wed, 26 Jul 2006 01:24:09 +0200

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" <[email-masked]>
Sent by: [email-masked]
26/07/2006 01:11
 
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     <[email-masked]>, "'Dave Walters'" 
<[email-masked]>, <[email-masked]>
        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

> From: [email-masked] 
> [mailto:[email-masked]] 
> Sent: Tuesday, July 25, 2006 6:53 PM
> To: Payam Torab
> Cc: [email-masked]; 'Dave Walters'; [email-masked]
> 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" <[email-masked]>
> 26/07/2006 00:47
>         cc:     <[email-masked]>, "'Dave Walters'" 
> <[email-masked]>, <[email-masked]>
>         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
> 
> 
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of 
> > [email-masked]
> > Sent: Tuesday, July 25, 2006 6:25 PM
> > To: Payam Torab
> > Cc: [email-masked]; 'Dave Walters'; [email-masked]
> > 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" <[email-masked]>
> > 26/07/2006 00:11
> >         cc:     "'Dave Walters'" <[email-masked]>
> >         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
> > 
> 
> 
> 

Delivery-date: Tue, 25 Jul 2006 23:13:29 +0000
From: "Payam Torab" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, "'Dave Walters'" <[email-masked]>, <[email-masked]>
Subject: RE: shared mesh restoration - e2e recovery signaling draft
Date: Tue, 25 Jul 2006 19:11:57 -0400
Organization: Lambda OpticalSystems

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

> From: [email-masked] 
> [mailto:[email-masked]] 
> Sent: Tuesday, July 25, 2006 6:53 PM
> To: Payam Torab
> Cc: [email-masked]; 'Dave Walters'; [email-masked]
> 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" <[email-masked]>
> 26/07/2006 00:47
>         cc:     <[email-masked]>, "'Dave Walters'" 
> <[email-masked]>, <[email-masked]>
>         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
> 
> 
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of 
> > [email-masked]
> > Sent: Tuesday, July 25, 2006 6:25 PM
> > To: Payam Torab
> > Cc: [email-masked]; 'Dave Walters'; [email-masked]
> > 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" <[email-masked]>
> > 26/07/2006 00:11
> >         cc:     "'Dave Walters'" <[email-masked]>
> >         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
> > 
> 
> 
> 

Delivery-date: Tue, 25 Jul 2006 22:53:37 +0000
To: "Payam Torab" <[email-masked]>
Cc: [email-masked], "'Dave Walters'" <[email-masked]>, [email-masked]
Subject: RE: shared mesh restoration - e2e recovery signaling draft
From: [email-masked]
Date: Wed, 26 Jul 2006 00:52:46 +0200

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" <[email-masked]>
Sent by: [email-masked]
26/07/2006 00:47
 
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     <[email-masked]>, "'Dave Walters'" 
<[email-masked]>, <[email-masked]>
        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

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> [email-masked]
> Sent: Tuesday, July 25, 2006 6:25 PM
> To: Payam Torab
> Cc: [email-masked]; 'Dave Walters'; [email-masked]
> 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" <[email-masked]>
> 26/07/2006 00:11
>         cc:     "'Dave Walters'" <[email-masked]>
>         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
> 

Delivery-date: Tue, 25 Jul 2006 22:48:57 +0000
From: "Payam Torab" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, "'Dave Walters'" <[email-masked]>, <[email-masked]>
Subject: RE: shared mesh restoration - e2e recovery signaling draft
Date: Tue, 25 Jul 2006 18:47:50 -0400
Organization: Lambda OpticalSystems

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

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> [email-masked]
> Sent: Tuesday, July 25, 2006 6:25 PM
> To: Payam Torab
> Cc: [email-masked]; 'Dave Walters'; [email-masked]
> 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" <[email-masked]>
> 26/07/2006 00:11
>         cc:     "'Dave Walters'" <[email-masked]>
>         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
> 

Delivery-date: Tue, 25 Jul 2006 22:46:13 +0000
Content-class: urn:content-classes:message
Subject: RE: Proposed response to OIF on OSPF ENNI
Date: Tue, 25 Jul 2006 18:38:25 -0400
From: "Ong, Lyndon" <[email-masked]>
To: "Drake, John E" <[email-masked]>, <[email-masked]>

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: [email-masked] [mailto:[email-masked]] On
Behalf Of Drake, John E
Sent: Tuesday, July 25, 2006 3:33 PM
To: [email-masked]
Subject: RE: Proposed response to OIF on OSPF ENNI

That's even worse than what I expected.

	-----Original Message-----
	From: Ong, Lyndon [mailto:[email-masked]]=20
	Sent: Tuesday, July 25, 2006 3:22 PM
	To: Drake, John E; [email-masked]
	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: [email-masked] [mailto:[email-masked]]
On Behalf Of Drake, John E
	Sent: Tuesday, July 25, 2006 3:08 PM
	To: [email-masked]
	Subject: RE: Proposed response to OIF on OSPF ENNI
=09
=09
	=20

		-----Original Message-----
		From: Ong, Lyndon [mailto:[email-masked]]=20
		Sent: Tuesday, July 25, 2006 2:39 PM
		To: Drake, John E; [email-masked]
		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: [email-masked]
[mailto:[email-masked]] On Behalf Of Drake, John E
		Sent: Tuesday, July 25, 2006 2:28 PM
		To: [email-masked]
		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> [email-masked]=20
[mailto:[email-masked]] <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
[email-masked]<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:[email-masked]] <BR><B>Sent:</B> Tuesday, July 25, 2006 3:22=20
  PM<BR><B>To:</B> Drake, John E; [email-masked]<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> [email-masked]=20
  [mailto:[email-masked]] <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
  [email-masked]<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:[email-masked]] <BR><B>Sent:</B> Tuesday, July 25, 2006 =
2:39=20
    PM<BR><B>To:</B> Drake, John E; =
[email-masked]<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> [email-masked]=20
    [mailto:[email-masked]] <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
    [email-masked]<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--

Delivery-date: Tue, 25 Jul 2006 22:46:06 +0000
Content-class: urn:content-classes:message
Subject: RE: Proposed response to OIF on OSPF ENNI
Date: Tue, 25 Jul 2006 18:39:31 -0400
From: "Ong, Lyndon" <[email-masked]>
To: <[email-masked]>
Cc: "Adrian Farrel" <[email-masked]>, <[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>, "Sadler, Jonathan B." <[email-masked]>, <[email-masked]>

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

Lyndon=20

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]=20
Sent: Tuesday, July 25, 2006 3:29 PM
To: Ong, Lyndon
Cc: Adrian Farrel; [email-masked]; Brungard, Deborah A, ALABS;
Sadler, Jonathan B.; [email-masked]
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" <[email-masked]>
25/07/2006 23:10
=20
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     "Adrian Farrel" <[email-masked]>,=20
<[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>,
"Sadler, Jonathan B." <[email-masked]>,
<[email-masked]>
        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: [email-masked]
[mailto:[email-masked]]
Sent: Tuesday, July 25, 2006 11:11 AM
To: Ong, Lyndon
Cc: Adrian Farrel; [email-masked]; Brungard, Deborah A, ALABS;
Sadler, Jonathan B.; [email-masked]
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" <[email-masked]>
25/07/2006 20:01
=20
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     "Adrian Farrel" <[email-masked]>,=20
<[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>,
"Sadler, Jonathan B." <[email-masked]>,
<[email-masked]>
        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: [email-masked]
[mailto:[email-masked]]
Sent: Tuesday, July 25, 2006 10:54 AM
To: Ong, Lyndon
Cc: Adrian Farrel; [email-masked]; Brungard, Deborah A, ALABS;
Sadler, Jonathan B.; [email-masked]
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" <[email-masked]>
Sent by: [email-masked]
25/07/2006 18:55
=20
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Sadler,=20
Jonathan B." <[email-masked]>
        cc:     "Adrian Farrel" <[email-masked]>,=20
<[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>,
<[email-masked]>
        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: [email-masked]
[mailto:[email-masked]]
Sent: Tuesday, July 25, 2006 3:18 AM
To: Sadler, Jonathan B.; Ong, Lyndon
Cc: Adrian Farrel; [email-masked]; Brungard, Deborah A, ALABS;
[email-masked]
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." <[email-masked]> Sent by:
[email-masked]
24/07/2006 22:31
=20
        To:     "Brungard, Deborah A, ALABS" <[email-masked]>, "Ong,=20
Lyndon" <[email-masked]>, <[email-masked]>
        cc:     "Adrian Farrel" <[email-masked]>
        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:[email-masked]]
Sent: Monday, July 24, 2006 2:33 PM
To: Brungard, Deborah A, ALABS; Sadler, Jonathan B.; [email-masked]
Cc: Adrian Farrel
Subject: RE: Proposed response to OIF on OSPF ENNI
=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: [email-masked] [mailto:[email-masked]] On
Behalf Of Brungard, Deborah A, ALABS
Sent: Monday, July 24, 2006 12:15 PM
To: Sadler, Jonathan B.; [email-masked]
Cc: Adrian Farrel
Subject: RE: Proposed response to OIF on OSPF ENNI Hi Jonathan, (and
Lyndon),
=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:[email-masked]]
Sent: Friday, July 21, 2006 11:34 AM
To: Brungard, Deborah A, ALABS; [email-masked]
Cc: Adrian Farrel
Subject: RE: Proposed response to OIF on OSPF ENNI Hi Deborah and
Adrian,
=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: [email-masked] [mailto:[email-masked]] On
Behalf Of Brungard, Deborah A, ALABS
Sent: Friday, July 21, 2006 9:38 AM
To: [email-masked]
Cc: Adrian Farrel
Subject: Proposed response to OIF on OSPF ENNI
=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

Delivery-date: Tue, 25 Jul 2006 22:33:38 +0000
Content-class: urn:content-classes:message
Subject: RE: Proposed response to OIF on OSPF ENNI
Date: Tue, 25 Jul 2006 15:33:10 -0700
From: "Drake, John E" <[email-masked]>
To: <[email-masked]>

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:[email-masked]]=20
	Sent: Tuesday, July 25, 2006 3:22 PM
	To: Drake, John E; [email-masked]
	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: [email-masked] [mailto:[email-masked]]
On Behalf Of Drake, John E
	Sent: Tuesday, July 25, 2006 3:08 PM
	To: [email-masked]
	Subject: RE: Proposed response to OIF on OSPF ENNI
=09
=09
	=20

		-----Original Message-----
		From: Ong, Lyndon [mailto:[email-masked]]=20
		Sent: Tuesday, July 25, 2006 2:39 PM
		To: Drake, John E; [email-masked]
		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: [email-masked]
[mailto:[email-masked]] On Behalf Of Drake, John E
		Sent: Tuesday, July 25, 2006 2:28 PM
		To: [email-masked]
		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:[email-masked]] <BR><B>Sent:</B> Tuesday, July 25, 2006 3:22=20
  PM<BR><B>To:</B> Drake, John E; [email-masked]<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> [email-masked]=20
  [mailto:[email-masked]] <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
  [email-masked]<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:[email-masked]] <BR><B>Sent:</B> Tuesday, July 25, 2006 =
2:39=20
    PM<BR><B>To:</B> Drake, John E; =
[email-masked]<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> [email-masked]=20
    [mailto:[email-masked]] <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
    [email-masked]<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--

Delivery-date: Tue, 25 Jul 2006 22:30:04 +0000
To: "Ong, Lyndon" <[email-masked]>
Cc: "Adrian Farrel" <[email-masked]>, [email-masked], "Brungard, Deborah A, ALABS" <[email-masked]>, "Sadler, Jonathan B." <[email-masked]>, [email-masked]
Subject: RE: Proposed response to OIF on OSPF ENNI
From: [email-masked]
Date: Wed, 26 Jul 2006 00:29:25 +0200

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" <[email-masked]>
25/07/2006 23:10
 
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     "Adrian Farrel" <[email-masked]>, 
<[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>, 
"Sadler, Jonathan B." <[email-masked]>, 
<[email-masked]>
        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: [email-masked]
[mailto:[email-masked]] 
Sent: Tuesday, July 25, 2006 11:11 AM
To: Ong, Lyndon
Cc: Adrian Farrel; [email-masked]; Brungard, Deborah A, ALABS;
Sadler, Jonathan B.; [email-masked]
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" <[email-masked]>
25/07/2006 20:01
 
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     "Adrian Farrel" <[email-masked]>, 
<[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>,
"Sadler, Jonathan B." <[email-masked]>,
<[email-masked]>
        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: [email-masked]
[mailto:[email-masked]]
Sent: Tuesday, July 25, 2006 10:54 AM
To: Ong, Lyndon
Cc: Adrian Farrel; [email-masked]; Brungard, Deborah A, ALABS;
Sadler, Jonathan B.; [email-masked]
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" <[email-masked]>
Sent by: [email-masked]
25/07/2006 18:55
 
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Sadler, 
Jonathan B." <[email-masked]>
        cc:     "Adrian Farrel" <[email-masked]>, 
<[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>,
<[email-masked]>
        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: [email-masked]
[mailto:[email-masked]] 
Sent: Tuesday, July 25, 2006 3:18 AM
To: Sadler, Jonathan B.; Ong, Lyndon
Cc: Adrian Farrel; [email-masked]; Brungard, Deborah A, ALABS;
[email-masked]
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." <[email-masked]> Sent by:
[email-masked]
24/07/2006 22:31
 
        To:     "Brungard, Deborah A, ALABS" <[email-masked]>, "Ong, 
Lyndon" <[email-masked]>, <[email-masked]>
        cc:     "Adrian Farrel" <[email-masked]>
        Subject:        RE: Proposed response to OIF on OSPF ENNI

Hi Deborah, Lyndon, et al,
 
Some additional comments:
 - The hierarchical model discussed in the draft IA liaised may be
supported without any modifications to OSPF.  As discussed in earlier
emails, it can be implemented solely through the import/export of
information described in Appendix I of G.7715.
 - The draft IA also recognizes namespace issues exist between Router ID
and the IP Address that messages are sent to (ITU calls this the RC PC
SCN address).  This issue is also discussed in
draft-ietf-ccamp-gmpls-addressing.
 
Given that:
-          CCAMP has a milestone to publish an ASON routing solution by 
Nov 2006, 
-          CCAMP didn't have at the time this was liaised (doesn't have 
today?) a working group document, and
-          the draft IA has been successfully implemented by more than a

dozen vendors and interop-tested many times, I would expect that we
should be looking at this as experience/text that could be leveraged...
"Running code..." and all that...
 
Regards,
 
Jonathan Sadler

From: Ong, Lyndon [mailto:[email-masked]]
Sent: Monday, July 24, 2006 2:33 PM
To: Brungard, Deborah A, ALABS; Sadler, Jonathan B.; [email-masked]
Cc: Adrian Farrel
Subject: RE: Proposed response to OIF on OSPF ENNI
 
Hi Deborah,
 
Here's what I would say is in and not in the OIF document:
 
-- G.7715, G.7715.1 and the IETF eval and solutions draft all identify a
need to support hierarchical routing areas for ASON, I am perplexed as
to why this seems to be viewed as a new feature.
 
-- the document does not specify the domain of usage and leaves this to
the carrier.  This is no different from G.7715.1 and IETF drafts that do
not explicitly state whether they are used for intra- or inter-domain
interfaces.
 
-- GMPLS OSPF does not support a 1:N or N:1 relationship between routing
controller and transport node, hence extensions are felt to be required
- and are proposed in the eval solutions draft. The conclusions are no
different.
 
-- the document does not in fact define any standard extensions to the
protocols, and points to future work in IETF and ITU to provide these.
Therefore I cannot understand where you say "new extensions to OSPF are
specified" and "none...align with the CCAMP's GMPLS-ASON work". 
 
I think we're experiencing a significant miscommunication...
 
Cheers,
 
Lyndon

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Brungard, Deborah A, ALABS
Sent: Monday, July 24, 2006 12:15 PM
To: Sadler, Jonathan B.; [email-masked]
Cc: Adrian Farrel
Subject: RE: Proposed response to OIF on OSPF ENNI Hi Jonathan, (and
Lyndon),
 
Thanks to both of you for responding.
 
"Significant" was referencing:
 
- supports a (new) hierarchical OSPF model
- supports inter-domain (inter-carrier) OSPF (not supported by today's
OSPF)
- identifies namespace issues with GMPLS OSPF which do not exist, and
proposes extensions to "fix"
- new extensions to OSPF are specified
- none of the proposed extensions align with CCAMP's GMPLS-ASON work
 
Did you have another adjective to suggest? We were thinking
"significant" 
was rather soft considering the above. Though if it's just ITU-speak
differences, why does the OIF liaison state it reflects several years of
work including testing? Any insight (alignment mapping to CCAMP's work)
which you or Lyndon can provide would be helpful. The divergence is
baffling to us.
 
Deborah

From: Sadler, Jonathan B. [mailto:[email-masked]]
Sent: Friday, July 21, 2006 11:34 AM
To: Brungard, Deborah A, ALABS; [email-masked]
Cc: Adrian Farrel
Subject: RE: Proposed response to OIF on OSPF ENNI Hi Deborah and
Adrian,
 
I haven't seen much discussion of the OIF E-NNI Routing document on the
CCAMP list.  Can you tell me what parts of the document are "significant
modifications to the operation of OSPF"?
 
Thanks,
 
Jonathan Sadler

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Brungard, Deborah A, ALABS
Sent: Friday, July 21, 2006 9:38 AM
To: [email-masked]
Cc: Adrian Farrel
Subject: Proposed response to OIF on OSPF ENNI
 
Hi,
 
We had a communication from OIF on their OSPF ENNI specification. You
can see the original files on http://www.olddog.co.uk/ccamp.htm. 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
============================================================

Delivery-date: Tue, 25 Jul 2006 22:25:49 +0000
To: "Payam Torab" <[email-masked]>
Cc: [email-masked], "'Dave Walters'" <[email-masked]>, [email-masked]
Subject: Re: shared mesh restoration - e2e recovery signaling draft
From: [email-masked]
Date: Wed, 26 Jul 2006 00:25:20 +0200

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" <[email-masked]>
Sent by: [email-masked]
26/07/2006 00:11
 
        To:     <[email-masked]>
        cc:     "'Dave Walters'" <[email-masked]>
        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

Delivery-date: Tue, 25 Jul 2006 22:23:55 +0000
Content-class: urn:content-classes:message
Subject: RE: Proposed response to OIF on OSPF ENNI
Date: Tue, 25 Jul 2006 18:22:19 -0400
From: "Ong, Lyndon" <[email-masked]>
To: "Drake, John E" <[email-masked]>, <[email-masked]>

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: [email-masked] [mailto:[email-masked]] On
Behalf Of Drake, John E
Sent: Tuesday, July 25, 2006 3:08 PM
To: [email-masked]
Subject: RE: Proposed response to OIF on OSPF ENNI

=20

	-----Original Message-----
	From: Ong, Lyndon [mailto:[email-masked]]=20
	Sent: Tuesday, July 25, 2006 2:39 PM
	To: Drake, John E; [email-masked]
	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: [email-masked] [mailto:[email-masked]]
On Behalf Of Drake, John E
	Sent: Tuesday, July 25, 2006 2:28 PM
	To: [email-masked]
	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> [email-masked]=20
[mailto:[email-masked]] <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
[email-masked]<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:[email-masked]] <BR><B>Sent:</B> Tuesday, July 25, 2006 2:39=20
  PM<BR><B>To:</B> Drake, John E; [email-masked]<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> [email-masked]=20
  [mailto:[email-masked]] <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
  [email-masked]<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--

Delivery-date: Tue, 25 Jul 2006 22:12:06 +0000
From: "Payam Torab" <[email-masked]>
To: <[email-masked]>
Cc: "'Dave Walters'" <[email-masked]>
Subject: shared mesh restoration - e2e recovery signaling draft
Date: Tue, 25 Jul 2006 18:11:01 -0400
Organization: Lambda OpticalSystems

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

Delivery-date: Tue, 25 Jul 2006 22:09:07 +0000
Content-class: urn:content-classes:message
Subject: RE: Proposed response to OIF on OSPF ENNI
Date: Tue, 25 Jul 2006 15:08:02 -0700
From: "Drake, John E" <[email-masked]>
To: <[email-masked]>

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:[email-masked]]=20
	Sent: Tuesday, July 25, 2006 2:39 PM
	To: Drake, John E; [email-masked]
	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: [email-masked] [mailto:[email-masked]]
On Behalf Of Drake, John E
	Sent: Tuesday, July 25, 2006 2:28 PM
	To: [email-masked]
	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:[email-masked]] <BR><B>Sent:</B> Tuesday, July 25, 2006 2:39=20
  PM<BR><B>To:</B> Drake, John E; [email-masked]<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> [email-masked]=20
  [mailto:[email-masked]] <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
  [email-masked]<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--

Delivery-date: Tue, 25 Jul 2006 21:45:52 +0000
Content-class: urn:content-classes:message
Subject: RE: Proposed response to OIF on OSPF ENNI
Date: Tue, 25 Jul 2006 17:39:14 -0400
From: "Ong, Lyndon" <[email-masked]>
To: "Drake, John E" <[email-masked]>, <[email-masked]>

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: [email-masked] [mailto:[email-masked]] On
Behalf Of Drake, John E
Sent: Tuesday, July 25, 2006 2:28 PM
To: [email-masked]
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><FONT face=3DArial color=3D#0000ff =
size=3D2>interoperability=20
tests.</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>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> [email-masked]=20
[mailto:[email-masked]] <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
[email-masked]<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, 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_01C6B032.C6E99EBE--

Delivery-date: Tue, 25 Jul 2006 21:38:28 +0000
Content-class: urn:content-classes:message
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
From: "Brungard, Deborah A, ALABS" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>
Cc: <[email-masked]>

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:[email-masked]]=20
Sent: Wednesday, July 12, 2006 3:54 PM
To: Brungard, Deborah A, ALABS
Cc: [email-masked]
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

Delivery-date: Tue, 25 Jul 2006 21:28:31 +0000
Content-class: urn:content-classes:message
Subject: RE: Proposed response to OIF on OSPF ENNI
Date: Tue, 25 Jul 2006 14:28:09 -0700
From: "Drake, John E" <[email-masked]>
To: <[email-masked]>

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

Delivery-date: Tue, 25 Jul 2006 21:26:37 +0000
Date: Tue, 25 Jul 2006 14:25:52 -0700
From: Richard Rabbat <[email-masked]>
To: "Sadler, Jonathan B." <[email-masked]>
CC: "Brungard, Deborah A, ALABS" <[email-masked]>, "Ong, Lyndon" <[email-masked]>, [email-masked], Adrian Farrel <[email-masked]>, Richard Rabbat <[email-masked]>
Subject: Re: Proposed response to OIF on OSPF ENNI

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 didn’t have at the time this was liaised (doesn’t have today?) 
> a working group document, and
>
> - the draft IA has been successfully implemented by more than a dozen 
> vendors and interop-tested many times,
>
> I would expect that we should be looking at this as experience/text 
> that could be leveraged... “Running code…” and all that…
>
> Regards,
>
> Jonathan Sadler
>
> ------------------------------------------------------------------------
>
> *From:* Ong, Lyndon [mailto:[email-masked]]
> *Sent:* Monday, July 24, 2006 2:33 PM
> *To:* Brungard, Deborah A, ALABS; Sadler, Jonathan B.; [email-masked]
> *Cc:* Adrian Farrel
> *Subject:* RE: Proposed response to OIF on OSPF ENNI
>
> Hi Deborah,
>
> Here's what I would say is in and not in the OIF document:
>
> -- G.7715, G.7715.1 and the IETF eval and solutions draft all identify 
> a need to support hierarchical
>
> routing areas for ASON, I am perplexed as to why this seems to be 
> viewed as a new feature.
>
> -- the document does not specify the domain of usage and leaves this 
> to the carrier. This is no different
>
> from G.7715.1 and IETF drafts that do not explicitly state whether 
> they are used for intra- or inter-domain
>
> interfaces.
>
> -- GMPLS OSPF does not support a 1:N or N:1 relationship between 
> routing controller and transport
>
> node, hence extensions are felt to be required - and are proposed in 
> the eval solutions draft. The
>
> conclusions are no different.
>
> -- the document does not in fact define any standard extensions to the 
> protocols, and points to future work
>
> in IETF and ITU to provide these. Therefore I cannot understand where 
> you say "new extensions to
>
> OSPF are specified" and "none...align with the CCAMP's GMPLS-ASON work".
>
> I think we're experiencing a significant miscommunication...
>
> Cheers,
>
> Lyndon
>
> ------------------------------------------------------------------------
>
> *From:* [email-masked] [mailto:[email-masked]] *On 
> Behalf Of *Brungard, Deborah A, ALABS
> *Sent:* Monday, July 24, 2006 12:15 PM
> *To:* Sadler, Jonathan B.; [email-masked]
> *Cc:* Adrian Farrel
> *Subject:* RE: Proposed response to OIF on OSPF ENNI
>
> Hi Jonathan, (and Lyndon),
>
> Thanks to both of you for responding.
>
> "Significant" was referencing:
>
> - supports a (new) hierarchical OSPF model
>
> - supports inter-domain (inter-carrier) OSPF (not supported by today's 
> OSPF)
>
> - identifies namespace issues with GMPLS OSPF which do not exist, and 
> proposes extensions to "fix"
>
> - new extensions to OSPF are specified
>
> - none of the proposed extensions align with CCAMP's GMPLS-ASON work
>
> Did you have another adjective to suggest? We were thinking 
> "significant" was rather soft considering the above. Though if it's 
> just ITU-speak differences, why does the OIF liaison state it reflects 
> several years of work including testing? Any insight (alignment 
> mapping to CCAMP's work) which you or Lyndon can provide would be 
> helpful. The divergence is baffling to us.
>
> Deborah
>
> ------------------------------------------------------------------------
>
> *From:* Sadler, Jonathan B. [mailto:[email-masked]]
> *Sent:* Friday, July 21, 2006 11:34 AM
> *To:* Brungard, Deborah A, ALABS; [email-masked]
> *Cc:* Adrian Farrel
> *Subject:* RE: Proposed response to OIF on OSPF ENNI
>
> Hi Deborah and Adrian,
>
> I haven’t seen much discussion of the OIF E-NNI Routing document on 
> the CCAMP list. Can you tell me what parts of the document are 
> “significant modifications to the operation of OSPF”?
>
> Thanks,
>
> Jonathan Sadler
>
> ------------------------------------------------------------------------
>
> *From:* [email-masked] [mailto:[email-masked]] *On 
> Behalf Of *Brungard, Deborah A, ALABS
> *Sent:* Friday, July 21, 2006 9:38 AM
> *To:* [email-masked]
> *Cc:* Adrian Farrel
> *Subject:* Proposed response to OIF on OSPF ENNI
>
> Hi,
>
> We had a communication from OIF on their OSPF ENNI specification. You 
> can see the original files on http://www.olddog.co.uk/ccamp.htm. 
> 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’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
> ============================================================
>   

Delivery-date: Tue, 25 Jul 2006 21:15:56 +0000
Content-class: urn:content-classes:message
Subject: RE: Proposed response to OIF on OSPF ENNI
Date: Tue, 25 Jul 2006 17:10:42 -0400
From: "Ong, Lyndon" <[email-masked]>
To: <[email-masked]>
Cc: "Adrian Farrel" <[email-masked]>, <[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>, "Sadler, Jonathan B." <[email-masked]>, <[email-masked]>

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: [email-masked]
[mailto:[email-masked]]=20
Sent: Tuesday, July 25, 2006 11:11 AM
To: Ong, Lyndon
Cc: Adrian Farrel; [email-masked]; Brungard, Deborah A, ALABS;
Sadler, Jonathan B.; [email-masked]
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" <[email-masked]>
25/07/2006 20:01
=20
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     "Adrian Farrel" <[email-masked]>,=20
<[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>,
"Sadler, Jonathan B." <[email-masked]>,
<[email-masked]>
        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: [email-masked]
[mailto:[email-masked]]
Sent: Tuesday, July 25, 2006 10:54 AM
To: Ong, Lyndon
Cc: Adrian Farrel; [email-masked]; Brungard, Deborah A, ALABS;
Sadler, Jonathan B.; [email-masked]
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" <[email-masked]>
Sent by: [email-masked]
25/07/2006 18:55
=20
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Sadler,=20
Jonathan B." <[email-masked]>
        cc:     "Adrian Farrel" <[email-masked]>,=20
<[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>,
<[email-masked]>
        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: [email-masked]
[mailto:[email-masked]]=20
Sent: Tuesday, July 25, 2006 3:18 AM
To: Sadler, Jonathan B.; Ong, Lyndon
Cc: Adrian Farrel; [email-masked]; Brungard, Deborah A, ALABS;
[email-masked]
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." <[email-masked]> Sent by:
[email-masked]
24/07/2006 22:31
=20
        To:     "Brungard, Deborah A, ALABS" <[email-masked]>, "Ong,=20
Lyndon" <[email-masked]>, <[email-masked]>
        cc:     "Adrian Farrel" <[email-masked]>
        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:[email-masked]]
Sent: Monday, July 24, 2006 2:33 PM
To: Brungard, Deborah A, ALABS; Sadler, Jonathan B.; [email-masked]
Cc: Adrian Farrel
Subject: RE: Proposed response to OIF on OSPF ENNI
=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: [email-masked] [mailto:[email-masked]] On
Behalf Of Brungard, Deborah A, ALABS
Sent: Monday, July 24, 2006 12:15 PM
To: Sadler, Jonathan B.; [email-masked]
Cc: Adrian Farrel
Subject: RE: Proposed response to OIF on OSPF ENNI Hi Jonathan, (and
Lyndon),
=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:[email-masked]]
Sent: Friday, July 21, 2006 11:34 AM
To: Brungard, Deborah A, ALABS; [email-masked]
Cc: Adrian Farrel
Subject: RE: Proposed response to OIF on OSPF ENNI Hi Deborah and
Adrian,
=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: [email-masked] [mailto:[email-masked]] On
Behalf Of Brungard, Deborah A, ALABS
Sent: Friday, July 21, 2006 9:38 AM
To: [email-masked]
Cc: Adrian Farrel
Subject: Proposed response to OIF on OSPF ENNI
=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

Delivery-date: Tue, 25 Jul 2006 21:06:19 +0000
Content-class: urn:content-classes:message
Subject: RE: Proposed response to OIF on OSPF ENNI
Date: Tue, 25 Jul 2006 14:05:09 -0700
From: "Drake, John E" <[email-masked]>
To: <[email-masked]>

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:[email-masked]]=20
	Sent: Tuesday, July 25, 2006 9:29 AM
	To: Brungard, Deborah A, ALABS; Ong, Lyndon; [email-masked]
	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:[email-masked]]=20
	Sent: Tuesday, July 25, 2006 9:58 AM
	To: Sadler, Jonathan B.; Ong, Lyndon; [email-masked]
	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:[email-masked]]=20
	Sent: Monday, July 24, 2006 5:38 PM
	To: Brungard, Deborah A, ALABS; Ong, Lyndon; [email-masked]
	Cc: Adrian Farrel
	Subject: RE: Proposed response to OIF on OSPF ENNI

	Hi Deborah,

	=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:[email-masked]]=20
	Sent: Monday, July 24, 2006 4:31 PM
	To: Sadler, Jonathan B.; Ong, Lyndon; [email-masked]
	Cc: Adrian Farrel
	Subject: RE: Proposed response to OIF on OSPF ENNI

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

	Hi Deborah, Lyndon, et al,

	=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:[email-masked]]=20
	Sent: Monday, July 24, 2006 2:33 PM
	To: Brungard, Deborah A, ALABS; Sadler, Jonathan B.;
[email-masked]
	Cc: Adrian Farrel
	Subject: RE: Proposed response to OIF on OSPF ENNI

	=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: [email-masked] [mailto:[email-masked]]
On Behalf Of Brungard, Deborah A, ALABS
	Sent: Monday, July 24, 2006 12:15 PM
	To: Sadler, Jonathan B.; [email-masked]
	Cc: Adrian Farrel
	Subject: RE: Proposed response to OIF on OSPF ENNI

	Hi Jonathan, (and Lyndon),

	=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:[email-masked]]=20
	Sent: Friday, July 21, 2006 11:34 AM
	To: Brungard, Deborah A, ALABS; [email-masked]
	Cc: Adrian Farrel
	Subject: RE: Proposed response to OIF on OSPF ENNI

	Hi Deborah and Adrian,

	=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: [email-masked] [mailto:[email-masked]]
On Behalf Of Brungard, Deborah A, ALABS
	Sent: Friday, July 21, 2006 9:38 AM
	To: [email-masked]
	Cc: Adrian Farrel
	Subject: Proposed response to OIF on OSPF ENNI

	=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:[email-masked]] <BR><B>Sent:</B> Tuesday, July =
25,=20
  2006 9:29 AM<BR><B>To:</B> Brungard, Deborah A, ALABS; Ong, Lyndon;=20
  [email-masked]<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></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">3.<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">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></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">Regarding =
Topic=20
  1:<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">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></SPAN></FONT></P>
  <P class=3DMsoNormal=20
  style=3D"MARGIN-LEFT: 27pt; TEXT-INDENT: -9pt; mso-list: l1 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;=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">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></SPAN></FONT></P>
  <P class=3DMsoNormal=20
  style=3D"MARGIN-LEFT: 27pt; TEXT-INDENT: -9pt; mso-list: l1 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;=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">you will=20
  note the email you provided states it was notifying ITU of =
publication.=20
  Witness the specific text:<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal=20
  style=3D"MARGIN-BOTTOM: 0pt; MARGIN-LEFT: 0.5in; 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">&#8220;The =
CCAMP working=20
  group is pleased to inform you of the _<I><SPAN=20
  style=3D"FONT-STYLE: italic">publication</SPAN></I>_ of RFC=20
  4258"<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal style=3D"MARGIN-RIGHT: 461.25pt"><FONT =
face=3DArial color=3Dnavy=20
  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">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></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">To=20
  remove any potential receiver confusion what this statement means, let =
me put=20
  in another way:<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">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></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">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></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">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></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">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></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=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></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">Regarding =
Topic=20
  2:<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">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></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">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></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">Regarding =
Topic=20
  3:<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">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></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">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></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">I look =
forward to=20
  reviewing the new liaison text.<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">=20
  Brungard, Deborah A, ALABS [mailto:[email-masked]] <BR><B><SPAN=20
  style=3D"FONT-WEIGHT: bold">Sent:</SPAN></B> Tuesday, July 25, 2006 =
9:58=20
  AM<BR><B><SPAN style=3D"FONT-WEIGHT: bold">To:</SPAN></B> Sadler, =
Jonathan B.;=20
  Ong, Lyndon; [email-masked]<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
  Jonathan,</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">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:</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"><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></SPAN></FONT><o:p></o:p></P>
  <P class=3DMsoNormal><FONT face=3D"Times New Roman" color=3Dnavy =
size=3D3><SPAN=20
  style=3D"FONT-SIZE: 12pt; COLOR: =
navy"><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">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></FONT><FONT =
face=3DArial=20
  color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"> =
</SPAN></FONT><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></FONT><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=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">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></FONT><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; 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>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><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></FONT><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>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
Arial">"Significant" Thanks=20
  on the confusion;-)</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">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"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <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 style=3D"MARGIN-BOTTOM: 12pt"><B><FONT =
face=3DTahoma=20
  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:[email-masked]] <BR><B><SPAN=20
  style=3D"FONT-WEIGHT: bold">Sent:</SPAN></B> Monday, July 24, 2006 =
5:38=20
  PM<BR><B><SPAN style=3D"FONT-WEIGHT: bold">To:</SPAN></B> Brungard, =
Deborah A,=20
  ALABS; Ong, Lyndon; [email-masked]<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>
  <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">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></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">=20
  Brungard, Deborah A, ALABS [mailto:[email-masked]] <BR><B><SPAN=20
  style=3D"FONT-WEIGHT: bold">Sent:</SPAN></B> Monday, July 24, 2006 =
4:31=20
  PM<BR><B><SPAN style=3D"FONT-WEIGHT: bold">To:</SPAN></B> Sadler, =
Jonathan B.;=20
  Ong, Lyndon; [email-masked]<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
  Jonathan,</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">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.</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">Thanks,</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">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"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <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 style=3D"MARGIN-BOTTOM: 12pt"><B><FONT =
face=3DTahoma=20
  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:[email-masked]] <BR><B><SPAN=20
  style=3D"FONT-WEIGHT: bold">Sent:</SPAN></B> Monday, July 24, 2006 =
4:32=20
  PM<BR><B><SPAN style=3D"FONT-WEIGHT: bold">To:</SPAN></B> Brungard, =
Deborah A,=20
  ALABS; Ong, Lyndon; [email-masked]<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>
  <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,=20
  et 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 =

  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:[email-masked]] <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.; [email-masked]<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 </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">conclusions =
are no=20
  different.</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 in fact define any standard extensions to the protocols, and =
points to=20
  future work</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">in IETF and =
ITU to=20
  provide these.&nbsp; Therefore I cannot understand where you say "new=20
  extensions to</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">OSPF are =
specified"=20
  and "none...align with the CCAMP's GMPLS-ASON work".&nbsp;=20
  </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>
  <DIV>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">I think =
we're=20
  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=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 style=3D"MARGIN-BOTTOM: 12pt"><B><FONT =
face=3DTahoma=20
  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
  [email-masked] [mailto:[email-masked]] <B><SPAN=20
  style=3D"FONT-WEIGHT: bold">On Behalf Of </SPAN></B>Brungard, Deborah =
A,=20
  ALABS<BR><B><SPAN style=3D"FONT-WEIGHT: bold">Sent:</SPAN></B> Monday, =
July 24,=20
  2006 12:15 PM<BR><B><SPAN style=3D"FONT-WEIGHT: bold">To:</SPAN></B> =
Sadler,=20
  Jonathan B.; [email-masked]<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>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Hi =
Jonathan, (and=20
  Lyndon),</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">Thanks to =
both of you=20
  for responding.</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">"Significant" was=20
  referencing:</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">-=20
  supports&nbsp;a&nbsp;(new) hierarchical OSPF=20
model</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">-&nbsp;supports&nbsp;inter-domain=20
  (inter-carrier) OSPF (not supported by today's=20
  OSPF)</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">- =
identifies=20
  namespace issues with GMPLS OSPF which do not exist, and proposes =
extensions=20
  to "fix"</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">- new =
extensions to=20
  OSPF are specified</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">- none of =
the=20
  proposed extensions align with CCAMP's GMPLS-ASON=20
  work</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">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.</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">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=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=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 style=3D"MARGIN-BOTTOM: 12pt"><B><FONT =
face=3DTahoma=20
  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:[email-masked]] <BR><B><SPAN=20
  style=3D"FONT-WEIGHT: bold">Sent:</SPAN></B> Friday, July 21, 2006 =
11:34=20
  AM<BR><B><SPAN style=3D"FONT-WEIGHT: bold">To:</SPAN></B> Brungard, =
Deborah A,=20
  ALABS; [email-masked]<BR><B><SPAN style=3D"FONT-WEIGHT: =
bold">Cc:</SPAN></B>=20
  Adrian Farrel<BR><B><SPAN style=3D"FONT-WEIGHT: =
bold">Subject:</SPAN></B> RE:=20
  Proposed response to OIF on OSPF ENNI</SPAN></FONT><o:p></o:p></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Hi Deborah =
and=20
  Adrian,<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">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></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">Thanks,<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">=20
  [email-masked] [mailto:[email-masked]] <B><SPAN=20
  style=3D"FONT-WEIGHT: bold">On Behalf Of </SPAN></B>Brungard, Deborah =
A,=20
  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
  [email-masked]<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=20
  communication from OIF on their OSPF ENNI specification. You can see =
the=20
  original files on </SPAN></FONT><A=20
  href=3D"http://www.olddog.co.uk/ccamp.htm"><FONT face=3DArial =
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=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></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=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></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=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></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=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=3D"Times New Roman" size=3D3><SPAN=20
  style=3D"FONT-SIZE: 12pt">Adrian Farrel</SPAN></FONT></st1:PersonName> =
and=20
  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></BLOCKQUOTE></BODY></HTML>

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

Delivery-date: Tue, 25 Jul 2006 20:33:20 +0000
Content-class: urn:content-classes:message
Subject: RE: Proposed response to OIF on OSPF ENNI
Date: Tue, 25 Jul 2006 15:29:08 -0500
From: "Sadler, Jonathan B." <[email-masked]>
To: "Brungard, Deborah A, ALABS" <[email-masked]>, "Ong, Lyndon" <[email-masked]>, <[email-masked]>
Cc: "Adrian Farrel" <[email-masked]>

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:[email-masked]]=20
Sent: Tuesday, July 25, 2006 2:04 PM
To: Sadler, Jonathan B.; Ong, Lyndon; [email-masked]
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:[email-masked]]=20
Sent: Tuesday, July 25, 2006 12:29 PM
To: Brungard, Deborah A, ALABS; Ong, Lyndon; [email-masked]
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:[email-masked]]=20
Sent: Tuesday, July 25, 2006 9:58 AM
To: Sadler, Jonathan B.; Ong, Lyndon; [email-masked]
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:[email-masked]]=20
Sent: Monday, July 24, 2006 5:38 PM
To: Brungard, Deborah A, ALABS; Ong, Lyndon; [email-masked]
Cc: Adrian Farrel
Subject: RE: Proposed response to OIF on OSPF ENNI

Hi Deborah,

=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:[email-masked]]=20
Sent: Monday, July 24, 2006 4:31 PM
To: Sadler, Jonathan B.; Ong, Lyndon; [email-masked]
Cc: Adrian Farrel
Subject: RE: Proposed response to OIF on OSPF ENNI

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

Hi Deborah, Lyndon, et al,

=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:[email-masked]]=20
Sent: Monday, July 24, 2006 2:33 PM
To: Brungard, Deborah A, ALABS; Sadler, Jonathan B.; [email-masked]
Cc: Adrian Farrel
Subject: RE: Proposed response to OIF on OSPF ENNI

=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: [email-masked] [mailto:[email-masked]] On
Behalf Of Brungard, Deborah A, ALABS
Sent: Monday, July 24, 2006 12:15 PM
To: Sadler, Jonathan B.; [email-masked]
Cc: Adrian Farrel
Subject: RE: Proposed response to OIF on OSPF ENNI

Hi Jonathan, (and Lyndon),

=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:[email-masked]]=20
Sent: Friday, July 21, 2006 11:34 AM
To: Brungard, Deborah A, ALABS; [email-masked]
Cc: Adrian Farrel
Subject: RE: Proposed response to OIF on OSPF ENNI

Hi Deborah and Adrian,

=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: [email-masked] [mailto:[email-masked]] On
Behalf Of Brungard, Deborah A, ALABS
Sent: Friday, July 21, 2006 9:38 AM
To: [email-masked]
Cc: Adrian Farrel
Subject: Proposed response to OIF on OSPF ENNI

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>And if you look at the response from t=
he
ITU (the other liaison you include </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/file151.doc">https:/=
/datatracker.ietf.org/documents/LIAISON/file151.doc</a>)
</span></font><font size=3D2 color=3Dnavy face=3DArial><span style=3D'font-=
size:10.0pt;
font-family:Arial;color:navy'>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></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 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:[email-masked]] <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; [email-masked]<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>

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

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Lyndon has already responded saying he
believes there is no mis-alignment. Thanks Lyndon. We will go with that.</s=
pan></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'>=
 Sadler,
Jonathan B. [mailto:[email-masked]] <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Tuesday, July 25, 2006=
 12:29
PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Brungard, Deborah A, ALA=
BS;
Ong, Lyndon; [email-masked]<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>

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

<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'>=
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></span></font></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>

<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
note the email you provided states it was notifying ITU of publication. Wit=
ness
the specific text:<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:.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><span style=3D'font-size:10.0pt;font-family:Arial;color:navy'>=
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></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 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>

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

<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'>=
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></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'>=
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></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'>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:[email-masked]] <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; [email-masked]<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>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>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></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/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>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>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.</span></f=
ont><font
size=3D2 face=3DArial><span style=3D'font-size:10.0pt;font-family:Arial'><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=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>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.</span></font><font siz=
e=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=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:[email-masked]] <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; [email-masked]<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>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>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></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:[email-masked]] <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; [email-masked]<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>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>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.</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'>=
 Sadler, Jonathan
B=2E [mailto:[email-masked]] <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; [email-masked]<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:[email-masked]] <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.; [email-masked]<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>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>node, hence extensions are felt to be
required - and are proposed in the eval solutions draft. The </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'>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'>=
 [email-masked]
[mailto:[email-masked]] <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.;
[email-masked]<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>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>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.</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'>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. [mailto:[email-masked]] <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;
[email-masked]<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>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>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></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'>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'>
[email-masked] [mailto:[email-masked]] <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> [email-masked]<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>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>We had a communication from OIF on the=
ir
OSPF ENNI specification. You can see the original files on </span></font><a
href=3D"http://www.olddog.co.uk/ccamp.htm"><font size=3D2 face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>http://www.olddog.co.uk/ccamp.=
htm</span></font></a><font
size=3D2 color=3Dblue face=3DArial><span style=3D'font-size:10.0pt;font-fam=
ily:Arial;
color:blue'>. 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.</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>

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

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>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></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'>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></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'>Specific comments include:<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.25in;text-indent:-.25in'><font s=
ize=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>1.</span></font><=
font
size=3D1><span style=3D'font-size:7.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </s=
pan></font>What
is the intent of this document? Will it be published as an Implementation
Agreement (IA)?<br>
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>

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

<p class=3DMsoNormal style=3D'margin-left:.25in;text-indent:-.25in'><font s=
ize=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>3.</span></font><=
font
size=3D1><span style=3D'font-size:7.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </s=
pan></font>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>

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

Delivery-date: Tue, 25 Jul 2006 19:59:56 +0000
Content-class: urn:content-classes:message
Subject: RE: Proposed response to OIF on OSPF ENNI
Date: Tue, 25 Jul 2006 14:58:34 -0500
From: "Brungard, Deborah A, ALABS" <[email-masked]>
To: "Tomohiro Otani" <[email-masked]>
Cc: <[email-masked]>, "Adrian Farrel" <[email-masked]>

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

Hi Deborah,

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

Delivery-date: Tue, 25 Jul 2006 19:05:03 +0000
Content-class: urn:content-classes:message
Subject: RE: Proposed response to OIF on OSPF ENNI
Date: Tue, 25 Jul 2006 14:03:51 -0500
From: "Brungard, Deborah A, ALABS" <[email-masked]>
To: "Sadler, Jonathan B." <[email-masked]>, "Ong, Lyndon" <[email-masked]>, <[email-masked]>
Cc: "Adrian Farrel" <[email-masked]>

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:[email-masked]]=20
Sent: Tuesday, July 25, 2006 12:29 PM
To: Brungard, Deborah A, ALABS; Ong, Lyndon; [email-masked]
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:[email-masked]]=20
Sent: Tuesday, July 25, 2006 9:58 AM
To: Sadler, Jonathan B.; Ong, Lyndon; [email-masked]
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:[email-masked]]=20
Sent: Monday, July 24, 2006 5:38 PM
To: Brungard, Deborah A, ALABS; Ong, Lyndon; [email-masked]
Cc: Adrian Farrel
Subject: RE: Proposed response to OIF on OSPF ENNI

Hi Deborah,

=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:[email-masked]]=20
Sent: Monday, July 24, 2006 4:31 PM
To: Sadler, Jonathan B.; Ong, Lyndon; [email-masked]
Cc: Adrian Farrel
Subject: RE: Proposed response to OIF on OSPF ENNI

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

Hi Deborah, Lyndon, et al,

=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:[email-masked]]=20
Sent: Monday, July 24, 2006 2:33 PM
To: Brungard, Deborah A, ALABS; Sadler, Jonathan B.; [email-masked]
Cc: Adrian Farrel
Subject: RE: Proposed response to OIF on OSPF ENNI

=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: [email-masked] [mailto:[email-masked]] On
Behalf Of Brungard, Deborah A, ALABS
Sent: Monday, July 24, 2006 12:15 PM
To: Sadler, Jonathan B.; [email-masked]
Cc: Adrian Farrel
Subject: RE: Proposed response to OIF on OSPF ENNI

Hi Jonathan, (and Lyndon),

=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:[email-masked]]=20
Sent: Friday, July 21, 2006 11:34 AM
To: Brungard, Deborah A, ALABS; [email-masked]
Cc: Adrian Farrel
Subject: RE: Proposed response to OIF on OSPF ENNI

Hi Deborah and Adrian,

=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: [email-masked] [mailto:[email-masked]] On
Behalf Of Brungard, Deborah A, ALABS
Sent: Friday, July 21, 2006 9:38 AM
To: [email-masked]
Cc: Adrian Farrel
Subject: Proposed response to OIF on OSPF ENNI

=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.</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>The current liaison was scoped as requirements =
which is why=20
we are trying to understand it.</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>Lyndon has already responded saying he believes =
there is no=20
mis-alignment. Thanks Lyndon. We will go with that.</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>Thanks,</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D327550218-25072006><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:[email-masked]] <BR><B>Sent:</B> Tuesday, July 25, =
2006=20
12:29 PM<BR><B>To:</B> Brungard, Deborah A, ALABS; Ong, Lyndon;=20
[email-masked]<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=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 =

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></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">3.<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">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></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">Regarding =
Topic=20
1:<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">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></SPAN></FONT></P>
<P class=3DMsoNormal=20
style=3D"MARGIN-LEFT: 27pt; TEXT-INDENT: -9pt; mso-list: l1 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;=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">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></SPAN></FONT></P>
<P class=3DMsoNormal=20
style=3D"MARGIN-LEFT: 27pt; TEXT-INDENT: -9pt; mso-list: l1 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;=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">you will=20
note the email you provided states it was notifying ITU of publication. =
Witness=20
the specific text:<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal=20
style=3D"MARGIN-BOTTOM: 0pt; MARGIN-LEFT: 0.5in; 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">&#8220;The =
CCAMP working=20
group is pleased to inform you of the _<I><SPAN=20
style=3D"FONT-STYLE: italic">publication</SPAN></I>_ of RFC=20
4258"<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal style=3D"MARGIN-RIGHT: 461.25pt"><FONT face=3DArial =
color=3Dnavy=20
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">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></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">To remove=20
any potential receiver confusion what this statement means, let me put =
in=20
another way:<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">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></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">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></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">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></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">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></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">Regarding =
Topic=20
2:<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">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></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">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></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">Regarding =
Topic=20
3:<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">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></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">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></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">I look =
forward to=20
reviewing the new liaison text.<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><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:[email-masked]] <BR><B><SPAN=20
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.;=20
Ong, Lyndon; [email-masked]<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
Jonathan,</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">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:</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"><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></SPAN></FONT><o:p></o:p></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" color=3Dnavy =
size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt; COLOR: =
navy"><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">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></FONT><FONT =
face=3DArial=20
color=3Dnavy size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"> =
</SPAN></FONT><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></FONT><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=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">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></FONT><FONT face=3DArial size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; 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>
<P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><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></FONT><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>
<P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">"Significant" =
Thanks on=20
the confusion;-)</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">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"><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"> Sadler,=20
Jonathan B. [mailto:[email-masked]] <BR><B><SPAN=20
style=3D"FONT-WEIGHT: bold">Sent:</SPAN></B> Monday, July 24, 2006 5:38=20
PM<BR><B><SPAN style=3D"FONT-WEIGHT: bold">To:</SPAN></B> Brungard, =
Deborah A,=20
ALABS; Ong, Lyndon; [email-masked]<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>
<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">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></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><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:[email-masked]] <BR><B><SPAN=20
style=3D"FONT-WEIGHT: bold">Sent:</SPAN></B> Monday, July 24, 2006 4:31=20
PM<BR><B><SPAN style=3D"FONT-WEIGHT: bold">To:</SPAN></B> Sadler, =
Jonathan B.;=20
Ong, Lyndon; [email-masked]<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
Jonathan,</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">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.</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">Thanks,</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">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"><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"> Sadler,=20
Jonathan B. [mailto:[email-masked]] <BR><B><SPAN=20
style=3D"FONT-WEIGHT: bold">Sent:</SPAN></B> Monday, July 24, 2006 4:32=20
PM<BR><B><SPAN style=3D"FONT-WEIGHT: bold">To:</SPAN></B> Brungard, =
Deborah A,=20
ALABS; Ong, Lyndon; [email-masked]<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>
<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 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><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:[email-masked]] <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.; [email-masked]<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 and=20
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 ASON,=20
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 no=20
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 IETF=20
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 not=20
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=20
are felt to be required - and are proposed in the eval solutions draft. =
The=20
</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">conclusions =
are no=20
different.</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 in fact define any standard extensions to the protocols, and points =
to=20
future work</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">in IETF and =
ITU to=20
provide these.&nbsp; Therefore I cannot understand where you say "new =
extensions=20
to</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">OSPF are =
specified" and=20
"none...align with the CCAMP's GMPLS-ASON work".&nbsp;=20
</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>
<DIV>
<P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><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
[email-masked] [mailto:[email-masked]] <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> Monday, =
July 24,=20
2006 12:15 PM<BR><B><SPAN style=3D"FONT-WEIGHT: bold">To:</SPAN></B> =
Sadler,=20
Jonathan B.; [email-masked]<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>
<P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Hi Jonathan, =
(and=20
Lyndon),</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">Thanks to =
both of you=20
for responding.</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">"Significant" =
was=20
referencing:</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">-=20
supports&nbsp;a&nbsp;(new) hierarchical OSPF =
model</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">-&nbsp;supports&nbsp;inter-domain=20
(inter-carrier) OSPF (not supported by today's=20
OSPF)</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">- identifies =
namespace=20
issues with GMPLS OSPF which do not exist, and proposes extensions to=20
"fix"</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">- new =
extensions to=20
OSPF are specified</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">- none of the =
proposed=20
extensions align with CCAMP's GMPLS-ASON =
work</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">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.</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">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=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"> Sadler,=20
Jonathan B. [mailto:[email-masked]] <BR><B><SPAN=20
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,=20
ALABS; [email-masked]<BR><B><SPAN style=3D"FONT-WEIGHT: =
bold">Cc:</SPAN></B>=20
Adrian Farrel<BR><B><SPAN style=3D"FONT-WEIGHT: =
bold">Subject:</SPAN></B> RE:=20
Proposed response to OIF on OSPF ENNI</SPAN></FONT><o:p></o:p></P>
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Hi Deborah =
and=20
Adrian,<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">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></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">Thanks,<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><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
[email-masked] [mailto:[email-masked]] <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
[email-masked]<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--

Delivery-date: Tue, 25 Jul 2006 18:11:52 +0000
To: "Ong, Lyndon" <[email-masked]>
Cc: "Adrian Farrel" <[email-masked]>, [email-masked], "Brungard, Deborah A, ALABS" <[email-masked]>, "Sadler, Jonathan B." <[email-masked]>, [email-masked]
Subject: RE: Proposed response to OIF on OSPF ENNI
From: [email-masked]
Date: Tue, 25 Jul 2006 20:11:16 +0200

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" <[email-masked]>
25/07/2006 20:01
 
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     "Adrian Farrel" <[email-masked]>, 
<[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>, 
"Sadler, Jonathan B." <[email-masked]>, 
<[email-masked]>
        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: [email-masked]
[mailto:[email-masked]] 
Sent: Tuesday, July 25, 2006 10:54 AM
To: Ong, Lyndon
Cc: Adrian Farrel; [email-masked]; Brungard, Deborah A, ALABS;
Sadler, Jonathan B.; [email-masked]
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" <[email-masked]>
Sent by: [email-masked]
25/07/2006 18:55
 
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Sadler, 
Jonathan B." <[email-masked]>
        cc:     "Adrian Farrel" <[email-masked]>, 
<[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>, 
<[email-masked]>
        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: [email-masked]
[mailto:[email-masked]] 
Sent: Tuesday, July 25, 2006 3:18 AM
To: Sadler, Jonathan B.; Ong, Lyndon
Cc: Adrian Farrel; [email-masked]; Brungard, Deborah A, ALABS;
[email-masked]
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." <[email-masked]> Sent by:
[email-masked]
24/07/2006 22:31
 
        To:     "Brungard, Deborah A, ALABS" <[email-masked]>, "Ong, 
Lyndon" <[email-masked]>, <[email-masked]>
        cc:     "Adrian Farrel" <[email-masked]>
        Subject:        RE: Proposed response to OIF on OSPF ENNI

Hi Deborah, Lyndon, et al,
 
Some additional comments:
 - The hierarchical model discussed in the draft IA liaised may be
supported without any modifications to OSPF.  As discussed in earlier
emails, it can be implemented solely through the import/export of
information described in Appendix I of G.7715.
 - The draft IA also recognizes namespace issues exist between Router ID
and the IP Address that messages are sent to (ITU calls this the RC PC
SCN address).  This issue is also discussed in
draft-ietf-ccamp-gmpls-addressing.
 
Given that:
-          CCAMP has a milestone to publish an ASON routing solution by 
Nov 2006, 
-          CCAMP didn't have at the time this was liaised (doesn't have 
today?) a working group document, and
-          the draft IA has been successfully implemented by more than a

dozen vendors and interop-tested many times, I would expect that we
should be looking at this as experience/text that could be leveraged...
"Running code..." and all that...
 
Regards,
 
Jonathan Sadler

From: Ong, Lyndon [mailto:[email-masked]]
Sent: Monday, July 24, 2006 2:33 PM
To: Brungard, Deborah A, ALABS; Sadler, Jonathan B.; [email-masked]
Cc: Adrian Farrel
Subject: RE: Proposed response to OIF on OSPF ENNI
 
Hi Deborah,
 
Here's what I would say is in and not in the OIF document:
 
-- G.7715, G.7715.1 and the IETF eval and solutions draft all identify a
need to support hierarchical routing areas for ASON, I am perplexed as
to why this seems to be viewed as a new feature.
 
-- the document does not specify the domain of usage and leaves this to
the carrier.  This is no different from G.7715.1 and IETF drafts that do
not explicitly state whether they are used for intra- or inter-domain
interfaces.
 
-- GMPLS OSPF does not support a 1:N or N:1 relationship between routing
controller and transport node, hence extensions are felt to be required
- and are proposed in the eval solutions draft. The conclusions are no
different.
 
-- the document does not in fact define any standard extensions to the
protocols, and points to future work in IETF and ITU to provide these.
Therefore I cannot understand where you say "new extensions to OSPF are
specified" and "none...align with the CCAMP's GMPLS-ASON work". 
 
I think we're experiencing a significant miscommunication...
 
Cheers,
 
Lyndon

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Brungard, Deborah A, ALABS
Sent: Monday, July 24, 2006 12:15 PM
To: Sadler, Jonathan B.; [email-masked]
Cc: Adrian Farrel
Subject: RE: Proposed response to OIF on OSPF ENNI Hi Jonathan, (and
Lyndon),
 
Thanks to both of you for responding.
 
"Significant" was referencing:
 
- supports a (new) hierarchical OSPF model
- supports inter-domain (inter-carrier) OSPF (not supported by today's
OSPF)
- identifies namespace issues with GMPLS OSPF which do not exist, and
proposes extensions to "fix"
- new extensions to OSPF are specified
- none of the proposed extensions align with CCAMP's GMPLS-ASON work
 
Did you have another adjective to suggest? We were thinking
"significant" 
was rather soft considering the above. Though if it's just ITU-speak
differences, why does the OIF liaison state it reflects several years of
work including testing? Any insight (alignment mapping to CCAMP's work)
which you or Lyndon can provide would be helpful. The divergence is
baffling to us.
 
Deborah

From: Sadler, Jonathan B. [mailto:[email-masked]]
Sent: Friday, July 21, 2006 11:34 AM
To: Brungard, Deborah A, ALABS; [email-masked]
Cc: Adrian Farrel
Subject: RE: Proposed response to OIF on OSPF ENNI Hi Deborah and
Adrian,
 
I haven't seen much discussion of the OIF E-NNI Routing document on the
CCAMP list.  Can you tell me what parts of the document are "significant
modifications to the operation of OSPF"?
 
Thanks,
 
Jonathan Sadler

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Brungard, Deborah A, ALABS
Sent: Friday, July 21, 2006 9:38 AM
To: [email-masked]
Cc: Adrian Farrel
Subject: Proposed response to OIF on OSPF ENNI
 
Hi,
 
We had a communication from OIF on their OSPF ENNI specification. You
can see the original files on http://www.olddog.co.uk/ccamp.htm. 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
============================================================

Delivery-date: Tue, 25 Jul 2006 18:07:56 +0000
To: "Sadler, Jonathan B." <[email-masked]>
Cc: "Adrian Farrel" <[email-masked]>, [email-masked], "Brungard, Deborah A, ALABS" <[email-masked]>, "Ong, Lyndon" <[email-masked]>, [email-masked]
Subject: RE: Proposed response to OIF on OSPF ENNI
From: [email-masked]
Date: Tue, 25 Jul 2006 20:07:18 +0200

Delivery-date: Tue, 25 Jul 2006 18:02:02 +0000
Content-class: urn:content-classes:message
Subject: RE: Proposed response to OIF on OSPF ENNI
Date: Tue, 25 Jul 2006 14:01:14 -0400
From: "Ong, Lyndon" <[email-masked]>
To: <[email-masked]>
Cc: "Adrian Farrel" <[email-masked]>, <[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>, "Sadler, Jonathan B." <[email-masked]>, <[email-masked]>

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: [email-masked]
[mailto:[email-masked]]=20
Sent: Tuesday, July 25, 2006 10:54 AM
To: Ong, Lyndon
Cc: Adrian Farrel; [email-masked]; Brungard, Deborah A, ALABS;
Sadler, Jonathan B.; [email-masked]
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" <[email-masked]>
Sent by: [email-masked]
25/07/2006 18:55
=20
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Sadler,=20
Jonathan B." <[email-masked]>
        cc:     "Adrian Farrel" <[email-masked]>,=20
<[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>,=20
<[email-masked]>
        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: [email-masked]
[mailto:[email-masked]]=20
Sent: Tuesday, July 25, 2006 3:18 AM
To: Sadler, Jonathan B.; Ong, Lyndon
Cc: Adrian Farrel; [email-masked]; Brungard, Deborah A, ALABS;
[email-masked]
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." <[email-masked]> Sent by:
[email-masked]
24/07/2006 22:31
=20
        To:     "Brungard, Deborah A, ALABS" <[email-masked]>, "Ong,=20
Lyndon" <[email-masked]>, <[email-masked]>
        cc:     "Adrian Farrel" <[email-masked]>
        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:[email-masked]]
Sent: Monday, July 24, 2006 2:33 PM
To: Brungard, Deborah A, ALABS; Sadler, Jonathan B.; [email-masked]
Cc: Adrian Farrel
Subject: RE: Proposed response to OIF on OSPF ENNI
=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: [email-masked] [mailto:[email-masked]] On
Behalf Of Brungard, Deborah A, ALABS
Sent: Monday, July 24, 2006 12:15 PM
To: Sadler, Jonathan B.; [email-masked]
Cc: Adrian Farrel
Subject: RE: Proposed response to OIF on OSPF ENNI Hi Jonathan, (and
Lyndon),
=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:[email-masked]]
Sent: Friday, July 21, 2006 11:34 AM
To: Brungard, Deborah A, ALABS; [email-masked]
Cc: Adrian Farrel
Subject: RE: Proposed response to OIF on OSPF ENNI Hi Deborah and
Adrian,
=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: [email-masked] [mailto:[email-masked]] On
Behalf Of Brungard, Deborah A, ALABS
Sent: Friday, July 21, 2006 9:38 AM
To: [email-masked]
Cc: Adrian Farrel
Subject: Proposed response to OIF on OSPF ENNI
=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

Delivery-date: Tue, 25 Jul 2006 17:55:36 +0000
To: "Ong, Lyndon" <[email-masked]>
Cc: "Adrian Farrel" <[email-masked]>, [email-masked], "Brungard, Deborah A, ALABS" <[email-masked]>, "Sadler, Jonathan B." <[email-masked]>, [email-masked]
Subject: RE: Proposed response to OIF on OSPF ENNI
From: [email-masked]
Date: Tue, 25 Jul 2006 19:54:23 +0200

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" <[email-masked]>
Sent by: [email-masked]
25/07/2006 18:55
 
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Sadler, 
Jonathan B." <[email-masked]>
        cc:     "Adrian Farrel" <[email-masked]>, 
<[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>, 
<[email-masked]>
        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: [email-masked]
[mailto:[email-masked]] 
Sent: Tuesday, July 25, 2006 3:18 AM
To: Sadler, Jonathan B.; Ong, Lyndon
Cc: Adrian Farrel; [email-masked]; Brungard, Deborah A, ALABS;
[email-masked]
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." <[email-masked]> Sent by:
[email-masked]
24/07/2006 22:31
 
        To:     "Brungard, Deborah A, ALABS" <[email-masked]>, "Ong, 
Lyndon" <[email-masked]>, <[email-masked]>
        cc:     "Adrian Farrel" <[email-masked]>
        Subject:        RE: Proposed response to OIF on OSPF ENNI

Hi Deborah, Lyndon, et al,
 
Some additional comments:
 - The hierarchical model discussed in the draft IA liaised may be
supported without any modifications to OSPF.  As discussed in earlier
emails, it can be implemented solely through the import/export of
information described in Appendix I of G.7715.
 - The draft IA also recognizes namespace issues exist between Router ID
and the IP Address that messages are sent to (ITU calls this the RC PC
SCN address).  This issue is also discussed in
draft-ietf-ccamp-gmpls-addressing.
 
Given that:
-          CCAMP has a milestone to publish an ASON routing solution by 
Nov 2006, 
-          CCAMP didn't have at the time this was liaised (doesn't have 
today?) a working group document, and
-          the draft IA has been successfully implemented by more than a

dozen vendors and interop-tested many times, I would expect that we
should be looking at this as experience/text that could be leveraged...
"Running code..." and all that...
 
Regards,
 
Jonathan Sadler

From: Ong, Lyndon [mailto:[email-masked]]
Sent: Monday, July 24, 2006 2:33 PM
To: Brungard, Deborah A, ALABS; Sadler, Jonathan B.; [email-masked]
Cc: Adrian Farrel
Subject: RE: Proposed response to OIF on OSPF ENNI
 
Hi Deborah,
 
Here's what I would say is in and not in the OIF document:
 
-- G.7715, G.7715.1 and the IETF eval and solutions draft all identify a
need to support hierarchical routing areas for ASON, I am perplexed as
to why this seems to be viewed as a new feature.
 
-- the document does not specify the domain of usage and leaves this to
the carrier.  This is no different from G.7715.1 and IETF drafts that do
not explicitly state whether they are used for intra- or inter-domain
interfaces.
 
-- GMPLS OSPF does not support a 1:N or N:1 relationship between routing
controller and transport node, hence extensions are felt to be required
- and are proposed in the eval solutions draft. The conclusions are no
different.
 
-- the document does not in fact define any standard extensions to the
protocols, and points to future work in IETF and ITU to provide these.
Therefore I cannot understand where you say "new extensions to OSPF are
specified" and "none...align with the CCAMP's GMPLS-ASON work". 
 
I think we're experiencing a significant miscommunication...
 
Cheers,
 
Lyndon

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Brungard, Deborah A, ALABS
Sent: Monday, July 24, 2006 12:15 PM
To: Sadler, Jonathan B.; [email-masked]
Cc: Adrian Farrel
Subject: RE: Proposed response to OIF on OSPF ENNI Hi Jonathan, (and
Lyndon),
 
Thanks to both of you for responding.
 
"Significant" was referencing:
 
- supports a (new) hierarchical OSPF model
- supports inter-domain (inter-carrier) OSPF (not supported by today's
OSPF)
- identifies namespace issues with GMPLS OSPF which do not exist, and
proposes extensions to "fix"
- new extensions to OSPF are specified
- none of the proposed extensions align with CCAMP's GMPLS-ASON work
 
Did you have another adjective to suggest? We were thinking
"significant" 
was rather soft considering the above. Though if it's just ITU-speak
differences, why does the OIF liaison state it reflects several years of
work including testing? Any insight (alignment mapping to CCAMP's work)
which you or Lyndon can provide would be helpful. The divergence is
baffling to us.
 
Deborah

From: Sadler, Jonathan B. [mailto:[email-masked]]
Sent: Friday, July 21, 2006 11:34 AM
To: Brungard, Deborah A, ALABS; [email-masked]
Cc: Adrian Farrel
Subject: RE: Proposed response to OIF on OSPF ENNI Hi Deborah and
Adrian,
 
I haven't seen much discussion of the OIF E-NNI Routing document on the
CCAMP list.  Can you tell me what parts of the document are "significant
modifications to the operation of OSPF"?
 
Thanks,
 
Jonathan Sadler

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Brungard, Deborah A, ALABS
Sent: Friday, July 21, 2006 9:38 AM
To: [email-masked]
Cc: Adrian Farrel
Subject: Proposed response to OIF on OSPF ENNI
 
Hi,
 
We had a communication from OIF on their OSPF ENNI specification. You
can see the original files on http://www.olddog.co.uk/ccamp.htm. 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
============================================================

Delivery-date: Tue, 25 Jul 2006 17:18:31 +0000
To: "Ong, Lyndon" <[email-masked]>
Cc: "Adrian Farrel" <[email-masked]>, [email-masked], "Brungard, Deborah A, ALABS" <[email-masked]>, "Sadler, Jonathan B." <[email-masked]>, [email-masked]
Subject: RE: Proposed response to OIF on OSPF ENNI
From: [email-masked]
Date: Tue, 25 Jul 2006 19:16:54 +0200

Delivery-date: Tue, 25 Jul 2006 16:56:57 +0000
Content-class: urn:content-classes:message
Subject: RE: Proposed response to OIF on OSPF ENNI
Date: Tue, 25 Jul 2006 12:55:35 -0400
From: "Ong, Lyndon" <[email-masked]>
To: <[email-masked]>, "Sadler, Jonathan B." <[email-masked]>
Cc: "Adrian Farrel" <[email-masked]>, <[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>, <[email-masked]>

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: [email-masked]
[mailto:[email-masked]]=20
Sent: Tuesday, July 25, 2006 3:18 AM
To: Sadler, Jonathan B.; Ong, Lyndon
Cc: Adrian Farrel; [email-masked]; Brungard, Deborah A, ALABS;
[email-masked]
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." <[email-masked]> Sent by:
[email-masked]
24/07/2006 22:31
=20
        To:     "Brungard, Deborah A, ALABS" <[email-masked]>, "Ong,=20
Lyndon" <[email-masked]>, <[email-masked]>
        cc:     "Adrian Farrel" <[email-masked]>
        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:[email-masked]]
Sent: Monday, July 24, 2006 2:33 PM
To: Brungard, Deborah A, ALABS; Sadler, Jonathan B.; [email-masked]
Cc: Adrian Farrel
Subject: RE: Proposed response to OIF on OSPF ENNI
=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: [email-masked] [mailto:[email-masked]] On
Behalf Of Brungard, Deborah A, ALABS
Sent: Monday, July 24, 2006 12:15 PM
To: Sadler, Jonathan B.; [email-masked]
Cc: Adrian Farrel
Subject: RE: Proposed response to OIF on OSPF ENNI Hi Jonathan, (and
Lyndon),
=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:[email-masked]]
Sent: Friday, July 21, 2006 11:34 AM
To: Brungard, Deborah A, ALABS; [email-masked]
Cc: Adrian Farrel
Subject: RE: Proposed response to OIF on OSPF ENNI Hi Deborah and
Adrian,
=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: [email-masked] [mailto:[email-masked]] On
Behalf Of Brungard, Deborah A, ALABS
Sent: Friday, July 21, 2006 9:38 AM
To: [email-masked]
Cc: Adrian Farrel
Subject: Proposed response to OIF on OSPF ENNI
=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

Delivery-date: Tue, 25 Jul 2006 16:32:21 +0000
Content-class: urn:content-classes:message
Subject: RE: Proposed response to OIF on OSPF ENNI
Date: Tue, 25 Jul 2006 11:28:36 -0500
From: "Sadler, Jonathan B." <[email-masked]>
To: "Brungard, Deborah A, ALABS" <[email-masked]>, "Ong, Lyndon" <[email-masked]>, <[email-masked]>
Cc: "Adrian Farrel" <[email-masked]>

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:[email-masked]]=20
Sent: Tuesday, July 25, 2006 9:58 AM
To: Sadler, Jonathan B.; Ong, Lyndon; [email-masked]
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:[email-masked]]=20
Sent: Monday, July 24, 2006 5:38 PM
To: Brungard, Deborah A, ALABS; Ong, Lyndon; [email-masked]
Cc: Adrian Farrel
Subject: RE: Proposed response to OIF on OSPF ENNI

Hi Deborah,

=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:[email-masked]]=20
Sent: Monday, July 24, 2006 4:31 PM
To: Sadler, Jonathan B.; Ong, Lyndon; [email-masked]
Cc: Adrian Farrel
Subject: RE: Proposed response to OIF on OSPF ENNI

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

Hi Deborah, Lyndon, et al,

=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:[email-masked]]=20
Sent: Monday, July 24, 2006 2:33 PM
To: Brungard, Deborah A, ALABS; Sadler, Jonathan B.; [email-masked]
Cc: Adrian Farrel
Subject: RE: Proposed response to OIF on OSPF ENNI

=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: [email-masked] [mailto:[email-masked]] On
Behalf Of Brungard, Deborah A, ALABS
Sent: Monday, July 24, 2006 12:15 PM
To: Sadler, Jonathan B.; [email-masked]
Cc: Adrian Farrel
Subject: RE: Proposed response to OIF on OSPF ENNI

Hi Jonathan, (and Lyndon),

=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:[email-masked]]=20
Sent: Friday, July 21, 2006 11:34 AM
To: Brungard, Deborah A, ALABS; [email-masked]
Cc: Adrian Farrel
Subject: RE: Proposed response to OIF on OSPF ENNI

Hi Deborah and Adrian,

=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: [email-masked] [mailto:[email-masked]] On
Behalf Of Brungard, Deborah A, ALABS
Sent: Friday, July 21, 2006 9:38 AM
To: [email-masked]
Cc: Adrian Farrel
Subject: Proposed response to OIF on OSPF ENNI

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

<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'>=
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></span></font></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>

<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 note the email you provided states it was notifying IT=
U of
publication. Witness the specific text:<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:.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>

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

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

<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'>=
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></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'>=
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></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'>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:[email-masked]] <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; [email-masked]<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>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>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></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/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>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>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.</span></f=
ont><font
size=3D2 face=3DArial><span style=3D'font-size:10.0pt;font-family:Arial'><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=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>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.</span></font><font siz=
e=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=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. [mailto:[email-masked]] <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; [email-masked]<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>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>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></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:[email-masked]] <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; [email-masked]<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>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>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.</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'>=
 Sadler,
Jonathan B. [mailto:[email-masked]] <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; [email-masked]<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:[email-masked]] <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.; [email-masked]<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>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>node, hence extensions are felt to be
required - and are proposed in the eval solutions draft. The </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'>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'>
[email-masked] [mailto:[email-masked]] <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.;
[email-masked]<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>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>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.</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'>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. [mailto:[email-masked]] <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;
[email-masked]<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>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>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></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'>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'>
[email-masked] [mailto:[email-masked]] <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> [email-masked]<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>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>We had a communication from OIF on the=
ir
OSPF ENNI specification. You can see the original files on </span></font><a
href=3D"http://www.olddog.co.uk/ccamp.htm"><font size=3D2 face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>http://www.olddog.co.uk/ccamp.=
htm</span></font></a><font
size=3D2 color=3Dblue face=3DArial><span style=3D'font-size:10.0pt;font-fam=
ily:Arial;
color:blue'>. 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.</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>

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

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>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></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'>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></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'>Specific comments include:<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.25in;text-indent:-.25in'><font s=
ize=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>1.</span></font><=
font
size=3D1><span style=3D'font-size:7.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </s=
pan></font>What
is the intent of this document? Will it be published as an Implementation
Agreement (IA)?<br>
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>

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

<p class=3DMsoNormal style=3D'margin-left:.25in;text-indent:-.25in'><font s=
ize=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>3.</span></font><=
font
size=3D1><span style=3D'font-size:7.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </s=
pan></font>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>

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

Delivery-date: Tue, 25 Jul 2006 16:31:40 +0000
Content-class: urn:content-classes:message
Subject: RE: Proposed response to OIF on OSPF ENNI
Date: Tue, 25 Jul 2006 12:30:02 -0400
From: "Ong, Lyndon" <[email-masked]>
To: "Brungard, Deborah A, ALABS" <[email-masked]>, "Sadler, Jonathan B." <[email-masked]>, <[email-masked]>
Cc: "Adrian Farrel" <[email-masked]>

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:[email-masked]]=20
Sent: Tuesday, July 25, 2006 7:58 AM
To: Sadler, Jonathan B.; Ong, Lyndon; [email-masked]
Cc: Adrian Farrel
Subject: RE: Proposed response to OIF on OSPF ENNI

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

Hi Deborah,

=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:[email-masked]]=20
Sent: Monday, July 24, 2006 4:31 PM
To: Sadler, Jonathan B.; Ong, Lyndon; [email-masked]
Cc: Adrian Farrel
Subject: RE: Proposed response to OIF on OSPF ENNI

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

Hi Deborah, Lyndon, et al,

=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:[email-masked]]=20
Sent: Monday, July 24, 2006 2:33 PM
To: Brungard, Deborah A, ALABS; Sadler, Jonathan B.; [email-masked]
Cc: Adrian Farrel
Subject: RE: Proposed response to OIF on OSPF ENNI

=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: [email-masked] [mailto:[email-masked]] On
Behalf Of Brungard, Deborah A, ALABS
Sent: Monday, July 24, 2006 12:15 PM
To: Sadler, Jonathan B.; [email-masked]
Cc: Adrian Farrel
Subject: RE: Proposed response to OIF on OSPF ENNI

Hi Jonathan, (and Lyndon),

=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:[email-masked]]=20
Sent: Friday, July 21, 2006 11:34 AM
To: Brungard, Deborah A, ALABS; [email-masked]
Cc: Adrian Farrel
Subject: RE: Proposed response to OIF on OSPF ENNI

Hi Deborah and Adrian,

=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: [email-masked] [mailto:[email-masked]] On
Behalf Of Brungard, Deborah A, ALABS
Sent: Friday, July 21, 2006 9:38 AM
To: [email-masked]
Cc: Adrian Farrel
Subject: Proposed response to OIF on OSPF ENNI

=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.</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>As to the relative relationships of the =
groups:&nbsp;=20
the eval draft and the</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D578530016-25072006>solutions draft are both IETF =
documents.&nbsp; They are=20
not OIF or ITU documents, and</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D578530016-25072006>decisions made in the drafts are IETF =
decisions.&nbsp;=20
Related drafts such as the</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D578530016-25072006>call signaling draft are not even going to be =
passed=20
through ITU or OIF for either group </SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D578530016-25072006>to review.&nbsp; I can and =
</SPAN></FONT><FONT=20
face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D578530016-25072006>do disagree with=20
that decision, but my views are treated as those</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D578530016-25072006>of a single IETF participant =
</SPAN></FONT><FONT=20
face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D578530016-25072006>with no greater=20
weight than any others' (maybe less :o(</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>So please, let's confine ourselves to =
commenting on=20
areas&nbsp;describing GMPLS (esp. the table</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D578530016-25072006>in 4.1) and identification of&nbsp;technical =
concerns=20
(such as the inter/intra-carrier scope)&nbsp;</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D578530016-25072006>and not worry about OIF's "intentions" or=20
"alignment"</SPAN></FONT><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D578530016-25072006>, since&nbsp;</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D578530016-25072006>a) this is not an IETF =
document</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D578530016-25072006>b) the document specifically points to =
IETF/ITU=20
</SPAN></FONT><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D578530016-25072006>for the protocol =
standards.</SPAN></FONT><FONT=20
face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D578530016-25072006>&nbsp;</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>Cheers,</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>Lyndon</SPAN></FONT></DIV><BR>
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
<HR tabIndex=3D-1>
<FONT face=3DTahoma size=3D2><B>From:</B> Brungard, Deborah A, ALABS=20
[mailto:[email-masked]] <BR><B>Sent:</B> Tuesday, July 25, 2006 7:58=20
AM<BR><B>To:</B> Sadler, Jonathan B.; Ong, Lyndon;=20
[email-masked]<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 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).</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>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D024435113-25072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>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.</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><FONT face=3DArial><FONT =
color=3D#0000ff><FONT size=3D2><SPAN=20
class=3D024435113-25072006>W</SPAN>e 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</SPAN>&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<SPAN class=3D024435113-25072006> which has us all=20
confused</SPAN>) 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.</FONT></FONT></FONT></SPAN></DIV></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>"Significant" Thanks on the=20
confusion;-)</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D024435113-25072006><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:[email-masked]] <BR><B>Sent:</B> Monday, July 24, =
2006 5:38=20
PM<BR><B>To:</B> Brungard, Deborah A, ALABS; Ong, Lyndon;=20
[email-masked]<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=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">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></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><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:[email-masked]] <BR><B><SPAN=20
style=3D"FONT-WEIGHT: bold">Sent:</SPAN></B> Monday, July 24, 2006 4:31=20
PM<BR><B><SPAN style=3D"FONT-WEIGHT: bold">To:</SPAN></B> Sadler, =
Jonathan B.;=20
Ong, Lyndon; [email-masked]<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
Jonathan,</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">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.</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">Thanks,</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">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"><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"> Sadler,=20
Jonathan B. [mailto:[email-masked]] <BR><B><SPAN=20
style=3D"FONT-WEIGHT: bold">Sent:</SPAN></B> Monday, July 24, 2006 4:32=20
PM<BR><B><SPAN style=3D"FONT-WEIGHT: bold">To:</SPAN></B> Brungard, =
Deborah A,=20
ALABS; Ong, Lyndon; [email-masked]<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>
<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 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><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:[email-masked]] <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.; [email-masked]<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 and=20
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 ASON,=20
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 no=20
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 IETF=20
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 not=20
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=20
are felt to be required - and are proposed in the eval solutions draft. =
The=20
</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">conclusions =
are no=20
different.</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 in fact define any standard extensions to the protocols, and points =
to=20
future work</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">in IETF and =
ITU to=20
provide these.&nbsp; Therefore I cannot understand where you say "new =
extensions=20
to</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">OSPF are =
specified" and=20
"none...align with the CCAMP's GMPLS-ASON work".&nbsp;=20
</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>
<DIV>
<P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><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
[email-masked] [mailto:[email-masked]] <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> Monday, =
July 24,=20
2006 12:15 PM<BR><B><SPAN style=3D"FONT-WEIGHT: bold">To:</SPAN></B> =
Sadler,=20
Jonathan B.; [email-masked]<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>
<P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Hi Jonathan, =
(and=20
Lyndon),</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">Thanks to =
both of you=20
for responding.</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">"Significant" =
was=20
referencing:</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">-=20
supports&nbsp;a&nbsp;(new) hierarchical OSPF =
model</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">-&nbsp;supports&nbsp;inter-domain=20
(inter-carrier) OSPF (not supported by today's=20
OSPF)</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">- identifies =
namespace=20
issues with GMPLS OSPF which do not exist, and proposes extensions to=20
"fix"</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">- new =
extensions to=20
OSPF are specified</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">- none of the =
proposed=20
extensions align with CCAMP's GMPLS-ASON =
work</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">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.</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">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=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"> Sadler,=20
Jonathan B. [mailto:[email-masked]] <BR><B><SPAN=20
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,=20
ALABS; [email-masked]<BR><B><SPAN style=3D"FONT-WEIGHT: =
bold">Cc:</SPAN></B>=20
Adrian Farrel<BR><B><SPAN style=3D"FONT-WEIGHT: =
bold">Subject:</SPAN></B> RE:=20
Proposed response to OIF on OSPF ENNI</SPAN></FONT><o:p></o:p></P>
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Hi Deborah =
and=20
Adrian,<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">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></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">Thanks,<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><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
[email-masked] [mailto:[email-masked]] <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
[email-masked]<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--

Delivery-date: Tue, 25 Jul 2006 14:59:55 +0000
Content-class: urn:content-classes:message
Subject: RE: Proposed response to OIF on OSPF ENNI
Date: Tue, 25 Jul 2006 09:58:24 -0500
From: "Brungard, Deborah A, ALABS" <[email-masked]>
To: "Sadler, Jonathan B." <[email-masked]>, "Ong, Lyndon" <[email-masked]>, <[email-masked]>
Cc: "Adrian Farrel" <[email-masked]>

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

Hi Deborah,

=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:[email-masked]]=20
Sent: Monday, July 24, 2006 4:31 PM
To: Sadler, Jonathan B.; Ong, Lyndon; [email-masked]
Cc: Adrian Farrel
Subject: RE: Proposed response to OIF on OSPF ENNI

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

Hi Deborah, Lyndon, et al,

=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:[email-masked]]=20
Sent: Monday, July 24, 2006 2:33 PM
To: Brungard, Deborah A, ALABS; Sadler, Jonathan B.; [email-masked]
Cc: Adrian Farrel
Subject: RE: Proposed response to OIF on OSPF ENNI

=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: [email-masked] [mailto:[email-masked]] On
Behalf Of Brungard, Deborah A, ALABS
Sent: Monday, July 24, 2006 12:15 PM
To: Sadler, Jonathan B.; [email-masked]
Cc: Adrian Farrel
Subject: RE: Proposed response to OIF on OSPF ENNI

Hi Jonathan, (and Lyndon),

=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:[email-masked]]=20
Sent: Friday, July 21, 2006 11:34 AM
To: Brungard, Deborah A, ALABS; [email-masked]
Cc: Adrian Farrel
Subject: RE: Proposed response to OIF on OSPF ENNI

Hi Deborah and Adrian,

=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: [email-masked] [mailto:[email-masked]] On
Behalf Of Brungard, Deborah A, ALABS
Sent: Friday, July 21, 2006 9:38 AM
To: [email-masked]
Cc: Adrian Farrel
Subject: Proposed response to OIF on OSPF ENNI

=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).</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>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D024435113-25072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>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.</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><FONT face=3DArial><FONT =
color=3D#0000ff><FONT size=3D2><SPAN=20
class=3D024435113-25072006>W</SPAN>e 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</SPAN>&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<SPAN class=3D024435113-25072006> which has us all=20
confused</SPAN>) 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.</FONT></FONT></FONT></SPAN></DIV></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>"Significant" Thanks on the=20
confusion;-)</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D024435113-25072006><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:[email-masked]] <BR><B>Sent:</B> Monday, July 24, =
2006 5:38=20
PM<BR><B>To:</B> Brungard, Deborah A, ALABS; Ong, Lyndon;=20
[email-masked]<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=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">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></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><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:[email-masked]] <BR><B><SPAN=20
style=3D"FONT-WEIGHT: bold">Sent:</SPAN></B> Monday, July 24, 2006 4:31=20
PM<BR><B><SPAN style=3D"FONT-WEIGHT: bold">To:</SPAN></B> Sadler, =
Jonathan B.;=20
Ong, Lyndon; [email-masked]<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
Jonathan,</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">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.</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">Thanks,</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">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"><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"> Sadler,=20
Jonathan B. [mailto:[email-masked]] <BR><B><SPAN=20
style=3D"FONT-WEIGHT: bold">Sent:</SPAN></B> Monday, July 24, 2006 4:32=20
PM<BR><B><SPAN style=3D"FONT-WEIGHT: bold">To:</SPAN></B> Brungard, =
Deborah A,=20
ALABS; Ong, Lyndon; [email-masked]<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>
<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 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><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:[email-masked]] <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.; [email-masked]<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 and=20
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 ASON,=20
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 no=20
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 IETF=20
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 not=20
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=20
are felt to be required - and are proposed in the eval solutions draft. =
The=20
</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">conclusions =
are no=20
different.</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 in fact define any standard extensions to the protocols, and points =
to=20
future work</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">in IETF and =
ITU to=20
provide these.&nbsp; Therefore I cannot understand where you say "new =
extensions=20
to</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">OSPF are =
specified" and=20
"none...align with the CCAMP's GMPLS-ASON work".&nbsp;=20
</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>
<DIV>
<P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><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
[email-masked] [mailto:[email-masked]] <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> Monday, =
July 24,=20
2006 12:15 PM<BR><B><SPAN style=3D"FONT-WEIGHT: bold">To:</SPAN></B> =
Sadler,=20
Jonathan B.; [email-masked]<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>
<P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Hi Jonathan, =
(and=20
Lyndon),</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">Thanks to =
both of you=20
for responding.</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">"Significant" =
was=20
referencing:</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">-=20
supports&nbsp;a&nbsp;(new) hierarchical OSPF =
model</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">-&nbsp;supports&nbsp;inter-domain=20
(inter-carrier) OSPF (not supported by today's=20
OSPF)</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">- identifies =
namespace=20
issues with GMPLS OSPF which do not exist, and proposes extensions to=20
"fix"</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">- new =
extensions to=20
OSPF are specified</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">- none of the =
proposed=20
extensions align with CCAMP's GMPLS-ASON =
work</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">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.</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">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=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"> Sadler,=20
Jonathan B. [mailto:[email-masked]] <BR><B><SPAN=20
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,=20
ALABS; [email-masked]<BR><B><SPAN style=3D"FONT-WEIGHT: =
bold">Cc:</SPAN></B>=20
Adrian Farrel<BR><B><SPAN style=3D"FONT-WEIGHT: =
bold">Subject:</SPAN></B> RE:=20
Proposed response to OIF on OSPF ENNI</SPAN></FONT><o:p></o:p></P>
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Hi Deborah =
and=20
Adrian,<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">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></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">Thanks,<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><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
[email-masked] [mailto:[email-masked]] <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
[email-masked]<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--

Delivery-date: Tue, 25 Jul 2006 10:49:43 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Mack-Crane, T. Benjamin" <[email-masked]>
Cc: <[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>
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

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

Delivery-date: Tue, 25 Jul 2006 10:20:09 +0000
To: "Sadler, Jonathan B." <[email-masked]>, "Ong, Lyndon" <[email-masked]>
Cc: "Adrian Farrel" <[email-masked]>, [email-masked], "Brungard, Deborah A, ALABS" <[email-masked]>, [email-masked]
Subject: RE: Proposed response to OIF on OSPF ENNI
From: [email-masked]
Date: Tue, 25 Jul 2006 12:18:29 +0200

Delivery-date: Mon, 24 Jul 2006 23:38:07 +0000
Content-class: urn:content-classes:message
Subject: RE: Proposed response to OIF on OSPF ENNI
Date: Mon, 24 Jul 2006 19:37:08 -0400
From: "Ong, Lyndon" <[email-masked]>
To: <[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>
Cc: "Adrian Farrel" <[email-masked]>, <[email-masked]>, <[email-masked]>

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

hi -=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" <[email-masked]> Sent by:
[email-masked]
21/07/2006 16:37
=20
        To:     <[email-masked]>
        cc:     "Adrian Farrel" <[email-masked]>
        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

Delivery-date: Mon, 24 Jul 2006 22:59:51 +0000
Date: Tue, 25 Jul 2006 07:59:35 +0900
From: Tomohiro Otani <[email-masked]>
To: "Brungard, Deborah A, ALABS" <[email-masked]>
Cc: [email-masked], Adrian Farrel <[email-masked]>
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,
>  
> 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
> 

Delivery-date: Mon, 24 Jul 2006 22:43:23 +0000
To: "Brungard, Deborah A, ALABS" <[email-masked]>
Cc: "Adrian Farrel" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Proposed response to OIF on OSPF ENNI
From: [email-masked]
Date: Tue, 25 Jul 2006 00:42:22 +0200

Delivery-date: Mon, 24 Jul 2006 22:02:20 +0000
Content-class: urn:content-classes:message
Subject: RE: Proposed response to OIF on OSPF ENNI
Date: Mon, 24 Jul 2006 16:58:57 -0500
From: "Sadler, Jonathan B." <[email-masked]>
To: "Brungard, Deborah A, ALABS" <[email-masked]>, "Ong, Lyndon" <[email-masked]>, <[email-masked]>
Cc: "Adrian Farrel" <[email-masked]>

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:[email-masked]]=20
Sent: Monday, July 24, 2006 4:22 PM
To: Ong, Lyndon; Sadler, Jonathan B.; [email-masked]
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:[email-masked]]=20
Sent: Monday, July 24, 2006 3:33 PM
To: Brungard, Deborah A, ALABS; Sadler, Jonathan B.; [email-masked]
Cc: Adrian Farrel
Subject: RE: Proposed response to OIF on OSPF ENNI

Hi Deborah,

=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: [email-masked] [mailto:[email-masked]] On
Behalf Of Brungard, Deborah A, ALABS
Sent: Monday, July 24, 2006 12:15 PM
To: Sadler, Jonathan B.; [email-masked]
Cc: Adrian Farrel
Subject: RE: Proposed response to OIF on OSPF ENNI

Hi Jonathan, (and Lyndon),

=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:[email-masked]]=20
Sent: Friday, July 21, 2006 11:34 AM
To: Brungard, Deborah A, ALABS; [email-masked]
Cc: Adrian Farrel
Subject: RE: Proposed response to OIF on OSPF ENNI

Hi Deborah and Adrian,

=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: [email-masked] [mailto:[email-masked]] On
Behalf Of Brungard, Deborah A, ALABS
Sent: Friday, July 21, 2006 9:38 AM
To: [email-masked]
Cc: Adrian Farrel
Subject: Proposed response to OIF on OSPF ENNI

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>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></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:[email-masked]] <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; [email-masked]<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:[email-masked]] <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.; [email-masked]<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>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>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></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>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>node, hence extensions are felt to be
required - and are proposed in the eval solutions draft. The </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'>conclusions are 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'>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;<u>if</u> non-unique link IDs (e.g.
unnumbered) were supported, an <u>optional</u> 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.</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=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>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?</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'>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'>
[email-masked] [mailto:[email-masked]] <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.;
[email-masked]<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>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>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.</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'>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:[email-masked]] <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;
[email-masked]<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>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>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></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'>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'>
[email-masked] [mailto:[email-masked]] <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> [email-masked]<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>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>We had a communication from OIF on the=
ir
OSPF ENNI specification. You can see the original files on </span></font><a
href=3D"http://www.olddog.co.uk/ccamp.htm"><font size=3D2 face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>http://www.olddog.co.uk/ccamp.=
htm</span></font></a><font
size=3D2 color=3Dblue face=3DArial><span style=3D'font-size:10.0pt;font-fam=
ily:Arial;
color:blue'>. 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.</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>

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

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>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></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'>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></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'>Specific comments include:<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.25in;text-indent:-.25in'><font s=
ize=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>1.</span></font><=
font
size=3D1><span style=3D'font-size:7.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </s=
pan></font>What
is the intent of this document? Will it be published as an Implementation
Agreement (IA)?<br>
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>

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

<p class=3DMsoNormal style=3D'margin-left:.25in;text-indent:-.25in'><font s=
ize=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>3.</span></font><=
font
size=3D1><span style=3D'font-size:7.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </s=
pan></font>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>

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

Delivery-date: Mon, 24 Jul 2006 21:41:41 +0000
Content-class: urn:content-classes:message
Subject: RE: Proposed response to OIF on OSPF ENNI
Date: Mon, 24 Jul 2006 16:38:05 -0500
From: "Sadler, Jonathan B." <[email-masked]>
To: "Brungard, Deborah A, ALABS" <[email-masked]>, "Ong, Lyndon" <[email-masked]>, <[email-masked]>
Cc: "Adrian Farrel" <[email-masked]>

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:[email-masked]]=20
Sent: Monday, July 24, 2006 4:31 PM
To: Sadler, Jonathan B.; Ong, Lyndon; [email-masked]
Cc: Adrian Farrel
Subject: RE: Proposed response to OIF on OSPF ENNI

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

Hi Deborah, Lyndon, et al,

=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:[email-masked]]=20
Sent: Monday, July 24, 2006 2:33 PM
To: Brungard, Deborah A, ALABS; Sadler, Jonathan B.; [email-masked]
Cc: Adrian Farrel
Subject: RE: Proposed response to OIF on OSPF ENNI

=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: [email-masked] [mailto:[email-masked]] On
Behalf Of Brungard, Deborah A, ALABS
Sent: Monday, July 24, 2006 12:15 PM
To: Sadler, Jonathan B.; [email-masked]
Cc: Adrian Farrel
Subject: RE: Proposed response to OIF on OSPF ENNI

Hi Jonathan, (and Lyndon),

=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:[email-masked]]=20
Sent: Friday, July 21, 2006 11:34 AM
To: Brungard, Deborah A, ALABS; [email-masked]
Cc: Adrian Farrel
Subject: RE: Proposed response to OIF on OSPF ENNI

Hi Deborah and Adrian,

=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: [email-masked] [mailto:[email-masked]] On
Behalf Of Brungard, Deborah A, ALABS
Sent: Friday, July 21, 2006 9:38 AM
To: [email-masked]
Cc: Adrian Farrel
Subject: Proposed response to OIF on OSPF ENNI

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>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></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:[email-masked]] <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; [email-masked]<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>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>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.</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'>=
 Sadler,
Jonathan B. [mailto:[email-masked]] <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; [email-masked]<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:[email-masked]] <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.; [email-masked]<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>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>node, hence extensions are felt to be
required - and are proposed in the eval solutions draft. The </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'>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'>
[email-masked] [mailto:[email-masked]] <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=
[email-masked]<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>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>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.</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'>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. [mailto:[email-masked]] <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;
[email-masked]<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>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>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></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'>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'>
[email-masked] [mailto:[email-masked]] <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> [email-masked]<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>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>We had a communication from OIF on the=
ir
OSPF ENNI specification. You can see the original files on </span></font><a
href=3D"http://www.olddog.co.uk/ccamp.htm"><font size=3D2 face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>http://www.olddog.co.uk/ccamp.=
htm</span></font></a><font
size=3D2 color=3Dblue face=3DArial><span style=3D'font-size:10.0pt;font-fam=
ily:Arial;
color:blue'>. 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.</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>

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

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>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></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'>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></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'>Specific comments include:<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.25in;text-indent:-.25in'><font s=
ize=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>1.</span></font><=
font
size=3D1><span style=3D'font-size:7.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </s=
pan></font>What
is the intent of this document? Will it be published as an Implementation
Agreement (IA)?<br>
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>

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

<p class=3DMsoNormal style=3D'margin-left:.25in;text-indent:-.25in'><font s=
ize=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>3.</span></font><=
font
size=3D1><span style=3D'font-size:7.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </s=
pan></font>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>

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

Delivery-date: Mon, 24 Jul 2006 21:31:32 +0000
Content-class: urn:content-classes:message
Subject: RE: Proposed response to OIF on OSPF ENNI
Date: Mon, 24 Jul 2006 16:31:17 -0500
From: "Brungard, Deborah A, ALABS" <[email-masked]>
To: "Sadler, Jonathan B." <[email-masked]>, "Ong, Lyndon" <[email-masked]>, <[email-masked]>
Cc: "Adrian Farrel" <[email-masked]>

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

Hi Deborah, Lyndon, et al,

=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:[email-masked]]=20
Sent: Monday, July 24, 2006 2:33 PM
To: Brungard, Deborah A, ALABS; Sadler, Jonathan B.; [email-masked]
Cc: Adrian Farrel
Subject: RE: Proposed response to OIF on OSPF ENNI

=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: [email-masked] [mailto:[email-masked]] On
Behalf Of Brungard, Deborah A, ALABS
Sent: Monday, July 24, 2006 12:15 PM
To: Sadler, Jonathan B.; [email-masked]
Cc: Adrian Farrel
Subject: RE: Proposed response to OIF on OSPF ENNI

Hi Jonathan, (and Lyndon),

=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:[email-masked]]=20
Sent: Friday, July 21, 2006 11:34 AM
To: Brungard, Deborah A, ALABS; [email-masked]
Cc: Adrian Farrel
Subject: RE: Proposed response to OIF on OSPF ENNI

Hi Deborah and Adrian,

=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: [email-masked] [mailto:[email-masked]] On
Behalf Of Brungard, Deborah A, ALABS
Sent: Friday, July 21, 2006 9:38 AM
To: [email-masked]
Cc: Adrian Farrel
Subject: Proposed response to OIF on OSPF ENNI

=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:[email-masked]] <BR><B>Sent:</B> Monday, July 24, =
2006 4:32=20
PM<BR><B>To:</B> Brungard, Deborah A, ALABS; Ong, Lyndon;=20
[email-masked]<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><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:[email-masked]] <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.; [email-masked]<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 and=20
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 ASON,=20
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 no=20
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 IETF=20
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 not=20
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=20
are felt to be required - and are proposed in the eval solutions draft. =
The=20
</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">conclusions =
are no=20
different.</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 in fact define any standard extensions to the protocols, and points =
to=20
future work</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">in IETF and =
ITU to=20
provide these.&nbsp; Therefore I cannot understand where you say "new =
extensions=20
to</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">OSPF are =
specified" and=20
"none...align with the CCAMP's GMPLS-ASON work".&nbsp;=20
</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>
<DIV>
<P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><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
[email-masked] [mailto:[email-masked]] <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> Monday, =
July 24,=20
2006 12:15 PM<BR><B><SPAN style=3D"FONT-WEIGHT: bold">To:</SPAN></B> =
Sadler,=20
Jonathan B.; [email-masked]<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>
<P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Hi Jonathan, =
(and=20
Lyndon),</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">Thanks to =
both of you=20
for responding.</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">"Significant" =
was=20
referencing:</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">-=20
supports&nbsp;a&nbsp;(new) hierarchical OSPF =
model</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">-&nbsp;supports&nbsp;inter-domain=20
(inter-carrier) OSPF (not supported by today's=20
OSPF)</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">- identifies =
namespace=20
issues with GMPLS OSPF which do not exist, and proposes extensions to=20
"fix"</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">- new =
extensions to=20
OSPF are specified</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">- none of the =
proposed=20
extensions align with CCAMP's GMPLS-ASON =
work</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">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.</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">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=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"> Sadler,=20
Jonathan B. [mailto:[email-masked]] <BR><B><SPAN=20
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,=20
ALABS; [email-masked]<BR><B><SPAN style=3D"FONT-WEIGHT: =
bold">Cc:</SPAN></B>=20
Adrian Farrel<BR><B><SPAN style=3D"FONT-WEIGHT: =
bold">Subject:</SPAN></B> RE:=20
Proposed response to OIF on OSPF ENNI</SPAN></FONT><o:p></o:p></P>
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Hi Deborah =
and=20
Adrian,<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">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></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">Thanks,<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><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
[email-masked] [mailto:[email-masked]] <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
[email-masked]<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--

Delivery-date: Mon, 24 Jul 2006 21:22:17 +0000
Content-class: urn:content-classes:message
Subject: RE: Proposed response to OIF on OSPF ENNI
Date: Mon, 24 Jul 2006 16:21:41 -0500
From: "Brungard, Deborah A, ALABS" <[email-masked]>
To: "Ong, Lyndon" <[email-masked]>, "Sadler, Jonathan B." <[email-masked]>, <[email-masked]>
Cc: "Adrian Farrel" <[email-masked]>

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:[email-masked]]=20
Sent: Monday, July 24, 2006 3:33 PM
To: Brungard, Deborah A, ALABS; Sadler, Jonathan B.; [email-masked]
Cc: Adrian Farrel
Subject: RE: Proposed response to OIF on OSPF ENNI

Hi Deborah,
=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: [email-masked] [mailto:[email-masked]] On
Behalf Of Brungard, Deborah A, ALABS
Sent: Monday, July 24, 2006 12:15 PM
To: Sadler, Jonathan B.; [email-masked]
Cc: Adrian Farrel
Subject: RE: Proposed response to OIF on OSPF ENNI

Hi Jonathan, (and Lyndon),
=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:[email-masked]]=20
Sent: Friday, July 21, 2006 11:34 AM
To: Brungard, Deborah A, ALABS; [email-masked]
Cc: Adrian Farrel
Subject: RE: Proposed response to OIF on OSPF ENNI

Hi Deborah and Adrian,

=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: [email-masked] [mailto:[email-masked]] On
Behalf Of Brungard, Deborah A, ALABS
Sent: Friday, July 21, 2006 9:38 AM
To: [email-masked]
Cc: Adrian Farrel
Subject: Proposed response to OIF on OSPF ENNI

=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:[email-masked]]=20
<BR><B>Sent:</B> Monday, July 24, 2006 3:33 PM<BR><B>To:</B> Brungard, =
Deborah=20
A, ALABS; Sadler, Jonathan B.; [email-masked]<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;<U>if</U> non-unique link =
IDs (e.g.=20
unnumbered) were supported, an <U>optional</U> 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.</SPAN></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><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?</SPAN></FONT></SPAN></DIV>
<DIV><SPAN class=3D839162419-24072006><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D749145619-24072006></SPAN></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><SPAN=20
class=3D749145619-24072006>db&gt; Agree;-)</SPAN></FONT></SPAN></DIV>
<DIV><SPAN class=3D839162419-24072006><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D749145619-24072006></SPAN></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</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><BR></DIV>
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
<HR tabIndex=3D-1>
<FONT face=3DTahoma size=3D2><B>From:</B> [email-masked]=20
[mailto:[email-masked]] <B>On Behalf Of </B>Brungard, Deborah =
A,=20
ALABS<BR><B>Sent:</B> Monday, July 24, 2006 12:15 PM<BR><B>To:</B> =
Sadler,=20
Jonathan B.; [email-masked]<BR><B>Cc:</B> Adrian =
Farrel<BR><B>Subject:</B>=20
RE: Proposed response to OIF on OSPF ENNI<BR></FONT><BR></DIV>
<DIV></DIV>
<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.</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>Deborah</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><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:[email-masked]] <BR><B>Sent:</B> Friday, July 21, =
2006=20
11:34 AM<BR><B>To:</B> Brungard, Deborah A, ALABS;=20
[email-masked]<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 =
and=20
Adrian,<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">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></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">Thanks,<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><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
[email-masked] [mailto:[email-masked]] <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
[email-masked]<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--

Delivery-date: Mon, 24 Jul 2006 21:03:27 +0000
Content-class: urn:content-classes:message
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
From: "Mack-Crane, T. Benjamin" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>
Cc: <[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>

Hi Adrian,

Some more questions in-line.

Regards,
Ben

> Sent: Sunday, July 23, 2006 10:19 AM
> To: Mack-Crane, T. Benjamin
> Cc: [email-masked]; 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
>=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

Delivery-date: Mon, 24 Jul 2006 20:35:34 +0000
Content-class: urn:content-classes:message
Subject: RE: Proposed response to OIF on OSPF ENNI
Date: Mon, 24 Jul 2006 15:31:55 -0500
From: "Sadler, Jonathan B." <[email-masked]>
To: "Brungard, Deborah A, ALABS" <[email-masked]>, "Ong, Lyndon" <[email-masked]>, <[email-masked]>
Cc: "Adrian Farrel" <[email-masked]>

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:[email-masked]]=20
Sent: Monday, July 24, 2006 2:33 PM
To: Brungard, Deborah A, ALABS; Sadler, Jonathan B.; [email-masked]
Cc: Adrian Farrel
Subject: RE: Proposed response to OIF on OSPF ENNI

=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: [email-masked] [mailto:[email-masked]] On
Behalf Of Brungard, Deborah A, ALABS
Sent: Monday, July 24, 2006 12:15 PM
To: Sadler, Jonathan B.; [email-masked]
Cc: Adrian Farrel
Subject: RE: Proposed response to OIF on OSPF ENNI

Hi Jonathan, (and Lyndon),

=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:[email-masked]]=20
Sent: Friday, July 21, 2006 11:34 AM
To: Brungard, Deborah A, ALABS; [email-masked]
Cc: Adrian Farrel
Subject: RE: Proposed response to OIF on OSPF ENNI

Hi Deborah and Adrian,

=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: [email-masked] [mailto:[email-masked]] On
Behalf Of Brungard, Deborah A, ALABS
Sent: Friday, July 21, 2006 9:38 AM
To: [email-masked]
Cc: Adrian Farrel
Subject: Proposed response to OIF on OSPF ENNI

=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:[email-masked]] <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.; [email-masked]<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>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>node, hence extensions are felt to be
required - and are proposed in the eval solutions draft. The </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'>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'>
[email-masked] [mailto:[email-masked]] <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.;
[email-masked]<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>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>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.</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'>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. [mailto:[email-masked]] <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;
[email-masked]<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>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>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></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'>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'>
[email-masked] [mailto:[email-masked]] <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> [email-masked]<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>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>We had a communication from OIF on the=
ir
OSPF ENNI specification. You can see the original files on </span></font><a
href=3D"http://www.olddog.co.uk/ccamp.htm"><font size=3D2 face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>http://www.olddog.co.uk/ccamp.=
htm</span></font></a><font
size=3D2 color=3Dblue face=3DArial><span style=3D'font-size:10.0pt;font-fam=
ily:Arial;
color:blue'>. 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.</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>

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

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>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></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'>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></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'>Specific comments include:<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.25in;text-indent:-.25in'><font s=
ize=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>1.</span></font><=
font
size=3D1><span style=3D'font-size:7.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </s=
pan></font>What
is the intent of this document? Will it be published as an Implementation
Agreement (IA)?<br>
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>

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

<p class=3DMsoNormal style=3D'margin-left:.25in;text-indent:-.25in'><font s=
ize=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>3.</span></font><=
font
size=3D1><span style=3D'font-size:7.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </s=
pan></font>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>

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

Delivery-date: Mon, 24 Jul 2006 19:34:48 +0000
Content-class: urn:content-classes:message
Subject: RE: Proposed response to OIF on OSPF ENNI
Date: Mon, 24 Jul 2006 15:33:28 -0400
From: "Ong, Lyndon" <[email-masked]>
To: "Brungard, Deborah A, ALABS" <[email-masked]>, "Sadler, Jonathan B." <[email-masked]>, <[email-masked]>
Cc: "Adrian Farrel" <[email-masked]>

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

Hi Jonathan, (and Lyndon),
=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:[email-masked]]=20
Sent: Friday, July 21, 2006 11:34 AM
To: Brungard, Deborah A, ALABS; [email-masked]
Cc: Adrian Farrel
Subject: RE: Proposed response to OIF on OSPF ENNI

Hi Deborah and Adrian,

=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: [email-masked] [mailto:[email-masked]] On
Behalf Of Brungard, Deborah A, ALABS
Sent: Friday, July 21, 2006 9:38 AM
To: [email-masked]
Cc: Adrian Farrel
Subject: Proposed response to OIF on OSPF ENNI

=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</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><BR></DIV>
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
<HR tabIndex=3D-1>
<FONT face=3DTahoma size=3D2><B>From:</B> [email-masked]=20
[mailto:[email-masked]] <B>On Behalf Of </B>Brungard, Deborah =
A,=20
ALABS<BR><B>Sent:</B> Monday, July 24, 2006 12:15 PM<BR><B>To:</B> =
Sadler,=20
Jonathan B.; [email-masked]<BR><B>Cc:</B> Adrian =
Farrel<BR><B>Subject:</B>=20
RE: Proposed response to OIF on OSPF ENNI<BR></FONT><BR></DIV>
<DIV></DIV>
<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.</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>Deborah</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><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:[email-masked]] <BR><B>Sent:</B> Friday, July 21, =
2006=20
11:34 AM<BR><B>To:</B> Brungard, Deborah A, ALABS;=20
[email-masked]<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 =
and=20
Adrian,<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">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></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">Thanks,<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><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
[email-masked] [mailto:[email-masked]] <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
[email-masked]<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--

Delivery-date: Mon, 24 Jul 2006 19:17:34 +0000
Content-class: urn:content-classes:message
Subject: RE: Proposed response to OIF on OSPF ENNI
Date: Mon, 24 Jul 2006 14:15:29 -0500
From: "Brungard, Deborah A, ALABS" <[email-masked]>
To: "Sadler, Jonathan B." <[email-masked]>, <[email-masked]>
Cc: "Adrian Farrel" <[email-masked]>

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:[email-masked]]=20
Sent: Friday, July 21, 2006 11:34 AM
To: Brungard, Deborah A, ALABS; [email-masked]
Cc: Adrian Farrel
Subject: RE: Proposed response to OIF on OSPF ENNI

Hi Deborah and Adrian,

=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: [email-masked] [mailto:[email-masked]] On
Behalf Of Brungard, Deborah A, ALABS
Sent: Friday, July 21, 2006 9:38 AM
To: [email-masked]
Cc: Adrian Farrel
Subject: Proposed response to OIF on OSPF ENNI

=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.</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>Deborah</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><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:[email-masked]] <BR><B>Sent:</B> Friday, July 21, =
2006=20
11:34 AM<BR><B>To:</B> Brungard, Deborah A, ALABS;=20
[email-masked]<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 =
and=20
Adrian,<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">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></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">Thanks,<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><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
[email-masked] [mailto:[email-masked]] <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
[email-masked]<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--

Delivery-date: Sun, 23 Jul 2006 15:28:54 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Mack-Crane, T. Benjamin" <[email-masked]>
Cc: <[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>
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

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

Delivery-date: Fri, 21 Jul 2006 18:24:05 +0000
Content-class: urn:content-classes:message
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
From: "Mack-Crane, T. Benjamin" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>
Cc: <[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>

Hi Adrian,

Some questions below...

Regards,
Ben

> Sent: Thursday, July 20, 2006 1:55 PM
> To: Mack-Crane, T. Benjamin
> Cc: [email-masked]; 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
>=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

Delivery-date: Fri, 21 Jul 2006 16:48:02 +0000
Content-class: urn:content-classes:message
Subject: RE: Proposed response to OIF on OSPF ENNI
Date: Fri, 21 Jul 2006 12:46:56 -0400
From: "Ong, Lyndon" <[email-masked]>
To: "Brungard, Deborah A, ALABS" <[email-masked]>, <[email-masked]>
Cc: "Adrian Farrel" <[email-masked]>

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

Hi,
=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> [email-masked]=20
[mailto:[email-masked]] <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
[email-masked]<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></I></FONT></FONT><SPAN=20
style=3D"mso-bidi-font-weight: bold; mso-bidi-font-style: italic"><FONT=20
size=3D3><FONT face=3D"Times New Roman">&#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><o:p></o:p></I></FONT></FONT></SPAN></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"><SPAN=20
style=3D"mso-fareast-font-family: 'Times New Roman'"><SPAN=20
style=3D"mso-list: Ignore"><FONT size=3D3>3.</FONT><SPAN=20
style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></SPAN></SPAN><FONT size=3D3>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.</FONT></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 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.</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>Best regards,</FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT size=3D3><FONT=20
face=3D"Times New Roman"><st1:PersonName w:st=3D"on">Adrian =
Farrel</st1:PersonName>=20
and Deborah Brungard,</FONT></FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT face=3D"Times =
New Roman"=20
size=3D3>CCAMP co-chairs</FONT></P></FONT></DIV></BODY></HTML>

------_=_NextPart_001_01C6ACE5.450A8AB5--

Delivery-date: Fri, 21 Jul 2006 16:31:36 +0000
Date: Fri, 21 Jul 2006 12:30:28 -0400
From: Acee Lindem <[email-masked]>
To: "Sadler, Jonathan B." <[email-masked]>
CC: Adrian Farrel <[email-masked]>, [email-masked]
Subject: Re: OSPF ASON Routing Solution

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
>
> Behalf Of Acee Lindem
> Sent: Thursday, July 20, 2006 4:40 PM
> To: Adrian Farrel
> Cc: [email-masked]
>> ----- Original Message ----- From: "Adrian Farrel"
>>     
> <[email-masked]>
>   
>> To: <[email-masked]>
> ============================================================
> 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
> ============================================================
>
>   

Delivery-date: Fri, 21 Jul 2006 15:37:06 +0000
Content-class: urn:content-classes:message
Subject: RE: Proposed response to OIF on OSPF ENNI
Date: Fri, 21 Jul 2006 10:34:08 -0500
From: "Sadler, Jonathan B." <[email-masked]>
To: "Brungard, Deborah A, ALABS" <[email-masked]>, <[email-masked]>
Cc: "Adrian Farrel" <[email-masked]>

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

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:navy'>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></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'>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'>
[email-masked] [mailto:[email-masked]] <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> [email-masked]<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>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span style=
=3D'font-size:
10.0pt;font-family:Arial;color:blue'>We had a communication from OIF on the=
ir
OSPF ENNI specification. You can see the original files on </span></font><a
href=3D"http://www.olddog.co.uk/ccamp.htm"><font size=3D2 face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>http://www.olddog.co.uk/ccamp.=
htm</span></font></a><font
size=3D2 color=3Dblue face=3DArial><span style=3D'font-size:10.0pt;font-fam=
ily:Arial;
color:blue'>. 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.</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>

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

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span style=3D=
'font-size:
12.0pt'>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></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'>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></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'>Specific comments include:<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.25in;text-indent:-.25in'><font s=
ize=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>1.</span></font><=
font
size=3D1><span style=3D'font-size:7.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </s=
pan></font>What
is the intent of this document? Will it be published as an Implementation
Agreement (IA)?<br>
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>

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

<p class=3DMsoNormal style=3D'margin-left:.25in;text-indent:-.25in'><font s=
ize=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>3.</span></font><=
font
size=3D1><span style=3D'font-size:7.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </s=
pan></font>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>

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

Delivery-date: Fri, 21 Jul 2006 15:29:33 +0000
Content-class: urn:content-classes:message
Subject: RE: OSPF ASON Routing Solution
Date: Fri, 21 Jul 2006 10:25:26 -0500
From: "Sadler, Jonathan B." <[email-masked]>
To: "Acee Lindem" <[email-masked]>, "Adrian Farrel" <[email-masked]>
Cc: <[email-masked]>

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: [email-masked] [mailto:[email-masked]] On
Behalf Of Acee Lindem
Sent: Thursday, July 20, 2006 4:40 PM
To: Adrian Farrel
Cc: [email-masked]
Subject: Re: OSPF ASON Routing Solution

Thanks,
Acee=20

Adrian Farrel wrote:
>> On Monday in CCAMP we discussed=20
>> draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt the solutions=20

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

Delivery-date: Fri, 21 Jul 2006 15:02:18 +0000
From: "Igor Bryskin" <[email-masked]>
To: <[email-masked]>
Cc: "Acee Lindem" <[email-masked]>, "Adrian Farrel" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: OSPF ASON Routing Solution
Date: Fri, 21 Jul 2006 11:01:30 -0400

See  in-line.
Igor

----- Original Message ----- 
From: <[email-masked]>
To: "Igor Bryskin" <[email-masked]>
Cc: "Acee Lindem" <[email-masked]>; "Adrian Farrel" <[email-masked]>;
<[email-masked]>; <[email-masked]>
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.
>
>
>
>
>
>
> 21/07/2006 16:04
>         cc:     "Acee Lindem" <[email-masked]>, "Adrian Farrel"
> <[email-masked]>, <[email-masked]>, <[email-masked]>

Delivery-date: Fri, 21 Jul 2006 14:37:39 +0000
Content-class: urn:content-classes:message
Subject: Proposed response to OIF on OSPF ENNI
Date: Fri, 21 Jul 2006 09:37:32 -0500
From: "Brungard, Deborah A, ALABS" <[email-masked]>
To: <[email-masked]>
Cc: "Adrian Farrel" <[email-masked]>

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></I></FONT></FONT><SPAN=20
style=3D"mso-bidi-font-weight: bold; mso-bidi-font-style: italic"><FONT=20
size=3D3><FONT face=3D"Times New Roman">&#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><o:p></o:p></I></FONT></FONT></SPAN></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"><SPAN=20
style=3D"mso-fareast-font-family: 'Times New Roman'"><SPAN=20
style=3D"mso-list: Ignore"><FONT size=3D3>3.</FONT><SPAN=20
style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></SPAN></SPAN><FONT size=3D3>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.</FONT></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 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.</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>Best regards,</FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT size=3D3><FONT=20
face=3D"Times New Roman"><st1:PersonName w:st=3D"on">Adrian =
Farrel</st1:PersonName>=20
and Deborah Brungard,</FONT></FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT face=3D"Times =
New Roman"=20
size=3D3>CCAMP co-chairs</FONT></P></FONT></DIV></BODY></HTML>

------_=_NextPart_001_01C6ACD3.33A1ED98--

Delivery-date: Fri, 21 Jul 2006 14:37:22 +0000
To: "Igor Bryskin" <[email-masked]>
Cc: "Acee Lindem" <[email-masked]>, "Adrian Farrel" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: OSPF ASON Routing Solution
From: [email-masked]
Date: Fri, 21 Jul 2006 16:36:38 +0200

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.

21/07/2006 16:04
 
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     "Acee Lindem" <[email-masked]>, "Adrian Farrel" 
<[email-masked]>, <[email-masked]>, <[email-masked]>
        Subject:        Re: OSPF ASON Routing Solution

Dimitri,

Please, see in line.

Igor

----- Original Message ----- 
From: <[email-masked]>
To: "Igor Bryskin" <[email-masked]>
Cc: "Acee Lindem" <[email-masked]>; "Adrian Farrel" <[email-masked]>;

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.

> 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

> Sent by: [email-masked]

Delivery-date: Fri, 21 Jul 2006 14:10:20 +0000
From: "Igor Bryskin" <[email-masked]>
To: "Acee Lindem" <[email-masked]>
Cc: "Adrian Farrel" <[email-masked]>, <[email-masked]>
Subject: Re: OSPF ASON Routing Solution
Date: Fri, 21 Jul 2006 10:09:39 -0400

Acee,

Igor

----- Original Message ----- 
From: "Acee Lindem" <[email-masked]>
To: "Igor Bryskin" <[email-masked]>
Cc: "Adrian Farrel" <[email-masked]>; <[email-masked]>
Sent: Thursday, July 20, 2006 9:44 PM
Subject: Re: OSPF ASON Routing Solution

should
> >>>> PS Note that a solution does not have to be 100% perfect to become a

Delivery-date: Fri, 21 Jul 2006 14:06:38 +0000
From: "Igor Bryskin" <[email-masked]>
To: <[email-masked]>
Cc: "Acee Lindem" <[email-masked]>, "Adrian Farrel" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: OSPF ASON Routing Solution
Date: Fri, 21 Jul 2006 10:04:56 -0400

Dimitri,

Please, see in line.

Igor

----- Original Message ----- 
From: <[email-masked]>
To: "Igor Bryskin" <[email-masked]>
Cc: "Acee Lindem" <[email-masked]>; "Adrian Farrel" <[email-masked]>;

Igor

> Sent by: [email-masked]

Delivery-date: Fri, 21 Jul 2006 01:45:13 +0000
Date: Thu, 20 Jul 2006 21:44:12 -0400
From: Acee Lindem <[email-masked]>
To: Igor Bryskin <[email-masked]>
CC: Adrian Farrel <[email-masked]>, [email-masked]
Subject: Re: OSPF ASON Routing Solution

Hi Igor,

Thanks,
Acee

>>>> PS Note that a solution does not have to be 100% perfect to become a

Delivery-date: Fri, 21 Jul 2006 00:07:06 +0000
To: "Igor Bryskin" <[email-masked]>
Cc: "Acee Lindem" <[email-masked]>, "Adrian Farrel" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: OSPF ASON Routing Solution
From: [email-masked]
Date: Fri, 21 Jul 2006 02:05:45 +0200

 

Hi Acee,

Igor

----- Original Message ----- 
From: "Acee Lindem" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, July 20, 2006 5:40 PM
Subject: Re: OSPF ASON Routing Solution

> >> PS Note that a solution does not have to be 100% perfect to become a

Delivery-date: Thu, 20 Jul 2006 23:01:10 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Mack-Crane, T. Benjamin" <[email-masked]>
Cc: <[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>
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

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

Delivery-date: Thu, 20 Jul 2006 22:07:00 +0000
From: "Igor Bryskin" <[email-masked]>
To: "Acee Lindem" <[email-masked]>, "Adrian Farrel" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: OSPF ASON Routing Solution
Date: Thu, 20 Jul 2006 18:05:51 -0400

Hi Acee,

Igor

----- Original Message ----- 
From: "Acee Lindem" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, July 20, 2006 5:40 PM
Subject: Re: OSPF ASON Routing Solution

> >> PS Note that a solution does not have to be 100% perfect to become a

Delivery-date: Thu, 20 Jul 2006 21:41:23 +0000
Date: Thu, 20 Jul 2006 17:40:24 -0400
From: Acee Lindem <[email-masked]>
To: Adrian Farrel <[email-masked]>
CC: [email-masked]
Subject: Re: OSPF ASON Routing Solution

Thanks,
Acee 

>> PS Note that a solution does not have to be 100% perfect to become a 

Delivery-date: Thu, 20 Jul 2006 18:58:39 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Mack-Crane, T. Benjamin" <[email-masked]>
Cc: <[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>
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

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

Delivery-date: Thu, 20 Jul 2006 15:28:07 +0000
Content-class: urn:content-classes:message
Subject: FW: [mpls] Use of reserved bits in Session object
Date: Thu, 20 Jul 2006 11:26:15 -0400
From: "Ong, Lyndon" <[email-masked]>
To: <[email-masked]>

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:[email-masked]]=20
Sent: Thursday, July 20, 2006 8:03 AM
To: Adrian Farrel; [email-masked]
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:[email-masked]]
Sent: Wednesday, July 12, 2006 12:57 PM
To: [email-masked]
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
[email-masked]
https://www1.ietf.org/mailman/listinfo/mpls

_______________________________________________
mpls mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mpls

Delivery-date: Thu, 20 Jul 2006 13:09:44 +0000
To: Jeroen van der Ham <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Questions regarding draft-ietf-ccamp-gmpls-mln-reqs-01
From: [email-masked]
Date: Thu, 20 Jul 2006 15:08:21 +0200

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.
> 
> [email-masked] 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.
> 
> 
> .
> 

Delivery-date: Thu, 20 Jul 2006 08:42:26 +0000
Date: Thu, 20 Jul 2006 10:41:50 +0200
From: Gert Grammel <[email-masked]>
Organization: Alcatel OND
CC: [email-masked]
Subject: Re: OSPF ASON Routing Solution

Adrian,

Gert

>> PS Note that a solution does not have to be 100% perfect to become a 

Delivery-date: Thu, 20 Jul 2006 06:56:51 +0000
Date: Thu, 20 Jul 2006 08:55:26 +0200
From: Jeroen van der Ham <[email-masked]>
To:  [email-masked]
CC:  [email-masked],  [email-masked]
Subject: Re: Questions regarding draft-ietf-ccamp-gmpls-mln-reqs-01

Hello Dimitri,

Thank you for your answers, it made some things much clearer.
I do have some additional comments though, find them inline.

[email-masked] 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.

Delivery-date: Wed, 19 Jul 2006 22:51:09 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-inter-domain-framework-05.txt 
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 
[email-masked] 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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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:	<[email-masked]>

--OtherAccess--

--NextPart--

Delivery-date: Wed, 19 Jul 2006 20:00:27 +0000
From: "Rajiv Papneja" <[email-masked]>
To: "'Adrian Farrel'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: OSPF ASON Routing Solution
Date: Wed, 19 Jul 2006 15:59:47 -0400

Adrian,

/R

toes,
> PS Note that a solution does not have to be 100% perfect to become a WG

Delivery-date: Wed, 19 Jul 2006 19:18:39 +0000
From: "Igor Bryskin" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: OSPF ASON Routing Solution
Date: Wed, 19 Jul 2006 15:17:36 -0400

Igor

> >> PS Note that a solution does not have to be 100% perfect to become a

Delivery-date: Wed, 19 Jul 2006 18:52:03 +0000
Content-class: urn:content-classes:message
Subject: RE: OSPF ASON Routing Solution
Date: Wed, 19 Jul 2006 14:50:39 -0400
From: "Ong, Lyndon" <[email-masked]>
To: "Richard Rabbat" <[email-masked]>, "Adrian Farrel" <[email-masked]>
Cc: <[email-masked]>

Cheers,
Lyndon=20

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

Adrian Farrel wrote:
> ----- Original Message ----- From: "Adrian Farrel"=20
> <[email-masked]>
> To: <[email-masked]>
>> draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt the solutions=20

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

Delivery-date: Wed, 19 Jul 2006 18:42:34 +0000
To: Jeroen van der Ham <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Questions regarding draft-ietf-ccamp-gmpls-mln-reqs-01
From: [email-masked]
Date: Wed, 19 Jul 2006 20:42:23 +0200

hi jeroen - 

first thanks for commenting - reviews are needed -

see in-line:

Jeroen van der Ham <[email-masked]>
Sent by: [email-masked]
19/07/2006 17:12
 
        To:     [email-masked]
        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.

Delivery-date: Wed, 19 Jul 2006 18:37:51 +0000
Content-class: urn:content-classes:message
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
From: "Mack-Crane, T. Benjamin" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>
Cc: <[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>

Hi Adrian,

See in-line.

Regards,
Ben

> Sent: Wednesday, July 19, 2006 8:26 AM
> To: Mack-Crane, T. Benjamin
> Cc: [email-masked]; 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

Delivery-date: Wed, 19 Jul 2006 18:08:44 +0000
Date: Wed, 19 Jul 2006 11:07:59 -0700
From: Richard Rabbat <[email-masked]>
To: Lucy Yong <[email-masked]>
CC: "'Huub van Helvoort'" <[email-masked]>, "'Ong, Lyndon'" <[email-masked]>, [email-masked], Richard Rabbat <[email-masked]>
Subject: Re: association object

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
>
> From: Huub van Helvoort [mailto:[email-masked]] 
> Sent: Wednesday, July 19, 2006 7:38 AM
> To: Lucy Yong; 'Ong, Lyndon'; [email-masked]; [email-masked]
> 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: [email-masked] [mailto:[email-masked]] On Behalf
>> Of Ong, Lyndon
>> Sent: Tuesday, July 18, 2006 12:26 PM
>> To: Lucy Yong; [email-masked]; [email-masked]
>> 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: [email-masked] [mailto:[email-masked]] On Behalf
>> Of Lucy Yong
>> Sent: Tuesday, July 18, 2006 7:16 AM
>> To: [email-masked]; [email-masked]
>> 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
>>
>>     
>
>
>
>
>   

Delivery-date: Wed, 19 Jul 2006 17:58:56 +0000
Date: Wed, 19 Jul 2006 10:58:28 -0700
From: Richard Rabbat <[email-masked]>
To: Adrian Farrel <[email-masked]>
CC: [email-masked]
Subject: Re: OSPF ASON Routing Solution

>> PS Note that a solution does not have to be 100% perfect to become a 

Delivery-date: Wed, 19 Jul 2006 17:55:02 +0000
Subject: Re: OSPF ASON Routing Solution
To: "Adrian Farrel" <[email-masked]>
Cc: [email-masked], [email-masked]
From: [email-masked]
Date: Wed, 19 Jul 2006 19:53:53 +0200

Adrian,

@+ mannu

                      "Adrian Farrel"                                                                                                

                      19/07/2006 15:27                                                                                               
                      Please respond                                                                                                 
                      to "Adrian                                                                                                     
                      Farrel"                                                                                                        

Adrian
----- Original Message -----
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, July 12, 2006 8:10 PM
Subject: OSPF ASON Routing Solution

for
> PS Note that a solution does not have to be 100% perfect to become a WG

Delivery-date: Wed, 19 Jul 2006 15:13:17 +0000
Date: Wed, 19 Jul 2006 17:12:27 +0200
From: Jeroen van der Ham <[email-masked]>
To:  [email-masked]
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.

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

Delivery-date: Wed, 19 Jul 2006 14:36:27 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Mack-Crane, T. Benjamin" <[email-masked]>
Cc: <[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>
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

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 

Delivery-date: Wed, 19 Jul 2006 14:36:19 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Re: OSPF ASON Routing Solution
Date: Wed, 19 Jul 2006 14:27:17 +0100
Organization: Old Dog Consulting

Adrian
----- Original Message ----- 
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, July 12, 2006 8:10 PM
Subject: OSPF ASON Routing Solution

> PS Note that a solution does not have to be 100% perfect to become a WG 

Delivery-date: Wed, 19 Jul 2006 14:08:11 +0000
Date: Wed, 19 Jul 2006 09:06:43 -0500
From: Lucy Yong <[email-masked]>
Subject: RE: RE: association object
To: 'Huub van Helvoort' <[email-masked]>, "'Ong, Lyndon'" <[email-masked]>, [email-masked], [email-masked]

Huub,

Thank you fro the answer. The value I mentioned is for VCG group ID.

Regards,
Lucy

-----Original Message-----
From: Huub van Helvoort [mailto:[email-masked]] 
Sent: Wednesday, July 19, 2006 7:38 AM
To: Lucy Yong; 'Ong, Lyndon'; [email-masked]; [email-masked]
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: [email-masked] [mailto:[email-masked]] On Behalf
> Of Ong, Lyndon
> Sent: Tuesday, July 18, 2006 12:26 PM
> To: Lucy Yong; [email-masked]; [email-masked]
> 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: [email-masked] [mailto:[email-masked]] On Behalf
> Of Lucy Yong
> Sent: Tuesday, July 18, 2006 7:16 AM
> To: [email-masked]; [email-masked]
> 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
> 

Delivery-date: Wed, 19 Jul 2006 12:39:41 +0000
From: Huub van Helvoort <[email-masked]>
To: Lucy Yong <[email-masked]>,"'Ong, Lyndon'" <[email-masked]>,<[email-masked]>,<[email-masked]>
Subject: Re: RE: association object
Date: Wed, 19 Jul 2006 14:37:57 +0200

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: [email-masked] [mailto:[email-masked]] On Behalf
> Of Ong, Lyndon
> Sent: Tuesday, July 18, 2006 12:26 PM
> To: Lucy Yong; [email-masked]; [email-masked]
> 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: [email-masked] [mailto:[email-masked]] On Behalf
> Of Lucy Yong
> Sent: Tuesday, July 18, 2006 7:16 AM
> To: [email-masked]; [email-masked]
> 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
> 

Delivery-date: Tue, 18 Jul 2006 20:35:32 +0000
Date: Tue, 18 Jul 2006 22:34:42 +0200
From: dimitri papadimitriou <[email-masked]>
Reply-To:  [email-masked],  [email-masked]
To: "Dean Cheng (dcheng)" <[email-masked]>
CC:  [email-masked]
Subject: Re: Some comments on draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt

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 

Delivery-date: Tue, 18 Jul 2006 18:45:28 +0000
Date: Tue, 18 Jul 2006 13:44:25 -0500
From: Lucy Yong <[email-masked]>
Subject: RE: association object
To: "'Ong, Lyndon'" <[email-masked]>, [email-masked], [email-masked]

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: [email-masked] [mailto:[email-masked]] On Behalf
Of Ong, Lyndon
Sent: Tuesday, July 18, 2006 12:26 PM
To: Lucy Yong; [email-masked]; [email-masked]
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: [email-masked] [mailto:[email-masked]] On Behalf
Of Lucy Yong
Sent: Tuesday, July 18, 2006 7:16 AM
To: [email-masked]; [email-masked]
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>

<p class=MsoNormal><font size=2 color=blue face=Courier><span style='font-size:
10.0pt;font-family:Courier;color:blue'>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></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>

<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'>
[email-masked] [mailto:[email-masked]] <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>; [email-masked]; [email-masked]<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'>
[email-masked] [mailto:[email-masked]] <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> [email-masked];
[email-masked]<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>

<p class=MsoNormal><font size=2 face=Courier><span style='font-size:10.0pt;
font-family:Courier'>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></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'>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></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'>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)--

Delivery-date: Tue, 18 Jul 2006 18:07:44 +0000
Content-class: urn:content-classes:message
Subject: Some comments on draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt
Date: Tue, 18 Jul 2006 11:07:09 -0700
From: "Dean Cheng \(dcheng\)" <[email-masked]>
To: "dimitri papadimitriou" <[email-masked]>
Cc: <[email-masked]>

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><FONT face=3DArial size=3D2><SPAN=20
class=3D048492323-17072006>Dimitri,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D048492323-17072006></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D048492323-17072006>I've =
some comments=20
now as follows:</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D048492323-17072006></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D048492323-17072006>1) The =
third=20
paragraph of section 6.1, it says, "....However, an</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN =
class=3D048492323-17072006>&nbsp;&nbsp;&nbsp;=20
additional restriction MUST be applied such that the RC =
</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN =
class=3D048492323-17072006>&nbsp;&nbsp;&nbsp;=20
selection process takes into account that an upper level =
may</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN =
class=3D048492323-17072006>&nbsp;&nbsp;&nbsp;=20
be adjacent to one or more lower levels."</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D048492323-17072006></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN =
class=3D048492323-17072006>&nbsp;&nbsp;&nbsp;=20
It would be good to clarify the words "one or more lower=20
levels"</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN =
class=3D048492323-17072006>&nbsp;&nbsp;&nbsp;=20
here. From the sentence after that, it&nbsp;actually means&nbsp;one=20
</SPAN></FONT><FONT face=3DArial size=3D2><SPAN =
class=3D048492323-17072006>or=20
</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN =
class=3D048492323-17072006>&nbsp;&nbsp;&nbsp;=20
more areas at the lower levels.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D048492323-17072006></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D048492323-17072006>2) In =
section 6.1,=20
it says that the D bit is used together with the</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D048492323-17072006>&nbsp; =

&nbsp;"Associated Area ID" sub-tlv, as "an additional restriction".=20
In</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN =
class=3D048492323-17072006>&nbsp;&nbsp;&nbsp;=20
the same section, it does not mention the use of that=20
sub-tlv</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN =
class=3D048492323-17072006>&nbsp;&nbsp;&nbsp;=20
along with U bit.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D048492323-17072006></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN =
class=3D048492323-17072006>&nbsp;&nbsp; But in=20
section 6.2.1 and 6.2.2, it explicitly says that the=20
"Associated</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN =
class=3D048492323-17072006>&nbsp;&nbsp; Area=20
ID" sub-tlv is included when re-originating the opaque LSA =
</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D048492323-17072006>&nbsp;&nbsp;&nbsp;downward or upward.=20
</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D048492323-17072006></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN =
class=3D048492323-17072006>&nbsp;&nbsp;&nbsp;It=20
would require clarification and consistency here.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D048492323-17072006></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D048492323-17072006>3) In=20
section&nbsp;6.1 (Discovery and Selection), it describes a=20
method</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN =
class=3D048492323-17072006>&nbsp;&nbsp;&nbsp;=20
for&nbsp;"selecting" the RC that performs the upward/downward=20
dissemination</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN =
class=3D048492323-17072006>&nbsp;&nbsp;&nbsp;=20
of routing information. </SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D048492323-17072006></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><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</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN =
class=3D048492323-17072006>&nbsp;&nbsp;&nbsp;=20
but&nbsp;RC2 just becomes active with U-bit set and a higher Router ID ? =

</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D048492323-17072006></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN =
class=3D048492323-17072006>&nbsp;&nbsp;&nbsp; I=20
guess the same handling as OSPF DR's&nbsp;election can be used=20
for</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN =
class=3D048492323-17072006>&nbsp;&nbsp;&nbsp;=20
stability purpose, and also for consistency, and if so, needs to be =
stated=20
</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN =
class=3D048492323-17072006>&nbsp;&nbsp;&nbsp;=20
in this section. And for that matter, the word "selection" vs.=20
"election"</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN =
class=3D048492323-17072006>&nbsp;&nbsp;&nbsp;=20
does not really&nbsp;make much difference.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D048492323-17072006></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D048492323-17072006>4) In =
section 7.2,=20
it is also useful to add that the number of levels be =
under</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D048492323-17072006>&nbsp;&nbsp;&nbsp;&nbsp;policy=20
control.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D048492323-17072006></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D048492323-17072006>5) It =
would be=20
useful to add an interoperability section, which describes=20
how</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN =
class=3D048492323-17072006>&nbsp;&nbsp;&nbsp;=20
an traditional OSPF node/network interoperates (if need to)&nbsp;with an =
OSPF=20
</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN =
class=3D048492323-17072006>&nbsp;&nbsp;&nbsp;=20
node/network </SPAN></FONT><FONT face=3DArial size=3D2><SPAN=20
class=3D048492323-17072006>with extensions as described in this ID. =
E.g., a=20
reachable</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN =
class=3D048492323-17072006>&nbsp;&nbsp;&nbsp;=20
address (prefix) is advertised by an&nbsp;ABR normally but&nbsp;with=20
this&nbsp;ID, can also</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN =
class=3D048492323-17072006>&nbsp;&nbsp;=20
&nbsp;be</SPAN></FONT><FONT face=3DArial size=3D2><SPAN=20
class=3D048492323-17072006>&nbsp;advertised through =
hierarchy.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D048492323-17072006></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D048492323-17072006>Thanks</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D048492323-17072006>Dean&nbsp;</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D048492323-17072006></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D048492323-17072006></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D048492323-17072006></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D048492323-17072006></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D048492323-17072006></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D048492323-17072006></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D048492323-17072006></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D048492323-17072006></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D048492323-17072006></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D048492323-17072006></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D048492323-17072006></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D048492323-17072006></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D048492323-17072006></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D048492323-17072006>&nbsp;</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D048492323-17072006></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D048492323-17072006></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D048492323-17072006></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D048492323-17072006>&nbsp;&nbsp;</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D048492323-17072006></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D048492323-17072006></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D048492323-17072006></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D048492323-17072006></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D048492323-17072006></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D048492323-17072006></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D048492323-17072006></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D048492323-17072006>&nbsp;</SPAN></FONT><FONT face=3DArial =
size=3D2><SPAN=20
class=3D048492323-17072006>&nbsp;</SPAN></FONT></DIV></BODY></HTML>

------_=_NextPart_001_01C6AA94.FC1F4A82--

Delivery-date: Tue, 18 Jul 2006 17:49:57 +0000
Date: Tue, 18 Jul 2006 10:49:17 -0700
From: Richard Rabbat <[email-masked]>
To: Lucy Yong <[email-masked]>
CC: [email-masked]
Subject: Re: association object

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

Delivery-date: Tue, 18 Jul 2006 17:28:15 +0000
Content-class: urn:content-classes:message
Subject: RE: association object
Date: Tue, 18 Jul 2006 13:25:36 -0400
From: "Ong, Lyndon" <[email-masked]>
To: "Lucy Yong" <[email-masked]>, <[email-masked]>, <[email-masked]>

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: [email-masked] [mailto:[email-masked]] On
Behalf Of Lucy Yong
Sent: Tuesday, July 18, 2006 7:16 AM
To: [email-masked]; [email-masked]
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> [email-masked]=20
[mailto:[email-masked]] <B>On Behalf Of </B>Lucy =
Yong<BR><B>Sent:</B>=20
Tuesday, July 18, 2006 7:16 AM<BR><B>To:</B> [email-masked];=20
[email-masked]<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--

Delivery-date: Tue, 18 Jul 2006 14:18:28 +0000
Date: Tue, 18 Jul 2006 09:16:24 -0500
From: Lucy Yong <[email-masked]>
Subject: association object
To: [email-masked], [email-masked]

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>

<p class=MsoNormal><font size=2 face=Courier><span style='font-size:10.0pt;
font-family:Courier'>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></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'>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></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'>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)--

Delivery-date: Tue, 18 Jul 2006 01:54:56 +0000
Content-class: urn:content-classes:message
Subject: RE: VLAN label range requirement
Date: Mon, 17 Jul 2006 21:53:41 -0400
From: "Stephen Shew" <[email-masked]>
To: <[email-masked]>

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:[email-masked]]=20
Sent: July 12, 2006 09:53
To: Ong, Lyndon
Cc: [email-masked]; Shew, Stephen (CAR:Q840); Adrian
Farrel; [email-masked]
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
>=20
> Lyndon=20
>=20
> From: dimitri papadimitriou [mailto:[email-masked]]=20
> Sent: Wednesday, July 12, 2006 6:33 AM
> To: Ong, Lyndon
> Cc: Stephen Shew; Adrian Farrel; [email-masked]
> 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
>>
>>From: [email-masked] [mailto:[email-masked]] On=20
>>Behalf Of Stephen Shew
>>Sent: Tuesday, July 11, 2006 8:09 PM
>>To: Adrian Farrel; [email-masked]
>>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
>>
>>Sent: July 11, 2006 18:42
>>To: Shew, Stephen (CAR:Q840); [email-masked]
>>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
>>From: "Stephen Shew" <[email-masked]>
>>To: <[email-masked]>
>>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
>>[email-masked]
>>Telephone: +1 613 763 2462 / ESN 393 2462
>>
>>
>>
>>
>>.
>>
>=20
>=20
> .
>=20

Delivery-date: Mon, 17 Jul 2006 20:52:44 +0000
Reply-To: "CHO, JAI HYUNG" <[email-masked]>
From: "CHO, JAI HYUNG" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: 
Bcc: 
Date: Tue, 18 Jul 2006 05:55:00 +0900
Subject: RE: Next steps for GMPLS control of Ethernet
Comment: GQ19@|@ZEk=E?,18?x, D38.>n@L4u3]?,18F@, 4c4g
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" <[email-masked]> 
?? ??: 2006-07-18 ?? 3:24:34 
?? ??: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]> 
??: "Ross Callon" <[email-masked]>, "Dimitri Papadimitriou" <[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>, "[email-masked]" <[email-masked]>, "Loa Andersson" <[email-masked]> 
??: 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 

Delivery-date: Mon, 17 Jul 2006 18:26:44 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: "Ross Callon" <[email-masked]>, <[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>, "Dimitri Papadimitriou" <[email-masked]>, "Loa Andersson" <[email-masked]>
Subject: Next steps for GMPLS control of Ethernet
Date: Mon, 17 Jul 2006 19:24:34 +0100
Organization: Old Dog Consulting

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 

Delivery-date: Mon, 17 Jul 2006 10:20:19 +0000
To: Freek Dijkstra <[email-masked]>
Cc: [email-masked]
Subject: Re: Ethernet interface in a TDM device: FSC, TDM, or L2SC?
From: [email-masked]
Date: Mon, 17 Jul 2006 12:20:12 +0200

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 <[email-masked]>
Sent by: [email-masked]
17/07/2006 12:05
 
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     [email-masked]
        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

Delivery-date: Mon, 17 Jul 2006 10:05:58 +0000
Date: Mon, 17 Jul 2006 12:05:37 +0200
From: Freek Dijkstra <[email-masked]>
To: [email-masked]
Cc: [email-masked]
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

Delivery-date: Mon, 17 Jul 2006 09:40:43 +0000
To: Freek Dijkstra <[email-masked]>
Cc: [email-masked]
Subject: Re: Ethernet interface in a TDM device: FSC, TDM, or L2SC?
From: [email-masked]
Date: Mon, 17 Jul 2006 11:40:33 +0200

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 <[email-masked]>
Sent by: [email-masked]
17/07/2006 11:25
 
        To:     [email-masked]
        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

Delivery-date: Mon, 17 Jul 2006 09:26:57 +0000
Date: Mon, 17 Jul 2006 11:25:09 +0200
From: Freek Dijkstra <[email-masked]>
To: [email-masked]
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

Delivery-date: Fri, 14 Jul 2006 16:47:17 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Mack-Crane, T. Benjamin" <[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>
Cc: <[email-masked]>
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

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" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>; "Brungard, Deborah A, ALABS" 
<[email-masked]>
Cc: <[email-masked]>
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

> From: [email-masked] [mailto:[email-masked]] On
Behalf
> Of Adrian Farrel
> Sent: Wednesday, July 12, 2006 2:54 PM
> To: Brungard, Deborah A, ALABS
> Cc: [email-masked]
> 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
============================================================

Delivery-date: Fri, 14 Jul 2006 16:44:21 +0000
Content-class: urn:content-classes:message
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
From: "Mack-Crane, T. Benjamin" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>
Cc: <[email-masked]>

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

> From: [email-masked] [mailto:[email-masked]] On
Behalf
> Of Adrian Farrel
> Sent: Wednesday, July 12, 2006 2:54 PM
> To: Brungard, Deborah A, ALABS
> Cc: [email-masked]
> 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

Delivery-date: Wed, 12 Jul 2006 19:54:41 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Brungard, Deborah A, ALABS" <[email-masked]>
Cc: <[email-masked]>
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

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 

Delivery-date: Wed, 12 Jul 2006 19:12:29 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: OSPF ASON Routing Solution
Date: Wed, 12 Jul 2006 20:10:05 +0100
Organization: Old Dog Consulting

Hi,

Thanks,
Adrian

Delivery-date: Wed, 12 Jul 2006 15:01:34 +0000
Content-class: urn:content-classes:message
Subject: RE: Revision 02 of draft-caviglia-ccamp-pc-and-sc-reqs
Date: Wed, 12 Jul 2006 10:00:31 -0500
From: "Bardalai, Snigdho" <[email-masked]>
To: "Diego Caviglia" <[email-masked]>, <[email-masked]>

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: [email-masked] on behalf of Diego Caviglia
Sent: Tue 7/11/2006 3:08 PM
To: [email-masked]
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> =
[email-masked] on =0A=
behalf of Diego Caviglia<BR><B>Sent:</B> Tue 7/11/2006 3:08 =
PM<BR><B>To:</B> =0A=
[email-masked]<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--

Delivery-date: Wed, 12 Jul 2006 14:55:39 +0000
Content-class: urn:content-classes:message
Subject: RE: VLAN label range requirement
Date: Wed, 12 Jul 2006 10:51:53 -0400
From: "Ong, Lyndon" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: "Stephen Shew" <[email-masked]>, "Adrian Farrel" <[email-masked]>, <[email-masked]>

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:[email-masked]]=20
Sent: Wednesday, July 12, 2006 6:53 AM
To: Ong, Lyndon
Cc: [email-masked]; Stephen Shew; Adrian Farrel;
[email-masked]
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
>=20
> Lyndon=20
>=20
> From: dimitri papadimitriou [mailto:[email-masked]]=20
> Sent: Wednesday, July 12, 2006 6:33 AM
> To: Ong, Lyndon
> Cc: Stephen Shew; Adrian Farrel; [email-masked]
> 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
>>
>>From: [email-masked] [mailto:[email-masked]] On=20
>>Behalf Of Stephen Shew
>>Sent: Tuesday, July 11, 2006 8:09 PM
>>To: Adrian Farrel; [email-masked]
>>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
>>
>>Sent: July 11, 2006 18:42
>>To: Shew, Stephen (CAR:Q840); [email-masked]
>>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
>>From: "Stephen Shew" <[email-masked]>
>>To: <[email-masked]>
>>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
>>[email-masked]
>>Telephone: +1 613 763 2462 / ESN 393 2462
>>
>>
>>
>>
>>.
>>
>=20
>=20
> .
>=20

Delivery-date: Wed, 12 Jul 2006 13:52:51 +0000
Date: Wed, 12 Jul 2006 15:52:49 +0200
From: dimitri papadimitriou <[email-masked]>
Reply-To:  [email-masked],  [email-masked]
To: "Ong, Lyndon" <[email-masked]>
CC:  [email-masked], Stephen Shew <[email-masked]>,  Adrian Farrel <[email-masked]>, [email-masked]
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 
> any proposals along those lines, it would then liaise this to CCAMP for
> its
> consideration.
> 
> Cheers,
> 
> Lyndon 
> 
> From: dimitri papadimitriou [mailto:[email-masked]] 
> Sent: Wednesday, July 12, 2006 6:33 AM
> To: Ong, Lyndon
> Cc: Stephen Shew; Adrian Farrel; [email-masked]
> 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
>>
>>Behalf Of Stephen Shew
>>Sent: Tuesday, July 11, 2006 8:09 PM
>>To: Adrian Farrel; [email-masked]
>>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
>>
>>Sent: July 11, 2006 18:42
>>To: Shew, Stephen (CAR:Q840); [email-masked]
>>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
>>From: "Stephen Shew" <[email-masked]>
>>To: <[email-masked]>
>>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
>>[email-masked]
>>Telephone: +1 613 763 2462 / ESN 393 2462
>>
>>
>>
>>
>>.
>>
> 
> 
> .
> 

Delivery-date: Wed, 12 Jul 2006 13:47:36 +0000
Content-class: urn:content-classes:message
Subject: RE: VLAN label range requirement
Date: Wed, 12 Jul 2006 09:41:22 -0400
From: "Ong, Lyndon" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, "Ong, Lyndon" <[email-masked]>
Cc: "Stephen Shew" <[email-masked]>, "Adrian Farrel" <[email-masked]>, <[email-masked]>

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:[email-masked]]=20
Sent: Wednesday, July 12, 2006 6:33 AM
To: Ong, Lyndon
Cc: Stephen Shew; Adrian Farrel; [email-masked]
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
> From: [email-masked] [mailto:[email-masked]] On=20
> Behalf Of Stephen Shew
> Sent: Tuesday, July 11, 2006 8:09 PM
> To: Adrian Farrel; [email-masked]
> 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
> Sent: July 11, 2006 18:42
> To: Shew, Stephen (CAR:Q840); [email-masked]
> 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
> From: "Stephen Shew" <[email-masked]>
> To: <[email-masked]>
> 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
> [email-masked]
> Telephone: +1 613 763 2462 / ESN 393 2462
>=20
>=20
>=20
>=20
> .
>=20

Delivery-date: Wed, 12 Jul 2006 13:32:59 +0000
Date: Wed, 12 Jul 2006 15:32:35 +0200
From: dimitri papadimitriou <[email-masked]>
Reply-To:  [email-masked],  [email-masked]
To: "Ong, Lyndon" <[email-masked]>
CC: Stephen Shew <[email-masked]>, Adrian Farrel <[email-masked]>,  [email-masked]
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 
> 
> Behalf Of Stephen Shew
> Sent: Tuesday, July 11, 2006 8:09 PM
> To: Adrian Farrel; [email-masked]
> 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 
> 
> Sent: July 11, 2006 18:42
> To: Shew, Stephen (CAR:Q840); [email-masked]
> 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
> From: "Stephen Shew" <[email-masked]>
> To: <[email-masked]>
> 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
> [email-masked]
> Telephone: +1 613 763 2462 / ESN 393 2462
> 
> 
> 
> 
> .
> 

Delivery-date: Wed, 12 Jul 2006 12:32:35 +0000
Content-class: urn:content-classes:message
Subject: RE: VLAN label range requirement
Date: Wed, 12 Jul 2006 08:30:48 -0400
From: "Ong, Lyndon" <[email-masked]>
To: "Stephen Shew" <[email-masked]>, "Adrian Farrel" <[email-masked]>, <[email-masked]>

That was my interpretation also, not sure if that
came through on the slides.

Lyndon=20

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Stephen Shew
Sent: Tuesday, July 11, 2006 8:09 PM
To: Adrian Farrel; [email-masked]
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:[email-masked]]
Sent: July 11, 2006 18:42
To: Shew, Stephen (CAR:Q840); [email-masked]
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" <[email-masked]>
To: <[email-masked]>
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
[email-masked]
Telephone: +1 613 763 2462 / ESN 393 2462

Delivery-date: Wed, 12 Jul 2006 03:10:25 +0000
Content-class: urn:content-classes:message
Subject: RE: VLAN label range requirement
Date: Tue, 11 Jul 2006 23:09:22 -0400
From: "Stephen Shew" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>, <[email-masked]>

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:[email-masked]]=20
Sent: July 11, 2006 18:42
To: Shew, Stephen (CAR:Q840); [email-masked]
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" <[email-masked]>
To: <[email-masked]>
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
[email-masked]
Telephone: +1 613 763 2462 / ESN 393 2462

Delivery-date: Wed, 12 Jul 2006 01:16:59 +0000
From: "Jaihyung Cho" <[email-masked]>
To: "'Brungard, Deborah A, ALABS'" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: RE: Future of the GELS mailing list
Date: Wed, 12 Jul 2006 10:16:05 +0900

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

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Brungard, Deborah A, ALABS
> Sent: Wednesday, July 12, 2006 12:18 AM
> To: Loa Andersson; Adrian Farrel
> Cc: [email-masked]; [email-masked];
[email-masked];
> 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
> 
> Behalf Of Loa Andersson
> Sent: Tuesday, July 11, 2006 10:27 AM
> To: Adrian Farrel
> Cc: Don Fedyk; [email-masked]; [email-masked];
> [email-masked]
> 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:  [email-masked]
>                                            [email-masked]
> 
> 
> _______________________________________________
> gels mailing list
> [email-masked]
> https://rtg.ietf.org/mailman/listinfo/gels

Delivery-date: Wed, 12 Jul 2006 00:07:58 +0000
Date: Wed, 12 Jul 2006 02:07:04 +0200
From: dimitri papadimitriou <[email-masked]>
Reply-To:  [email-masked],  [email-masked]
To: Diego Caviglia <[email-masked]>
CC:  [email-masked], ccamp <[email-masked]>
Subject: Re: Revision 02 of draft-caviglia-ccamp-pc-and-sc-reqs

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 [email-masked]; Please respond to 
> [email-masked]
> To:     Diego Caviglia <[email-masked]>
> cc:     [email-masked] 
> 
> 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
>>
>>
> 
> 
> 
> 
> 

Delivery-date: Tue, 11 Jul 2006 22:42:29 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Stephen Shew" <[email-masked]>, <[email-masked]>
Subject: Re: VLAN label range requirement
Date: Tue, 11 Jul 2006 23:41:52 +0100
Organization: Old Dog Consulting

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" <[email-masked]>
To: <[email-masked]>
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
[email-masked]
Telephone: +1 613 763 2462 / ESN 393 2462

Delivery-date: Tue, 11 Jul 2006 22:29:55 +0000
Sensitivity: 
Subject: Re: Revision 02 of draft-caviglia-ccamp-pc-and-sc-reqs
To: [email-masked], [email-masked]
Cc: "ccamp" <[email-masked]>
From: "Diego Caviglia" <[email-masked]>
Date: Wed, 12 Jul 2006 00:29:42 +0200

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 <[email-masked]> on 12/07/2006 00.06.21

Please respond to [email-masked]; Please respond to
       [email-masked]

To:    Diego Caviglia <[email-masked]>
cc:    [email-masked]

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

Delivery-date: Tue, 11 Jul 2006 22:07:02 +0000
Date: Wed, 12 Jul 2006 00:06:21 +0200
From: dimitri papadimitriou <[email-masked]>
Reply-To:  [email-masked],  [email-masked]
To: Diego Caviglia <[email-masked]>
CC:  [email-masked]
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
> 
> 

Delivery-date: Tue, 11 Jul 2006 20:55:19 +0000
Date: Tue, 11 Jul 2006 22:54:40 +0200
From: Freek Dijkstra <[email-masked]>
To: [email-masked]
Subject: Short question on LSA

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

Delivery-date: Tue, 11 Jul 2006 20:08:34 +0000
Sensitivity: 
To: [email-masked]
Subject: Revision 02 of draft-caviglia-ccamp-pc-and-sc-reqs
From: "Diego Caviglia" <[email-masked]>
Date: Tue, 11 Jul 2006 22:08:10 +0200

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

Delivery-date: Tue, 11 Jul 2006 19:34:03 +0000
Date: Tue, 11 Jul 2006 21:33:08 +0200
From: dimitri papadimitriou <[email-masked]>
Reply-To:  [email-masked],  [email-masked]
To: Igor Bryskin <[email-masked]>
CC: Stephen Shew <[email-masked]>,  [email-masked]
Subject: Re: Comments (2) on draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt

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 [email-masked] 
> Telephone: +1 613 763 2462 / ESN 393 2462
> 

Delivery-date: Tue, 11 Jul 2006 16:31:39 +0000
From: "Igor Bryskin" <[email-masked]>
To: "Stephen Shew" <[email-masked]>, <[email-masked]>
Subject: Re: Comments (2) on draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt
Date: Tue, 11 Jul 2006 12:30:39 -0400

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
  [email-masked]=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><FONT face=3D"Times New Roman" color=3D#008080 size=3D2>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.</FONT></DIV>
<DIV><FONT color=3D#008080 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#008080 size=3D2>Agree 100%</FONT></DIV>
<DIV><FONT color=3D#008080 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#008080 size=3D2>Igor</FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <P><FONT face=3DArial color=3D#000000 size=3D2>Stephen Shew</FONT> =
<BR><FONT=20
  face=3DArial color=3D#000000 size=3D2>Metro Ethernet Networks</FONT> =
<BR><FONT=20
  face=3DArial color=3D#000000 size=3D2>Nortel</FONT> <BR><FONT =
face=3DArial=20
  color=3D#000000 size=3D2>[email-masked]</FONT> <BR><FONT =
face=3DArial=20
  color=3D#000000 size=3D2>Telephone: +1 613 763 2462 / ESN 393 =
2462</FONT>=20
</P></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0062_01C6A4E5.D131B680--

Delivery-date: Tue, 11 Jul 2006 15:55:13 +0000
Date: Tue, 11 Jul 2006 11:54:44 -0400
From: Eric W Gray <[email-masked]>
Reply-To: [email-masked]
To: "Andrew G. Malis" <[email-masked]>
CC: "[email-masked]" <[email-masked]>, Adrian Farrel <[email-masked]>, [email-masked], [email-masked], [email-masked], Don Fedyk <[email-masked]>
Subject: Re: Future of the GELS mailing list

--------------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 [email-masked] <mailto:[email-masked]>).  This should 
> happen either on an IEEE-associated list, or a private list not 
> associated with the IETF.
>  
> Thanks,
> Andy
>
>  
> On 7/11/06, [email-masked] 
> <mailto:[email-masked]> 
> <[email-masked] 
> <mailto:[email-masked]>> 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" < [email-masked] <mailto:[email-masked]>>
>     Sent by: [email-masked] <mailto:[email-masked]>
>     11/07/2006 15:35
>     Please respond to "Adrian Farrel"
>
>            To:     "Don Fedyk" < [email-masked]
>     <mailto:[email-masked]>>, Dimitri
>     PAPADIMITRIOU/BE/ALCATEL@ALCATEL
>            cc:     <[email-masked] <mailto:[email-masked]>>, <
>     [email-masked] <mailto:[email-masked]>>
>            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
>     [email-masked] <mailto:[email-masked]>
>     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="[email-masked]"  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:[email-masked]">[email-masked]</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:[email-masked]">[email-masked]</a></b>
&lt;<a href="mailto:[email-masked]">[email-masked]
  </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:[email-masked]">
[email-masked]</a>&gt;<br>
Sent by: <a href="mailto:[email-masked]">[email-masked]</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:[email-masked]">[email-masked]</a>&gt;,
Dimitri<br>
PAPADIMITRIOU/BE/ALCATEL@ALCATEL<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; cc:&nbsp;&nbsp;&nbsp;&nbsp; &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;,
&lt;<a href="mailto:[email-masked]">
[email-masked]</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:[email-masked]">[email-masked]</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--

Delivery-date: Tue, 11 Jul 2006 15:45:03 +0000
Content-class: urn:content-classes:message
Subject: VLAN label range requirement
Date: Tue, 11 Jul 2006 11:44:13 -0400
From: "Stephen Shew" <[email-masked]>
To: <[email-masked]>

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
[email-masked]
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>

<P><FONT COLOR=3D"#008080" SIZE=3D2 FACE=3D"Times New Roman">&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;</FONT></P>

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

<P><FONT COLOR=3D"#008080" SIZE=3D2 FACE=3D"Times New Roman">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.</FONT></P>

<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">[email-masked]</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--

Delivery-date: Tue, 11 Jul 2006 14:45:08 +0000
Content-class: urn:content-classes:message
Subject: RE: Comments (2) on draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt
Date: Tue, 11 Jul 2006 10:43:59 -0400
From: "Ong, Lyndon" <[email-masked]>
To: "Stephen Shew" <[email-masked]>, <[email-masked]>

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: [email-masked] [mailto:[email-masked]] On
Behalf Of Stephen Shew
Sent: Tuesday, July 11, 2006 7:14 AM
To: [email-masked]
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
[email-masked]=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><SPAN class=3D892174114-11072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Hi,</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D892174114-11072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D892174114-11072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>I agree with Stephen, especially on the last =
item: it's=20
better to head off any confusion now between</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D892174114-11072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>the data plane node identifier and the routing =
controller=20
identifier by keeping these separate.&nbsp;</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D892174114-11072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D892174114-11072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Cheers,</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D892174114-11072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D892174114-11072006><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> [email-masked]=20
[mailto:[email-masked]] <B>On Behalf Of </B>Stephen=20
Shew<BR><B>Sent:</B> Tuesday, July 11, 2006 7:14 AM<BR><B>To:</B>=20
[email-masked]<BR><B>Subject:</B> Comments (2) on=20
draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt<BR></FONT><BR></DIV>
<DIV></DIV><!-- Converted from text/rtf format -->
<P><FONT face=3D"Times New Roman" color=3D#008080 size=3D2>Two comments =
on the draft I=20
have are:</FONT> </P>
<P><FONT face=3D"Times New Roman" color=3D#008080 size=3D2>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.</FONT></P>
<P><FONT face=3D"Times New Roman" color=3D#008080 size=3D2>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.</FONT></P>
<P><FONT face=3DArial color=3D#000000 size=3D2>Stephen Shew</FONT> =
<BR><FONT=20
face=3DArial color=3D#000000 size=3D2>Metro Ethernet Networks</FONT> =
<BR><FONT=20
face=3DArial color=3D#000000 size=3D2>Nortel</FONT> <BR><FONT =
face=3DArial color=3D#000000=20
size=3D2>[email-masked]</FONT> <BR><FONT face=3DArial color=3D#000000 =

size=3D2>Telephone: +1 613 763 2462 / ESN 393 2462</FONT> =
</P></BODY></HTML>

------_=_NextPart_001_01C6A4F8.7210E9D0--

Delivery-date: Tue, 11 Jul 2006 14:27:13 +0000
Date: Tue, 11 Jul 2006 16:26:46 +0200
From: Loa Andersson <[email-masked]>
Organization: Acreo AB
To: Adrian Farrel <[email-masked]>
CC: Don Fedyk <[email-masked]>,  [email-masked],  [email-masked],  [email-masked]
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

-- 
Loa Andersson

Principal Networking Architect
Acreo AB                           phone:  +46 8 632 77 14
Isafjordsgatan 22                  mobile: +46 739 81 21 64
Kista, Sweden                      email:  [email-masked]
                                           [email-masked]

Delivery-date: Tue, 11 Jul 2006 14:24:14 +0000
To: "Don Fedyk" <[email-masked]>
Cc: "Adrian Farrel" <[email-masked]>, "Andrew G. Malis" <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: RE: Future of the GELS mailing list
From: [email-masked]
Date: Tue, 11 Jul 2006 16:23:15 +0200

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" <[email-masked]>
11/07/2006 16:06
 
        To:     "Andrew G. Malis" <[email-masked]>, Dimitri 
PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     "Adrian Farrel" <[email-masked]>, 
<[email-masked]>, <[email-masked]>, <[email-masked]>
        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:[email-masked]] 
Sent: Tuesday, July 11, 2006 10:01 AM
To: [email-masked]
Cc: Adrian Farrel; [email-masked]; [email-masked]; 
[email-masked]; 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 [email-masked]).  This should happen either on an IEEE-associated 
list, or a private list not associated with the IETF. 
 
Thanks,
Andy

On 7/11/06, [email-masked] <
[email-masked] > 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" < [email-masked]>
Sent by: [email-masked]
11/07/2006 15:35
Please respond to "Adrian Farrel"

       To:     "Don Fedyk" < [email-masked]>, Dimitri
PAPADIMITRIOU/BE/ALCATEL@ALCATEL
       cc:     <[email-masked]>, < [email-masked]>
       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
[email-masked]
https://rtg.ietf.org/mailman/listinfo/gels

Delivery-date: Tue, 11 Jul 2006 14:18:36 +0000
Content-class: urn:content-classes:message
Subject: RE: Future of the GELS mailing list
Date: Tue, 11 Jul 2006 10:06:19 -0400
From: "Don Fedyk" <[email-masked]>
To: "Andrew G. Malis" <[email-masked]>, <[email-masked]>
Cc: "Adrian Farrel" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>

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:[email-masked]]=20
	Sent: Tuesday, July 11, 2006 10:01 AM
	To: [email-masked]
	Cc: Adrian Farrel; [email-masked]; [email-masked];
[email-masked]; 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 [email-masked]).  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, [email-masked]
<[email-masked] > 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" < [email-masked]
<mailto:[email-masked]> >
		Sent by: [email-masked]
		11/07/2006 15:35
		Please respond to "Adrian Farrel"
	=09
		       To:     "Don Fedyk" < [email-masked]>,
Dimitri
		PAPADIMITRIOU/BE/ALCATEL@ALCATEL
		       cc:     <[email-masked]>, < [email-masked]
<mailto:[email-masked]> >
		       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
		[email-masked]
		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><SPAN class=3D900340214-11072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Andy</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>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:[email-masked]] <BR><B>Sent:</B> Tuesday, July 11, 2006 =
10:01=20
  AM<BR><B>To:</B> [email-masked]<BR><B>Cc:</B> Adrian =
Farrel;=20
  [email-masked]; [email-masked]; [email-masked]; =
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:[email-masked]">[email-masked]</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:[email-masked]">Dimitri.Papadimitriou@al=
catel.be</A></B>=20
  &lt;<A=20
  =
href=3D"mailto:[email-masked]">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:[email-masked]"> =
[email-masked]</A>&gt;<BR>Sent by:=20
    <A=20
    =
href=3D"mailto:[email-masked]">[email-masked]</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:[email-masked]">[email-masked]</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:[email-masked]">[email-masked]</A>&gt;, =
&lt;<A=20
    href=3D"mailto:[email-masked]">=20
    [email-masked]</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:[email-masked]">[email-masked]</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--

Delivery-date: Tue, 11 Jul 2006 14:17:31 +0000
To: "Andrew G. Malis" <[email-masked]>
Cc: "Adrian Farrel" <[email-masked]>, [email-masked], "Don Fedyk" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Future of the GELS mailing list
From: [email-masked]
Date: Tue, 11 Jul 2006 16:14:51 +0200

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" <[email-masked]>
Sent by: [email-masked]
11/07/2006 16:00
 
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     "Adrian Farrel" <[email-masked]>, [email-masked], 
[email-masked], [email-masked], "Don Fedyk" 
<[email-masked]>
        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 [email-masked]).  This should happen either on an IEEE-associated 
list, or a private list not associated with the IETF. 
 
Thanks,
Andy

On 7/11/06, [email-masked] <
[email-masked] > 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" < [email-masked]>
Sent by: [email-masked]
11/07/2006 15:35
Please respond to "Adrian Farrel"

       To:     "Don Fedyk" < [email-masked]>, Dimitri
PAPADIMITRIOU/BE/ALCATEL@ALCATEL
       cc:     <[email-masked]>, < [email-masked]>
       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
[email-masked]
https://rtg.ietf.org/mailman/listinfo/gels

Delivery-date: Tue, 11 Jul 2006 14:16:48 +0000
Content-class: urn:content-classes:message
Subject: Comments (2) on draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt
Date: Tue, 11 Jul 2006 10:13:33 -0400
From: "Stephen Shew" <[email-masked]>
To: <[email-masked]>

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
[email-masked]
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>

<P><FONT COLOR=3D"#008080" SIZE=3D2 FACE=3D"Times New Roman">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.</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">[email-masked]</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--

Delivery-date: Tue, 11 Jul 2006 14:06:06 +0000
Content-class: urn:content-classes:message
Subject: RE: Future of the GELS mailing list
Date: Tue, 11 Jul 2006 16:05:36 +0200
From: "MEURIC Julien RD-CORE-LAN" <[email-masked]>
To: "Don Fedyk" <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

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: [email-masked] [mailto:[email-masked]] On
Behalf Of Don Fedyk

Hi Dimitri
> From: [email-masked]=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" <[email-masked]>
> 11/07/2006 15:35
> Please respond to "Adrian Farrel"
> =20
>         To:     "Don Fedyk" <[email-masked]>, Dimitri=20
> PAPADIMITRIOU/BE/ALCATEL@ALCATEL
>         cc:     <[email-masked]>, <[email-masked]>
>         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
[email-masked]
https://rtg.ietf.org/mailman/listinfo/gels

Delivery-date: Tue, 11 Jul 2006 14:01:02 +0000
Date: Tue, 11 Jul 2006 10:00:48 -0400
From: "Andrew G. Malis" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Re: Future of the GELS mailing list
Cc: "Adrian Farrel" <[email-masked]>, [email-masked], [email-masked],  [email-masked], "Don Fedyk" <[email-masked]>

------=_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
[email-masked]).  This should happen either on an IEEE-associated list,
or a private list not associated with the IETF.

Thanks,
Andy

On 7/11/06, [email-masked] <
[email-masked]> 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" <[email-masked]>
> 11/07/2006 15:35
> Please respond to "Adrian Farrel"
>
>        To:     "Don Fedyk" <[email-masked]>, Dimitri
> PAPADIMITRIOU/BE/ALCATEL@ALCATEL
>        cc:     <[email-masked]>, <[email-masked]>
>        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
> [email-masked]
> 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:[email-masked]">[email-masked]</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:[email-masked]">[email-masked]</a></b> &lt;<a href="mailto:[email-masked]">[email-masked]
</a>&gt; wrote:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">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>&quot;Adrian Farrel&quot; &lt;<a href="mailto:[email-masked]">
[email-masked]</a>&gt;<br>Sent by: <a href="mailto:[email-masked]">[email-masked]</a><br>11/07/2006 15:35<br>Please respond to &quot;Adrian Farrel&quot;<br><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; To:&nbsp;&nbsp;&nbsp;&nbsp; &quot;Don Fedyk&quot; &lt;
<a href="mailto:[email-masked]">[email-masked]</a>&gt;, Dimitri<br>PAPADIMITRIOU/BE/ALCATEL@ALCATEL<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; cc:&nbsp;&nbsp;&nbsp;&nbsp; &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;, &lt;<a href="mailto:[email-masked]">
[email-masked]</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:[email-masked]">[email-masked]</a><br><a href="https://rtg.ietf.org/mailman/listinfo/gels">https://rtg.ietf.org/mailman/listinfo/gels</a><br></blockquote></div><br>

------=_Part_104483_20182149.1152626448357--

Delivery-date: Tue, 11 Jul 2006 13:57:26 +0000
Content-class: urn:content-classes:message
Subject: RE: Future of the GELS mailing list
Date: Tue, 11 Jul 2006 09:56:16 -0400
From: "Don Fedyk" <[email-masked]>
To: <[email-masked]>, "Adrian Farrel" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>

Hi Dimitri
> From: [email-masked]=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" <[email-masked]>
> 11/07/2006 15:35
> Please respond to "Adrian Farrel"
> =20
>         To:     "Don Fedyk" <[email-masked]>, Dimitri=20
> PAPADIMITRIOU/BE/ALCATEL@ALCATEL
>         cc:     <[email-masked]>, <[email-masked]>
>         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

Delivery-date: Tue, 11 Jul 2006 13:44:53 +0000
To: "Adrian Farrel" <[email-masked]>
Cc: [email-masked], "Don Fedyk" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Future of the GELS mailing list
From: [email-masked]
Date: Tue, 11 Jul 2006 15:44:06 +0200

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" <[email-masked]>
Sent by: [email-masked]
11/07/2006 15:35
Please respond to "Adrian Farrel"
 
        To:     "Don Fedyk" <[email-masked]>, Dimitri 
PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     <[email-masked]>, <[email-masked]>
        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 

Delivery-date: Tue, 11 Jul 2006 13:36:10 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Don Fedyk" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: Re: Future of the GELS mailing list
Date: Tue, 11 Jul 2006 14:35:49 +0100
Organization: Old Dog Consulting

> 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 

Delivery-date: Tue, 11 Jul 2006 13:34:34 +0000
Content-class: urn:content-classes:message
Subject: RE: Future of the GELS mailing list
Date: Tue, 11 Jul 2006 16:34:09 +0200
From: "Nurit Sprecher" <[email-masked]>
To: "Diego Caviglia" <[email-masked]>, <[email-masked]>
Cc: "gels" <[email-masked]>, "ccamp" <[email-masked]>, "<Dimitri.Papadimitriou" <[email-masked]>, "dpapadimitriou" <[email-masked]>, " Adrian Farrel  <adrian" <[email-masked]>, "owner-ccamp" <[email-masked]>

TO me as well=20

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Diego Caviglia
Sent: Tuesday, July 11, 2006 15:32
To: [email-masked]
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" <[email-masked]>@rtg.ietf.org on 11/07/2006 15.27.04

Sent by:    [email-masked]

To:    <[email-masked]>, "Adrian Farrel"
       <[email-masked]>
cc:    [email-masked], [email-masked], [email-masked],
       [email-masked]

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

> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of=20
> [email-masked]
> Sent: Tuesday, July 11, 2006 8:17 AM
> To: Adrian Farrel
> Cc: [email-masked]; [email-masked]; [email-masked];=20
> [email-masked]
> 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 <[email-masked]>
> 11/07/2006 11:34
>         To:     Adrian Farrel <[email-masked]>,
> <[email-masked]>
>         cc:     <[email-masked]>
>         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" <[email-masked]> 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
[email-masked]
https://rtg.ietf.org/mailman/listinfo/gels

_______________________________________________
gels mailing list
[email-masked]
https://rtg.ietf.org/mailman/listinfo/gels

Delivery-date: Tue, 11 Jul 2006 13:32:01 +0000
Sensitivity: 
Subject: RE: Future of the GELS mailing list
To: [email-masked]
Cc: "<Dimitri.Papadimitriou" <[email-masked]>, ""Adrian Farrel" <adrian" <[email-masked]>, "ccamp" <[email-masked]>, "gels" <[email-masked]>, "owner-ccamp" <[email-masked]>, "dpapadimitriou" <[email-masked]>
From: "Diego Caviglia" <[email-masked]>
Date: Tue, 11 Jul 2006 15:31:45 +0200

Sounds good to me.

Diego

"Don Fedyk" <[email-masked]>@rtg.ietf.org on 11/07/2006 15.27.04

Sent by:    [email-masked]

To:    <[email-masked]>, "Adrian Farrel"
       <[email-masked]>
cc:    [email-masked], [email-masked], [email-masked],
       [email-masked]

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

> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Tuesday, July 11, 2006 8:17 AM
> To: Adrian Farrel
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> 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 <[email-masked]>
> 11/07/2006 11:34
>         To:     Adrian Farrel <[email-masked]>,
> <[email-masked]>
>         cc:     <[email-masked]>
>         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" <[email-masked]> 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
[email-masked]
https://rtg.ietf.org/mailman/listinfo/gels

Delivery-date: Tue, 11 Jul 2006 13:28:00 +0000
Content-class: urn:content-classes:message
Subject: RE: Future of the GELS mailing list
Date: Tue, 11 Jul 2006 09:27:04 -0400
From: "Don Fedyk" <[email-masked]>
To: <[email-masked]>, "Adrian Farrel" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>

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

> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of=20
> [email-masked]
> Sent: Tuesday, July 11, 2006 8:17 AM
> To: Adrian Farrel
> Cc: [email-masked]; [email-masked];=20
> [email-masked]; [email-masked]
> 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 <[email-masked]>
> 11/07/2006 11:34
> =20
>         To:     Adrian Farrel <[email-masked]>,=20
> <[email-masked]>
>         cc:     <[email-masked]>
>         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" <[email-masked]> 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

Delivery-date: Tue, 11 Jul 2006 13:25:51 +0000
Content-class: urn:content-classes:message
Subject: RE: Future of the GELS mailing list
Date: Tue, 11 Jul 2006 16:25:21 +0200
From: "Nurit Sprecher" <[email-masked]>
To: <[email-masked]>, "Ping Pan" <[email-masked]>
Cc: <[email-masked]>, "Adrian Farrel" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>

I agree.
=20

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of [email-masked]
Sent: Tuesday, July 11, 2006 15:21
To: Ping Pan
Cc: [email-masked]; Adrian Farrel; [email-masked];
[email-masked]; [email-masked]
Subject: RE: Future of the GELS mailing list

ping - this is exactly my point -=20

-d.

"Ping Pan" <[email-masked]>
Sent by: [email-masked]
11/07/2006 14:33
=20
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Adrian
Farrel"=20
<[email-masked]>
        cc:     [email-masked], [email-masked],=20
[email-masked]
        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: [email-masked] [mailto:[email-masked]] On
Behalf Of [email-masked]
Sent: Tuesday, July 11, 2006 5:17 AM
To: Adrian Farrel
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]
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 <[email-masked]>
Sent by: [email-masked]
11/07/2006 11:34
=20
        To:     Adrian Farrel <[email-masked]>,
<[email-masked]>
        cc:     <[email-masked]>
        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" <[email-masked]> 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
[email-masked]
https://rtg.ietf.org/mailman/listinfo/gels

_______________________________________________
gels mailing list
[email-masked]
https://rtg.ietf.org/mailman/listinfo/gels

_______________________________________________
gels mailing list
[email-masked]
https://rtg.ietf.org/mailman/listinfo/gels

Delivery-date: Tue, 11 Jul 2006 13:21:59 +0000
To: "Ping Pan" <[email-masked]>
Cc: "Adrian Farrel" <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Subject: RE: Future of the GELS mailing list
From: [email-masked]
Date: Tue, 11 Jul 2006 15:20:57 +0200

ping - this is exactly my point - 

-d.

"Ping Pan" <[email-masked]>
Sent by: [email-masked]
11/07/2006 14:33
 
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Adrian Farrel" 
<[email-masked]>
        cc:     [email-masked], [email-masked], 
[email-masked]
        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: [email-masked] [mailto:[email-masked]] On
Behalf Of [email-masked]
Sent: Tuesday, July 11, 2006 5:17 AM
To: Adrian Farrel
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]
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 <[email-masked]>
Sent by: [email-masked]
11/07/2006 11:34
 
        To:     Adrian Farrel <[email-masked]>,
<[email-masked]>
        cc:     <[email-masked]>
        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" <[email-masked]> 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
[email-masked]
https://rtg.ietf.org/mailman/listinfo/gels

_______________________________________________
gels mailing list
[email-masked]
https://rtg.ietf.org/mailman/listinfo/gels

Delivery-date: Tue, 11 Jul 2006 12:17:35 +0000
To: Adrian Farrel <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Future of the GELS mailing list
From: [email-masked]
Date: Tue, 11 Jul 2006 14:16:39 +0200

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 <[email-masked]>
Sent by: [email-masked]
11/07/2006 11:34
 
        To:     Adrian Farrel <[email-masked]>, <[email-masked]>
        cc:     <[email-masked]>
        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" <[email-masked]> 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 
> 

Delivery-date: Tue, 11 Jul 2006 09:49:26 +0000
Date: Tue, 11 Jul 2006 05:34:33 -0400
Subject: Re: Future of the GELS mailing list
From: Monique Morrow <[email-masked]>
To: Adrian Farrel <[email-masked]>, <[email-masked]>
CC: <[email-masked]>

Agree with shutting down the GELS list.

/m

On 10/7/06 7:35 pm, "Adrian Farrel" <[email-masked]> 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 
> 

Delivery-date: Tue, 11 Jul 2006 05:58:06 +0000
Content-class: urn:content-classes:message
Subject: RE: Future of the GELS mailing list
Date: Tue, 11 Jul 2006 01:56:34 -0400
From: "Zafar Ali \(zali\)" <[email-masked]>
To: "Andrew G. Malis" <[email-masked]>, "Adrian Farrel" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

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: [email-masked] [mailto:[email-masked]]
On Behalf Of Andrew G. Malis
	Sent: Monday, July 10, 2006 8:15 PM
	To: Adrian Farrel
	Cc: [email-masked]; [email-masked]
	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 <[email-masked]> 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><FONT face=3DArial color=3D#0000ff=20
size=3D2></FONT>&nbsp;</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> [email-masked]=20
  [mailto:[email-masked]] <B>On Behalf Of </B>Andrew G.=20
  Malis<BR><B>Sent:</B> Monday, July 10, 2006 8:15 PM<BR><B>To:</B> =
Adrian=20
  Farrel<BR><B>Cc:</B> [email-masked]; =
[email-masked]<BR><B>Subject:</B>=20
  Re: Future of the GELS mailing list<BR></FONT><BR></DIV>
  <DIV></DIV>
  <DIV>Adrian,<BR><BR>I would suggest shutting down the gels=20
  list.&nbsp;&nbsp;<SPAN class=3D731005605-11072006><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>&nbsp;</FONT></SPAN></DIV>
  <DIV><SPAN class=3D731005605-11072006></SPAN>&nbsp;</DIV></BLOCKQUOTE>
<DIV><SPAN class=3D731005605-11072006><FONT face=3DArial color=3D#0000ff =
size=3D2>I=20
agree w/ shutting down the gels list. </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>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:[email-masked]">[email-masked]</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--

Delivery-date: Tue, 11 Jul 2006 02:19:32 +0000
Date: Mon, 10 Jul 2006 21:21:26 -0500
From: YongLucy 73674 <[email-masked]>
Subject: Re: Future of the GELS mailing list
To: "Andrew G. Malis" <[email-masked]>
Cc: Adrian Farrel <[email-masked]>, [email-masked], [email-masked]

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" <[email-masked]>
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 <[email-masked]> 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
> >
> 

Delivery-date: Tue, 11 Jul 2006 00:15:53 +0000
Date: Mon, 10 Jul 2006 20:14:57 -0400
From: "Andrew G. Malis" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>
Subject: Re: Future of the GELS mailing list
Cc: [email-masked], [email-masked]

------=_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 <[email-masked]> 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,<br><br>I would suggest shutting down the gels list. &nbsp;That would guarantee that we only see the messages once.<br><br>Cheers,<br>Andy<br><br><div><span class="gmail_quote">On 7/10/06, <b class="gmail_sendername">Adrian Farrel
</b> &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt; wrote:</span><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,<br><br>We 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 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>?<br><br>One question remains.<br>Should the GELS mailing list continue or should all discussions move to the<br>CCAMP list?<br><br>I am personally inclined to think that the separate list is a useful venue<br>for discussions that might not be completely dedicated to GMPLS protocol
<br>issues. On the other hand, maybe the WG would like all discussions in the<br>same place.<br><br>I would prefer that we stopped copying emails to both lists.<br><br>Opinions?<br>Adrian<br></blockquote></div><br>

------=_Part_99219_23197649.1152576897164--

Delivery-date: Mon, 10 Jul 2006 23:36:53 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Future of the GELS mailing list
Date: Tue, 11 Jul 2006 00:35:01 +0100
Organization: Old Dog Consulting

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 

Delivery-date: Mon, 10 Jul 2006 18:33:01 +0000
Content-class: urn:content-classes:message
Subject: RE: High level comment on draft-li-ccamp-confirm-data-channel-status-00.txt, 
Date: Mon, 10 Jul 2006 20:31:42 +0200
From: "MEURIC Julien RD-CORE-LAN" <[email-masked]>
To: "Zafar Ali \(zali\)" <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: "ccamp" <[email-masked]>

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: [email-masked] [mailto:[email-masked]] 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

Delivery-date: Mon, 10 Jul 2006 15:09:55 +0000
Content-class: urn:content-classes:message
Subject: Discussion on draft-fedyk-gmpls-ethernet-pbt-00.txt
Date: Mon, 10 Jul 2006 11:07:24 -0400
From: "Don Fedyk" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: "David Allan" <[email-masked]>, <[email-masked]>

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

Delivery-date: Mon, 10 Jul 2006 12:08:29 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Agenda and slides uploaded
Date: Mon, 10 Jul 2006 13:07:03 +0100
Organization: Old Dog Consulting

Hi,

Just in time working group management.

http://www3.ietf.org/proceedings/06jul/agenda/ccamp.htm

Adrian

Delivery-date: Mon, 10 Jul 2006 06:09:29 +0000
Content-class: urn:content-classes:message
Subject: Any objection on recommending upstream and downstream component links to be the same, 
Date: Mon, 10 Jul 2006 02:08:01 -0400
From: "Zafar Ali \(zali\)" <[email-masked]>
To: "ccamp" <[email-masked]>
Cc: "Richard Rabbat" <[email-masked]>, "Kohei Shiomoto" <[email-masked]>, "Rajiv Papneja" <[email-masked]>

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><SPAN class=3D175370106-10072006>Dear CCAMP-ers/ authors of =
addressing-id,=20
</SPAN></DIV>
<DIV><SPAN class=3D175370106-10072006></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D175370106-10072006>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. </SPAN></SPAN></DIV>
<DIV><SPAN class=3D175370106-10072006><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"></SPAN></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D175370106-10072006><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</SPAN></SPAN></DIV>
<DIV><SPAN class=3D175370106-10072006><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></FONT></SPAN></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D175370106-10072006><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 </SPAN></SPAN></DIV></BODY></HTML>

------_=_NextPart_001_01C6A3E7.3526584D--

Delivery-date: Mon, 10 Jul 2006 03:05:00 +0000
Content-class: urn:content-classes:message
Subject: Comments on draft-li-ccamp-multinodes-gr-proc-00.txt, 
Date: Sun, 9 Jul 2006 23:04:23 -0400
From: "Zafar Ali \(zali\)" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: "ccamp" <[email-masked]>

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><FONT face=3DArial size=3D2><SPAN class=3D986385202-10072006>Dear =
Authors,=20
</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D986385202-10072006></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D986385202-10072006>This =
is Deja-vu to=20
me.... </SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D986385202-10072006></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT><SPAN class=3D986385202-10072006><FONT face=3DArial><FONT =
size=3D2>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
</SPAN></FONT></FONT></SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial><FONT size=3D2><SPAN style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;=20
<SPAN class=3D986385202-10072006>"</SPAN></SPAN>[GR-EXT] also extends =
the Hello=20
message to exchange information about </FONT></FONT></DIV>
<DIV><FONT face=3DArial><FONT size=3D2><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;</SPAN>the ability to =
support the=20
RecoveryPath message. </FONT></FONT></DIV>
<DIV><FONT face=3DArial><FONT size=3D2><SPAN style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;=20
</SPAN>The examples and procedures in [GR-EXT] focus on the description =
of a=20
</FONT></FONT></DIV>
<DIV><FONT face=3DArial><FONT size=3D2><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;</SPAN>single node restart =
when=20
adjacent network nodes are operative. </FONT></FONT></DIV>
<DIV><FONT face=3DArial><FONT size=3D2><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;</SPAN>Although the =
procedures are=20
equally applicable to multi-node restarts, </FONT></FONT></DIV>
<DIV><FONT face=3DArial><FONT size=3D2><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;</SPAN>no detailed =
explanation is=20
provided.<SPAN class=3D986385202-10072006>" </SPAN></FONT></FONT></DIV>
<DIV><SPAN class=3D986385202-10072006><FONT =
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D986385202-10072006><FONT face=3DArial size=3D2>is not =
accurate.=20
Please see section 4 on the earlier version of the [GR-EXT], </FONT><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</FONT></A><FONT=20
face=3DArial size=3D2>. </FONT></SPAN></DIV>
<DIV><SPAN class=3D986385202-10072006><FONT =
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D986385202-10072006><FONT =
size=3D2>Thanks</FONT></SPAN></DIV>
<DIV><SPAN class=3D986385202-10072006><FONT =
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D986385202-10072006><FONT size=3D2>Regards... Zafar=20
</FONT></SPAN></DIV>
<DIV><SPAN class=3D986385202-10072006><FONT=20
size=3D2></FONT></SPAN>&nbsp;</DIV></BODY></HTML>

------_=_NextPart_001_01C6A3CD.8D339B2D--

Delivery-date: Mon, 10 Jul 2006 02:41:02 +0000
Content-class: urn:content-classes:message
Subject: High level comment on draft-li-ccamp-confirm-data-channel-status-00.txt, 
Date: Sun, 9 Jul 2006 22:39:32 -0400
From: "Zafar Ali \(zali\)" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: "ccamp" <[email-masked]>

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><FONT face=3DArial size=3D2><SPAN class=3D839221802-10072006>Dear =
Authors,=20
</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D839221802-10072006></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D839221802-10072006>RSVP =
refreshes do=20
this job, so I am not sure motivation for this draft/ LMP=20
extensions.&nbsp;</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D839221802-10072006></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT><SPAN class=3D839221802-10072006><FONT size=3D2><FONT =
face=3DArial>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
</SPAN></SPAN></FONT></FONT></SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D839221802-10072006></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D839221802-10072006>Thanks</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D839221802-10072006></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN =
class=3D839221802-10072006>Regards... Zafar=20
</SPAN></FONT></DIV></BODY></HTML>

------_=_NextPart_001_01C6A3CA.1397CB93--

Delivery-date: Sun, 09 Jul 2006 15:59:24 +0000
Date: Sun, 09 Jul 2006 11:58:52 -0400
From: Acee Lindem <[email-masked]>
To: "Ong, Lyndon" <[email-masked]>
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: Comments on draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt

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

>From: [email-masked]
>[mailto:[email-masked]] 
>Sent: Friday, July 07, 2006 5:14 AM
>To: Ong, Lyndon
>Cc: Acee Lindem; [email-masked]; [email-masked]
>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" <[email-masked]>
>06/07/2006 23:18
>        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Acee Lindem" 
><[email-masked]>
>        cc:     <[email-masked]>, <[email-masked]>
>        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 
>
>Behalf Of [email-masked]
>Sent: Thursday, July 06, 2006 11:12 AM
>To: Acee Lindem
>Cc: [email-masked]; [email-masked]
>Subject: Re: Comments on
>draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt
>
>acee - see inline
>
>
>
>
>Acee Lindem <[email-masked]>
>06/07/2006 18:36
>        cc:     [email-masked]
>        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
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>    
>>
>
>
>  
>

Delivery-date: Sun, 09 Jul 2006 15:49:12 +0000
Content-class: urn:content-classes:message
Subject: RE: Comments on draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt
Date: Sun, 9 Jul 2006 11:44:23 -0400
From: "Ong, Lyndon" <[email-masked]>
To: <[email-masked]>
Cc: "Acee Lindem" <[email-masked]>, <[email-masked]>, <[email-masked]>

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: [email-masked]
[mailto:[email-masked]]=20
Sent: Friday, July 07, 2006 5:14 AM
To: Ong, Lyndon
Cc: Acee Lindem; [email-masked]; [email-masked]
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" <[email-masked]>
Sent by: [email-masked]
06/07/2006 23:18
=20
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Acee Lindem"=20
<[email-masked]>
        cc:     <[email-masked]>, <[email-masked]>
        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: [email-masked] [mailto:[email-masked]] On
Behalf Of [email-masked]
Sent: Thursday, July 06, 2006 11:12 AM
To: Acee Lindem
Cc: [email-masked]; [email-masked]
Subject: Re: Comments on
draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt

acee - see inline

Acee Lindem <[email-masked]>
Sent by: [email-masked]
06/07/2006 18:36
=20
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     [email-masked]
        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

>=20

Delivery-date: Fri, 07 Jul 2006 13:00:15 +0000
To: "Ong, Lyndon" <[email-masked]>
Cc: "Acee Lindem" <[email-masked]>, [email-masked], [email-masked]
Subject: RE: Comments on draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt
From: [email-masked]
Date: Fri, 7 Jul 2006 14:13:56 +0200

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" <[email-masked]>
Sent by: [email-masked]
06/07/2006 23:18
 
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Acee Lindem" 
<[email-masked]>
        cc:     <[email-masked]>, <[email-masked]>
        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: [email-masked] [mailto:[email-masked]] On
Behalf Of [email-masked]
Sent: Thursday, July 06, 2006 11:12 AM
To: Acee Lindem
Cc: [email-masked]; [email-masked]
Subject: Re: Comments on
draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt

acee - see inline

Acee Lindem <[email-masked]>
Sent by: [email-masked]
06/07/2006 18:36
 
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     [email-masked]
        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

>Acee

Delivery-date: Thu, 06 Jul 2006 23:18:38 +0000
Content-class: urn:content-classes:message
Subject: RE: Comments on draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt
Date: Thu, 6 Jul 2006 19:11:15 -0400
From: "Ong, Lyndon" <[email-masked]>
To: "Sadler, Jonathan B." <[email-masked]>, "Acee Lindem" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>

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:[email-masked]]=20
Sent: Thursday, July 06, 2006 3:09 PM
To: Acee Lindem; Ong, Lyndon
Cc: [email-masked]; [email-masked];
[email-masked]
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: [email-masked] [mailto:[email-masked]] On
Behalf Of Acee Lindem
Sent: Thursday, July 06, 2006 4:23 PM
To: Ong, Lyndon
Cc: [email-masked]; [email-masked];
[email-masked]
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

>From: [email-masked] [mailto:[email-masked]] On=20
>Behalf Of [email-masked]
>Sent: Thursday, July 06, 2006 11:12 AM
>To: Acee Lindem
>Cc: [email-masked]; [email-masked]
>Subject: Re: Comments on
>draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt
>
>acee - see inline
>
>
>
>
>Acee Lindem <[email-masked]>
>06/07/2006 18:36
>=20
>        cc:     [email-masked]
>        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

Delivery-date: Thu, 06 Jul 2006 22:13:34 +0000
Content-class: urn:content-classes:message
Subject: RE: Comments on draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt
Date: Thu, 6 Jul 2006 17:08:55 -0500
From: "Sadler, Jonathan B." <[email-masked]>
To: "Acee Lindem" <[email-masked]>, "Ong, Lyndon" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>

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: [email-masked] [mailto:[email-masked]] On
Behalf Of Acee Lindem
Sent: Thursday, July 06, 2006 4:23 PM
To: Ong, Lyndon
Cc: [email-masked]; [email-masked];
[email-masked]
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

>Lyndon=20
>Behalf Of [email-masked]
>Sent: Thursday, July 06, 2006 11:12 AM
>To: Acee Lindem
>Cc: [email-masked]; [email-masked]
>Subject: Re: Comments on
>draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt
>
>acee - see inline
>
>
>
>
>Acee Lindem <[email-masked]>
>06/07/2006 18:36
>=20
>        cc:     [email-masked]
>        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

Delivery-date: Thu, 06 Jul 2006 21:23:57 +0000
Date: Thu, 06 Jul 2006 17:23:14 -0400
From: Acee Lindem <[email-masked]>
To: "Ong, Lyndon" <[email-masked]>
CC: [email-masked], [email-masked], [email-masked]
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
>  
>

>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

>Behalf Of [email-masked]
>Sent: Thursday, July 06, 2006 11:12 AM
>To: Acee Lindem
>Cc: [email-masked]; [email-masked]
>Subject: Re: Comments on
>draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt
>
>acee - see inline
>
>
>
>
>Acee Lindem <[email-masked]>
>06/07/2006 18:36
>        cc:     [email-masked]
>        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
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>    
>>
>
>
>  
>

Delivery-date: Thu, 06 Jul 2006 21:18:43 +0000
Content-class: urn:content-classes:message
Subject: RE: Comments on draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt
Date: Thu, 6 Jul 2006 17:18:15 -0400
From: "Ong, Lyndon" <[email-masked]>
To: <[email-masked]>, "Acee Lindem" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

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: [email-masked] [mailto:[email-masked]] On
Behalf Of [email-masked]
Sent: Thursday, July 06, 2006 11:12 AM
To: Acee Lindem
Cc: [email-masked]; [email-masked]
Subject: Re: Comments on
draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt

acee - see inline

Acee Lindem <[email-masked]>
Sent by: [email-masked]
06/07/2006 18:36
=20
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     [email-masked]
        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

>=20

Delivery-date: Thu, 06 Jul 2006 21:12:38 +0000
From: "Igor Bryskin" <[email-masked]>
To: "Lou Berger" <[email-masked]>, "Yakov Rekhter" <[email-masked]>
Cc: "Rahul Aggarwal" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: draft-ietf-mpls-rsvp-te-p2mp-06.txt [P2MP ID] 
Date: Thu, 6 Jul 2006 17:11:21 -0400

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" <[email-masked]>
To: "Lou Berger" <[email-masked]>
Cc: "Rahul Aggarwal" <[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>
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.
>

Delivery-date: Thu, 06 Jul 2006 19:57:25 +0000
Content-class: urn:content-classes:message
Subject: RE: draft-fedyk-gmpls-ethernet-pbt-00.txt
Date: Thu, 6 Jul 2006 15:56:36 -0400
From: "Don Fedyk" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>

Hi Alan=20

> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of [email-masked]
> =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

Delivery-date: Thu, 06 Jul 2006 19:06:53 +0000
To: Acee Lindem <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Comments on draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt
From: [email-masked]
Date: Thu, 6 Jul 2006 20:12:04 +0200

acee - see inline

Acee Lindem <[email-masked]>
Sent by: [email-masked]
06/07/2006 18:36
 
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     [email-masked]
        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

>Acee

Delivery-date: Thu, 06 Jul 2006 16:37:12 +0000
Date: Thu, 06 Jul 2006 12:36:23 -0400
From: Acee Lindem <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: Comments on draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt

[email-masked] 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 <[email-masked]>
>06/07/2006 03:12
>        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

>Acee

Delivery-date: Thu, 06 Jul 2006 14:57:52 +0000
Date: Thu, 06 Jul 2006 10:57:04 -0400
To: Yakov Rekhter <[email-masked]>
From: Lou Berger <[email-masked]>
Subject: Re: draft-ietf-mpls-rsvp-te-p2mp-06.txt [P2MP ID] 
Cc: Lou Berger <[email-masked]>,Rahul Aggarwal <[email-masked]>, [email-masked],[email-masked],[email-masked]

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.

Delivery-date: Thu, 06 Jul 2006 14:45:41 +0000
From: "Pandian, Vijay" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>,  "[email-masked]'" <[email-masked]>
Subject: RE: RFC3630 - Local and Remote Interface IP address
Date: Thu, 6 Jul 2006 10:44:25 -0400 

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: [email-masked]
[mailto:[email-masked]]
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" <[email-masked]>
Sent by: [email-masked]
06/07/2006 02:56
 
        To:     [email-masked]
        cc:     [email-masked], [email-masked]
        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

Delivery-date: Thu, 06 Jul 2006 10:18:02 +0000
Content-class: urn:content-classes:message
Subject: draft-fedyk-gmpls-ethernet-pbt-00.txt
Date: Thu, 6 Jul 2006 11:15:55 +0100
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>

=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

Delivery-date: Thu, 06 Jul 2006 05:55:33 +0000
To: Acee Lindem <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Comments on draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt
From: [email-masked]
Date: Thu, 6 Jul 2006 07:40:49 +0200

hi acee - thanks for commenting 

one or two hints below such as to clarify some point you mentioned here 
below

Acee Lindem <[email-masked]>
Sent by: [email-masked]
06/07/2006 03:12
 
        To:     [email-masked]
        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

Delivery-date: Thu, 06 Jul 2006 01:12:28 +0000
Date: Wed, 05 Jul 2006 21:12:10 -0400
From: Acee Lindem <[email-masked]>
To: [email-masked]
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.

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

Delivery-date: Thu, 06 Jul 2006 00:57:23 +0000
From: "Pandian, Vijay" <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: RFC3630 - Local and Remote Interface IP address
Date: Wed, 5 Jul 2006 20:56:06 -0400 

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><FONT face=Arial size=2><SPAN class=529573300-06072006>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.</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=529573300-06072006></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2><SPAN class=529573300-06072006>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.</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=529573300-06072006></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2><SPAN class=529573300-06072006>Specifically, can a 
TE-Link have just one Local Interface IP address but multiple Remote Interface 
IP Address or vice-versa?</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=529573300-06072006></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2><SPAN class=529573300-06072006>Best 
regards,</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=529573300-06072006></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=529573300-06072006>Vijay</SPAN></FONT></DIV></BODY></HTML>

------_=_NextPart_001_01C6A096.F699C238--

Delivery-date: Wed, 05 Jul 2006 22:54:43 +0000
Date: Wed, 05 Jul 2006 17:56:39 -0500
From: YongLucy 73674 <[email-masked]>
Subject: Re: RE: draft-fedyk-gmpls-ethernet-pbt-00.txt
To: Don Fedyk <[email-masked]>
Cc: Igor Bryskin <[email-masked]>, [email-masked], [email-masked]

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 <[email-masked]>
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
> > >  
> > 
> > 
> > 
> > 
> > 
> > 
> 
> 

Delivery-date: Wed, 05 Jul 2006 19:19:08 +0000
To: Lou Berger <[email-masked]>
cc: Rahul Aggarwal <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: draft-ietf-mpls-rsvp-te-p2mp-06.txt [P2MP ID] 
Date: Wed, 05 Jul 2006 12:18:13 -0700
From: Yakov Rekhter <[email-masked]>

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: [email-masked]
Delivery-date: Wed, 05 Jul 2006 16:08:04 +0000
To: Lou Berger <[email-masked]>
Cc: Yakov Rekhter <[email-masked]>, Rahul Aggarwal <[email-masked]>, [email-masked], [email-masked], [email-masked]
Cc: [email-masked]
Subject: Re: draft-ietf-mpls-rsvp-te-p2mp-06.txt [P2MP ID] 
From: George Swallow <[email-masked]>
Date: Wed, 05 Jul 2006 12:08:40 -0400
Message-Id: <[email-masked]>

>          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

Delivery-date: Wed, 05 Jul 2006 15:10:13 +0000
Date: Wed, 05 Jul 2006 11:09:44 -0400
To: Yakov Rekhter <[email-masked]>
From: Lou Berger <[email-masked]>
Subject: Re: draft-ietf-mpls-rsvp-te-p2mp-06.txt [P2MP ID] 
Cc: Lou Berger <[email-masked]>,Rahul Aggarwal <[email-masked]>, [email-masked],[email-masked],[email-masked]

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 

Delivery-date: Wed, 05 Jul 2006 14:59:18 +0000
To: George Swallow <[email-masked]>
cc: Lou Berger <[email-masked]>, Rahul Aggarwal <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: draft-ietf-mpls-rsvp-te-p2mp-06.txt [P2MP ID] 
Date: Wed, 05 Jul 2006 07:58:56 -0700
From: Yakov Rekhter <[email-masked]>

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.

Delivery-date: Wed, 05 Jul 2006 14:41:00 +0000
To: Lou Berger <[email-masked]>
cc: Rahul Aggarwal <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: draft-ietf-mpls-rsvp-te-p2mp-06.txt [P2MP ID] 
Date: Wed, 05 Jul 2006 07:39:44 -0700
From: Yakov Rekhter <[email-masked]>

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.

Delivery-date: Wed, 05 Jul 2006 07:05:46 +0000
Date: Wed, 05 Jul 2006 15:03:49 +0800
From: Zheng Hewen <[email-masked]>
Subject: I made a foolish mistake, I am sorry for the inconvenience about a wrong Email .
To: 'LE ROUX Jean-Louis RD-CORE-LAN' <[email-masked]>, [email-masked]

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

Delivery-date: Wed, 05 Jul 2006 06:56:20 +0000
Date: Wed, 05 Jul 2006 14:52:25 +0800
From: Zheng Hewen <[email-masked]>
Subject: Are you interested at forming requirments about MPLS P2MP membership discovery and distribution?
To: 'LE ROUX Jean-Louis RD-CORE-LAN' <[email-masked]>, [email-masked]

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

Delivery-date: Mon, 03 Jul 2006 23:37:10 +0000
To: Greg jones <[email-masked]>
Cc: Loa Andersson <[email-masked]>, George Swallow <[email-masked]>, Deborah Brungard <[email-masked]>, Ross Callon <[email-masked]>, Bill Fenner <[email-masked]>, Stewart Bryant <[email-masked]>, Danny McPherson <[email-masked]>, Mark Townsley <[email-masked]>, IESG <[email-masked]>, IAB <[email-masked]>, Steve Trowbridge <[email-masked]>, Malcolm Betts <[email-masked]>, Ghani Abbas <[email-masked]>, Houlin Zhao <[email-masked]>, Yoichi Maeda  <[email-masked]>, Jari Arkko <[email-masked]>, Scott Bradner <[email-masked]>, Scott Brim <[email-masked]>, CCAMP mailing list <[email-masked]>, MPLS mailing list <[email-masked]>, PWE3 mailing list <[email-masked]>, Adrian Farrel <[email-masked]>, Ross Callon <[email-masked]>, Stewart Bryant <[email-masked]>, Loa Andersson <[email-masked]>
From: Adrian Farrel(IETF CCAMP WG) <[email-masked]>
Subject: New Liaison Statement, "Continued IETF / SG15 Cooperation on T-MPLS  and other MPLS Issues" 
reply-to: Adrian Farrel <[email-masked]>
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) <[email-masked]>
To: ITU-T SG15(Greg jones <[email-masked]>)
Cc: Loa Andersson <[email-masked]>
George Swallow <[email-masked]>
Deborah Brungard <[email-masked]>
Ross Callon <[email-masked]>
Bill Fenner <[email-masked]>
Stewart Bryant <[email-masked]>
Danny McPherson < [email-masked]>
Mark Townsley <[email-masked]>
IESG <[email-masked]>
IAB <[email-masked]>
Steve Trowbridge <[email-masked]>
Malcolm Betts <[email-masked]>
Ghani Abbas <[email-masked]>
Houlin Zhao <[email-masked]>
Yoichi Maeda  <[email-masked]>
Jari Arkko <[email-masked]>
Scott Bradner <[email-masked]>
Scott Brim <[email-masked]>
CCAMP mailing list <[email-masked]>
MPLS mailing list <[email-masked]>
PWE3 mailing list <[email-masked]>
Reponse Contact: Adrian Farrel <[email-masked]>
Ross Callon <[email-masked]>
Technical Contact: Stewart Bryant <[email-masked]>
Loa Andersson <[email-masked]>
Purpose: For action 
Body: From: Adrian Farrel (IETF Liaison to SG15, CCAMP WG Chair, [email-masked])
      Loa Andersson (IETF MPLS WG Chair; [email-masked])
      George Swallow (IETF MPLS WG Chair; [email-masked])
      Deborah Brungard  (IETF CCAMP WG Chair, [email-masked])
      Ross Callon (IETF Routing Area Director; [email-masked])
      Bill Fenner (IETF Routing Area Director; [email-masked])
      Stewart Bryant (IETF PWE3 WG Chair; [email-masked])
      Danny McPherson  (IETF PWE3 WG Chair, [email-masked])
      Mark Townsley (IETF Internet Area Director, [email-masked])
		
To:   ITU-T Study Group 15; Greg Jones  ([email-masked])

CC:   IESG  ([email-masked])
      IAB  ([email-masked])
      Steve Trowbridge  ([email-masked])
      Malcolm Betts  ([email-masked])
      Ghani Abbas  ([email-masked])
      Houlin Zhao  ([email-masked])
      Yoichi Maeda   ([email-masked])
      Jari Arkko ([email-masked])
      Scott Bradner  ([email-masked])
      Scott Brim  ([email-masked])
      CCAMP mailing list ([email-masked])
      MPLS mailing list ([email-masked])
      PWE3 mailing list ([email-masked])

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

Delivery-date: Mon, 03 Jul 2006 16:14:29 +0000
Content-class: urn:content-classes:message
Subject: RE: I-D ACTION:draft-ietf-ccamp-gmpls-mln-eval-01.txt 
Date: Mon, 3 Jul 2006 18:12:36 +0200
From: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
To: <[email-masked]>

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 : [email-masked]=20
> [mailto:[email-masked]] De la part de=20
> [email-masked]
> Envoy=E9 : jeudi 29 juin 2006 00:50
> =C0 : [email-masked]
> Cc : [email-masked]
> 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 [email-masked] 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:
> 	[email-masked].
> 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

Delivery-date: Sun, 02 Jul 2006 22:20:35 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Time for your slides, please
Date: Sun, 2 Jul 2006 23:19:01 +0100
Organization: Old Dog Consulting

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 

Delivery-date: Sun, 02 Jul 2006 13:51:33 +0000
Content-class: urn:content-classes:message
Subject: RE: draft-fedyk-gmpls-ethernet-pbt-00.txt
Date: Sun, 2 Jul 2006 16:47:31 +0200
From: "Nurit Sprecher" <[email-masked]>
To: "Lucy Yong" <[email-masked]>
Cc: "Don Fedyk" <[email-masked]>, "Igor Bryskin" <[email-masked]>, <[email-masked]>, <[email-masked]>, "Nurit Sprecher" <[email-masked]>

=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: [email-masked] [mailto:[email-masked]] On
Behalf Of Lucy Yong
Sent: Friday, June 30, 2006 18:31
To: 'Don Fedyk'; 'Igor Bryskin'; [email-masked]; [email-masked]
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: [email-masked] [mailto:[email-masked]] On
Behalf Of Don Fedyk
Sent: Monday, June 26, 2006 10:50 AM
To: Igor Bryskin; [email-masked]; [email-masked]
Subject: RE: draft-fedyk-gmpls-ethernet-pbt-00.txt

=20

> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Igor Bryskin
>
> Thanks Don,
>=20
> See in-line.
>=20
> Igor
>=20
> From: "Don Fedyk" <[email-masked]>
>=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

Delivery-date: Sat, 01 Jul 2006 22:39:00 +0000
To: "Don Fedyk" <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], Igor Bryskin <[email-masked]>, Lucy Yong <[email-masked]>
Subject: RE: draft-fedyk-gmpls-ethernet-pbt-00.txt
From: [email-masked]
Date: Sun, 2 Jul 2006 00:36:44 +0200

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" <[email-masked]>
Sent by: [email-masked]
01/07/2006 05:54
 
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     [email-masked], [email-masked], Lucy Yong 
<[email-masked]>, [email-masked], Igor Bryskin 
<[email-masked]>
        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 

> From: [email-masked] 
> [mailto:[email-masked]] 
> 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
[email-masked]
https://rtg.ietf.org/mailman/listinfo/gels

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
Date: Fri, 30 Jun 2006 23:54:14 -0400
From: "Don Fedyk" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, "Igor Bryskin" <[email-masked]>, "Lucy Yong" <[email-masked]>

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

> From: [email-masked]=20
> [mailto:[email-masked]]=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>

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
Date: Fri, 30 Jun 2006 23:47:53 -0400
From: "Don Fedyk" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, "Igor Bryskin" <[email-masked]>, "Lucy Yong" <[email-masked]>, <[email-masked]>

Hi Dimitri=20

Yes I used control loosely I agree with your more specific definitions.=20

Don=20
> From: [email-masked]=20
> [mailto:[email-masked]]=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>