Subject: Get $2400 welcome bonus

From: "Berta Hare" <[email-masked]>

Relax and have fun with poker, blackjack, roulette, progressive video slots at your own leisure from your couch.
   
We pay you to play. 

Come find out.

Download our casino in 20 seconds to get $2400 richer when you join. 

http://worldacasino.net.cn/

Delivery-date: Mon, 31 Dec 2007 19:56:13 +0000
Content-class: urn:content-classes:message
Subject: RE: ccamp minutes
Date: Mon, 31 Dec 2007 14:54:07 -0500
From: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
To: <[email-masked]>

This is a multi-part message in MIME format.

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

Try this version - there were an excessive number of typos introduced in
the other uploaded version:
http://www3.ietf.org/proceedings/07dec/minutes/ccamp.txt
=20
And thanks to our note takers - Dimitri, Martin, and Dan!

________________________________

From: [email-masked] [mailto:[email-masked]] On
Behalf Of BRUNGARD, DEBORAH A, ATTLABS
Sent: Monday, December 31, 2007 1:41 PM
To: [email-masked]
Subject: ccamp minutes

Hi CCAMP,
=20
The minutes have been uploaded:
http://www3.ietf.org/proceedings/07dec/minutes/ccamp.htm
=20
Let us know if any changes/additions.
=20
Happy 2008!
Adrian and Deborah
=20

------_=_NextPart_001_01C84BE6.E7D709DF
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.3243" name=3DGENERATOR></HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D583125019-31122007>Try this version - there were an excessive =
number=20
of&nbsp;typos introduced in the other uploaded =
version:</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D583125019-31122007><A=20
href=3D"http://www3.ietf.org/proceedings/07dec/minutes/ccamp.txt">http://=
www3.ietf.org/proceedings/07dec/minutes/ccamp.txt</A></SPAN></FONT></DIV>=

<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D583125019-31122007></SPAN></FONT>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D583125019-31122007>And thanks to our note takers - Dimitri, =
Martin, and=20
Dan!</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> [email-masked]=20
[mailto:[email-masked]] <B>On Behalf Of </B>BRUNGARD, DEBORAH =
A,=20
ATTLABS<BR><B>Sent:</B> Monday, December 31, 2007 1:41 PM<BR><B>To:</B>=20
[email-masked]<BR><B>Subject:</B> ccamp minutes<BR></FONT><BR></DIV>
<DIV></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D466323818-31122007>Hi=20
CCAMP,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D466323818-31122007></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D466323818-31122007>The =
minutes have=20
been uploaded:</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D466323818-31122007><A=20
href=3D"http://www3.ietf.org/proceedings/07dec/minutes/ccamp.htm">http://=
www3.ietf.org/proceedings/07dec/minutes/ccamp.htm</A></SPAN></FONT></DIV>=

<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D466323818-31122007></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D466323818-31122007>Let us =
know if any=20
changes/additions.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D466323818-31122007></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D466323818-31122007>Happy=20
2008!</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D466323818-31122007>Adrian =
and=20
Deborah</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D466323818-31122007></SPAN></FONT>&nbsp;</DIV></BODY></HTML>

------_=_NextPart_001_01C84BE6.E7D709DF--

Delivery-date: Mon, 31 Dec 2007 18:43:55 +0000
Content-class: urn:content-classes:message
Subject: ccamp minutes
Date: Mon, 31 Dec 2007 13:41:11 -0500
From: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
To: <[email-masked]>

This is a multi-part message in MIME format.

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

Hi CCAMP,
=20
The minutes have been uploaded:
http://www3.ietf.org/proceedings/07dec/minutes/ccamp.htm
=20
Let us know if any changes/additions.
=20
Happy 2008!
Adrian and Deborah
=20

------_=_NextPart_001_01C84BDC.B759AB2C
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.3243" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D466323818-31122007>Hi=20
CCAMP,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D466323818-31122007></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D466323818-31122007>The =
minutes have=20
been uploaded:</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D466323818-31122007><A=20
href=3D"http://www3.ietf.org/proceedings/07dec/minutes/ccamp.htm">http://=
www3.ietf.org/proceedings/07dec/minutes/ccamp.htm</A></SPAN></FONT></DIV>=

<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D466323818-31122007></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D466323818-31122007>Let us =
know if any=20
changes/additions.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D466323818-31122007></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D466323818-31122007>Happy=20
2008!</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D466323818-31122007>Adrian =
and=20
Deborah</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D466323818-31122007></SPAN></FONT>&nbsp;</DIV></BODY></HTML>

------_=_NextPart_001_01C84BDC.B759AB2C--

Delivery-date: Fri, 28 Dec 2007 18:58:57 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "David Ward" <[email-masked]>, "Tim Polk" <[email-masked]>
Cc: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>, "Kohei Shiomoto" <[email-masked]>, "Ross Callon" <[email-masked]>, <[email-masked]>
Subject: Your Discusses and Comments on draft-ietf-ccamp-mpls-gmpls-interwork-fmwk
Date: Fri, 28 Dec 2007 18:55:48 -0000

Hi,

I think we have proposals to resolve your issues with 
draft-ietf-ccamp-mpls-gmpls-interwork-fmwk.

Can you confirm that they would meet your needs?

Thanks,
Adrian

===
Tim Polk
Discuss
"This is a discuss discuss.  Personally, I find the phased migration model 
terrifying.  Selective introduction of features seems like a great 
opportunity to perform a DoS attack on your own network.  Are there features 
of GMPLS that assume the existence of other features for consistent 
operation?  It seems like you are developing your own interim internal 
"standards" that need to be self-consistent.  Is this really a good thing 
for the IETF to recommend?"

Ross is right that the intention of CCAMP in this I-D was to not recommend 
the phased model (although it should be noted that this is exactly what the 
vendors are doing)-:  So section 4.3 is a fine place to add additional 
warnings as follows...

>   Interoperability concerns though are exacerbated by this migration
>   model, unless all LSRs in the network are updated simultaneously and
>   there is a clear understanding of which subset of features are to be
>   included in the hybrid LSRs. Interworking between a hybrid LSR and an
>   unchanged MPLS LSR would put the hybrid LSR in the role of a GMPLS
>   LSR as described in the previous sections and puts the unchanged LSR
>   in the role of an MPLS LSR. The potential for different hybrids
>   within the network will complicate matters considerably.
    This model is, therefore, only appropriate for use when the set of new
    features to be deployed is well known and limited, and where there is
    a clear understanding of and agreement on this set of features by the
    network operators of the ISP(s) involved as well as all vendors whose
    equipment will be involved in the migration.

===

Tim Polk
Comment
"Section 5, Paragraph 4 first sentence currently reads:

  The second strategy for PSC and non-PSC networks is to migrate from
  the PSC network to GMPLS, first, and then enable GMPLS within the
  non-PSC network.

I suggest:

  The second strategy is to migrate from
  the PSC network to GMPLS, first, and then enable GMPLS within the
  non-PSC network."

This should actually read...
   The second strategy is to migrate
   the PSC network to GMPLS first, and then enable GMPLS within the
   non-PSC network."

===

Dave Ward
Comment
"There is no mention of using PCEs for this functionality."

PCE could fit usefully into the Island model and the Integrated model. It 
would not play any valuable role in the Phased model.

I think the best place to add a reference would be in section 5.1 since PCE 
may provide a component in the migration toolkit. This would not be as 
strong as a recommendation to use PCE since it is clear that the use of PCE 
is not a prerequisite for migration.

So we could add...

5.1.4. Path Computation Element

   The Path Computation Element (PCE) [RFC4655] may provide an
   additional tool to aid MPLS to GMPLS migration. If a layered network
   approach (Section 5.1.1) is used, PCEs may be used to facilitate the
   computation of paths for LSPs in the different layers
   [PCE-INTER-LAYER].

And to section 12.2

   [RFC4655] A. Farrel, JP. Vasseur and J. Ash, "A Path Computation
              Element (PCE)-Based Architecture", RFC 4655, August 2006.

   [PCE-INTER-LAYER] Oki, E., Le Roux , J-L,. and Farrel, A.,
                         "Framework for PCE-Based Inter-Layer MPLS
                          and GMPLS Traffic Engineering,"
                          draft-ietf-pce-inter-layer-frwk, work in progress.

Delivery-date: Fri, 28 Dec 2007 14:25:38 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Updated: Draft response to the OIF
Date: Fri, 28 Dec 2007 14:14:52 -0000

Hi,

After some off-line emails, here is an updated draft response to 
http://www.olddog.co.uk/oif2007_382_01.pdf

The changes are in the answer to question 3)

Any further comments?

Cheers,
Adrian

===
 To : Lyndon Ong, OIF TC Chair <[email-masked]>
Cc: Ross Callon, IETF Routing Area Director <[email-masked]>
   David Ward, IETF Routing Area Director <[email-masked]>

Subject: Response to Your Questions about GMPLS Protocol Usage

Dear Lyndon,

Thanks for your communication dated 29th November 2007 and your subsequent
email exchange with clarifications.

Please find below responses from CCAMP experts to the questions you posed.

May we take this oportunity to stress that we are open to receiving such
questions in a less formal way either directly or through the CCAMP mailing
list, and may be able to provide timely responses during the course of your
testing events.

> 1) One of the features provided in the OIF UNI 2.0 is the ability to
> non-disruptively modify service attributes associated with an LSP. The
> modification of the service attributes is limited to LSPs that were
> initiated using Shared Explicit filter style. Modification is performed
> by signaling a new LSP that utilizes the same Tunnel ID as the original
> LSP but with the new service parameters. Once the new LSP state is
> established, the original LSP state is removed.

There are two distinct options for modifying an LSP. The first is "in-place"
modification where a new trigger Path message is sent for an existing LSP.
The second is the "make-before-break" approach to tunnel/service
modification first introduced in RFC 3209. You appear to be refering to the
latter case since you mention a new LSP.

> Non-disruptive modification was demonstrated in the 2007
> interoperability test by modifying the bandwidth of an LSP realized by a
> SONET/SDH VCAT group. In the process of testing, a number of questions
> arose regarding the RESV message flow. These questions included:
>
> - How many RESV messages are expected to be generated? Is it one since
>   the resources in use by both LSPs are the same, or two since the LSPs
>   are handled through separate signaling sessions.

In make-before-break, each LSP is signaled independently.  Per LSP Resv
messages should be expected.  Assuming the old LSP is in-place at the time
of signaling the new LSP, and only one Path message is issued, then only one
Resv would be expected. That is, a Resv for the new LSP, but no further Resv
for the existing LSP.

When the old LSP is also modified as part of the make-before-break, e.g., to
update administrative status prior to alarm-free tear-down, then a Resv
message on the old LSP may also be generated.

> - What is the bandwidth amount that should be reflected in the RESV
>   messages? If separate RESV messages are generated for both LSPs, is it
>   the bandwidth requested in the corresponding PATH message? Or is it
>   the actual bandwidth being provided by the connection at the time the
>   RESV message is generated?

According to RFC 4606:

    For a particular sender in a session, the contents of the FLOWSPEC
    object received in a Resv message SHOULD be identical to the contents
    of the SENDER_TSPEC object received in the corresponding Path
    message.  If the objects do not match, a ResvErr message with a
    "Traffic Control Error/Bad Flowspec value" error SHOULD be generated.

Again, in make-before-break, each LSP is signaled independently.

> In the interop test both approaches were observed. To facilitate the
> subsequent demonstration, receivers were expected to handle both cases.
>
> 2) In the process of testing, we found that not all implementations
> included Explicit Route Objects (ERO) in PATH messages when performing
> graceful deletion, even though earlier PATH messages for the LSP had
> included an ERO. For some intermediate node implementations, the lack of
> the ERO was seen as removing the 'pinned' nature of the connection,
> causing the node to interpret the PATH message as requiring a new path
> computation which may end up using a different route. Other
> implementations utilized the Session and Sender Template to relate the
> received PATH message with the existing connection thereby identifying
> the path the message should be forwarded on. This approach was taken by
> these implementations since inclusion of an ERO is not mandatory. We
> would appreciate CCAMP's thoughts on what the behavior should be.

As described in RFC 2205, Path and Resv messages are idempotent.  This means
that any Path message reflects full state, and differences between one Path
message and a subsequent Path message may be reasonably considered an
explicit change. Therefore, while there is no explicit requirement stated in
RFC 3473, it is typical to only modify the Admin Status Object in Path
messages sent in connection to RFC 3473 section 7.2.1. deletion procedures
(i.e. to include the full ERO as on previous Path messages).

It may be observed, however, that while an implementation detecting a change
in ERO (such as the removal of the ERO) may legitimately opt to reroute,
that implementation should also note the change in Admin Status associated
with the graceful deletion and may "assume" that such a reroute would be a
waste of time. Further, in a transport system, implementaitons should only
perform local reroutes (deviating from in-place LSPs) with extreme caution
since these risk impacting traffic.

> 3) In the process of testing, we found cases where the update of a
> link's attributes (i.e. available capacity) was not being done by
> advertising an updated LSA using the same LSAid, but by flushing the old
> LSA followed by generation of a new LSA with a new LSAid. Since the
> LSAid for Opaque LSAs is not tied to the resource being advertised
> (i.e. the resource is identified using TLVs in the Opaque LSA, not using
> the LSAid as is done with IPv4 OSPF LSAs), this can cause a problem as
> it causes the order that the LSAs are processed to become important. We
> would appreciate CCAMP's thoughts on what the behavior should be.

The OSPF WG, is the proper WG to respond to this as they are the 
authoritative source on OSPF technology.  From our perspective, RFC 2328 
dictates the use of the same Link State ID when advertising a change in 
information about a link, and  RFC 3630  states "The LSA ID has no 
topological significance."

While it is certainly possible to advertise a change via issuing an LSA with 
a new Link State ID and flushing old state, from the perspective of OSPF 
this is not a change in link state, rather a completely new link.

In fact, when there are key changes to the information advertised about a 
link (for example, a change to the Link Type or Link ID), the advertising 
router should recognise that these changes represent the advertisement of a 
new link and should use a new LSA with a new Link State ID. However, where 
the change is clearly a change to the link state of an existing link, the 
advertising router should use the same Link State ID.

> 4) Finally, in the process of testing, we found cases where established
> connections were deleted based on node restart procedures in RFC
> 3473. R163 of the OIF Carrier requirements (liaised to IETF in 12/2006)
> states deletion of established connections as the result of control
> plane failure (including node restart) shall not occur. It has been
> identified this could also occur when a number of cascaded nodes restart
> at the same time. We would appreciate CCAMP's thoughts on ways to
> prevent deletion of established connections from occurring when a node
> restarts.

Without specific details, it's impossible to address the found cases or to
identify if they were due to implementation or specification issues.

More broadly, RFC 3473 does not require the removal of forwarding state,
even in the case of state synchronization errors, and implementations may
take different action (such as reporting the condition to a management
station). An implementation at a restarting node may consider that the lack
of control plane state at its neighbor indicates that the removal of
forwarding plane state has been attempted through the control plane while
the restarting node was down and should follow local policy in determining
how to react.

We would also like to direct you to RFC 5063 and
draft-ietf-ccamp-gr-description which may provide additional relevant
information.

We hope this addresses your questions.

Best regards,
Adrian Farrel and Deborah Brungard
IETF CCAMP working group co-chairs 

Delivery-date: Fri, 21 Dec 2007 20:23:04 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Greg Bernstein" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Liaison received from ITU-T on T-MPLS ring protection
Date: Fri, 21 Dec 2007 20:19:13 -0000

Hi Greg,

I see what you are saying.

At the moment, however, there seems to have been no decision about a 
specific control plane for T-MPLS.

There are a couple of ways this could be relevant to us, however...

- Ring protection techniques could be used in a PSC network under the
  control of GMPLS. That is, GMPLS could be used to set up ring
  protection in a PSC network. I would want to see the requirements
  for this, however, since GMPLS appears to provide plenty of
  alternatives for protection and restoration it may be an uphill struggle
  to demonstrate why ring protection is beneficial in a PSC that is
  more like a mesh.

- A GMPLS network may operate over rings that have underlying
  ring protection. In this case the ring protection provides link-level
  protection, and we know how to handle that.

I am a little sceptical about the idea of mixing ring protection with 
end-to-end provisioning. Since MPLS gives us an easy mechanism for 
hierarchy, I don't see why we wouldn't traverse an MPLS protected ring as a 
single hop in an end-to-end LSP.

Anyway...
I think that the current work in the ITU-T for T-MPLS ring protection still 
only refers to the data plane.

Cheers,
Adrian

----- Original Message ----- 
From: "Greg Bernstein" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, December 20, 2007 5:32 PM
Subject: Re: Liaison received from ITU-T on T-MPLS ring protection

> Hi all, it seems to me there maybe some implications for GMPLS based on 
> previous experience with "software based 4F-BLSRs", that is rings that are 
> setup on portions of a mesh network to provide fast redundant protection 
> using SDH like ring switching mechanisms.
> These types of rings which are applicable to a number of layers (optical, 
> SDH, whatever) have traditionally had interoperability problems across 
> vendors.  This has typically involved how to share the "ring map" 
> information (see section 17.1 of the liaison attachment). In addition 
> "nodes" need information on connections added and dropped so they can 
> prevent mis-connection (the "squelching" process).
>
> Obviously one way to keep track of a ring map is to "mark" a link as 
> belonging to a particular ring and distribute this info via GMPLS routing.
>
> Regards
>
> Greg B.
>
>
> Adrian Farrel wrote:
>> Hi,
>>
>> We received a liaison from the ITU-T that reads as follows...
>>
>>   SG15 Q9 has nearly completed its work on a recommendation for
>>   T-MPLS Ring Protection - G.8132. It is targeted to consent this
>>   new recommendation in the next SG15 plenary meeting scheduled
>>   for Feb., 2008.
>>
>>   We have attached the latest draft for your information and
>>   comments.
>>
>> We are requested to comment by 11th February 2008.
>>
>> At first glance, this work appears to concentrate on the data plane only 
>> and so is not within our scope. The MPLS working group was also copied 
>> and can handle any issues concerning the MPLS data plane.
>>
>> As always, you can see all incoming and outgoing communications for CCAMP 
>> at www.olddog.co.uk/ccamp.htm
>>
>> Thanks,
>> Adrian
>>
>>
>>
>
> -- 
> ===================================================
> Dr Greg Bernstein, Grotto Networking (510) 573-2237
>
>
> 

Delivery-date: Fri, 21 Dec 2007 15:37:43 +0000
To: [email-masked]
From: [email-masked]
Date: Mon, 17 Dec 2007 16:10:02 -0500
Cc: [email-masked]
Subject: I-D Action:draft-ietf-ccamp-gmpls-mln-eval-05.txt 
Reply-To: [email-masked]

--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           : Evaluation of existing GMPLS Protocols against Multi Layer and Multi Region Networks (MLN/MRN)
	Author(s)       : J. Le Roux, et al.
	Filename        : draft-ietf-ccamp-gmpls-mln-eval-05.txt
	Pages           : 16
	Date            : 2007-12-17

This document provides an evaluation of Generalized Multi-Protocol
Label Switching (GMPLS) protocols and mechanisms against the
requirements for Multi-Layer Networks (MLN) and Multi-Region Networks
(MRN). In addition, this document identifies areas where additional
protocol extensions or procedures are needed to satisfy these
requirements, and provides guidelines for potential extensions.Conventions
used in this document

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-mln-eval-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-gmpls-mln-eval-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-gmpls-mln-eval-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-gmpls-mln-eval-05.txt

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

Content-Type: text/plain
Content-ID: <2007-12-17160517.I-D\@ietf.org>

--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/i-d-announce

--NextPart--

Delivery-date: Thu, 20 Dec 2007 19:04:11 +0000
Date: Thu, 20 Dec 2007 10:53:51 -0800
From: "Richard Rabbat" <[email-masked]>
To: "Greg Bernstein" <[email-masked]>
Subject: Re: On Labels for Wavelength Switched Optical Networks...
Cc: ccamp <[email-masked]>

------=_Part_23283_11296360.1198176832020
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

hey Greg,
When you have a minute, can you send out the proposal for the slight tweak?
I put these together to make things simpler and they're perfect :)
Richard.

On Dec 20, 2007 7:39 AM, Greg Bernstein <[email-masked]> wrote:

>  Hi folks I've gotten a couple of questions on my note, so I wanted to
> clarify. The essence of the discussion below is to show that  no
> significantly simpler method exists to specify a global label for lambdas
> (in either frequency or wavelength) and that the label of [Otani] has the
> advantage of being based on a widely accepted and used standard.  I do not
> think that we need to modify the label of [Otani] in any significant way,
> though I have discussed with the authors a slight "tweak" to the CWDM format
> to more closely mirror the DWDM format.
>
> Regards
>
> Greg B.
>
>
> Greg Bernstein wrote:
>
> Hi folks, at the Vancouver meeting the lambda label format of Otani, et.
> al. draft-otani-ccamp-gmpls-lambda-labels-01.txt<http://tools.ietf.org/html/draft-otani-ccamp-gmpls-lambda-labels-01.txt>[Otani] was presented for a second time and a few new issues seemed to
> arise. I'm writing this note to see if we can resolve these on the list so
> this work can move forward, since the label format is valuable, in general,
> to the control of wavelength switched optical networks (WSON).
>
> First, a general 32 bit lambda label has been defined in RFC3471.  This
> previous label does not directly relate to either the wavelength or
> frequency of the light used in a lambda LSP in a standardized way (folks can
> use the 32 bits as they see fit).
> To come up with a completely general "lambda label" one could/should
> define both a (i) wavelength label specified in meters and (ii) a frequency
> label specified in Hertz (Hz).  These could be specified either with a 32
> bit IEEE floating point number or via a suitable 32 bit integer by suitably
> adjusting the base units.  We could represent the frequency via a 32 bit
> integer in MHz, then a 193.1THz light source could be characterized by the
> integer 193,100,000. Similarly we could represent the wavelength label via a
> 32 bit integer in pico meters (10-12 meters), then a 1550nm wavelength could
> be characterized by the integer 1,550,000.
>
>  Now any of the previous formats could be used with the 32 bit lambda
> label already defined.  The problem here is to pick a format for
> interoperability and compatibility with potentially common wavelength
> switched control operations.
> Issues with the previously mentioned formats:
>
> (a)    While floating point numbers provide great flexibility, as a label
> they have issues when it comes to comparison operations.
>
> (b)   An integer format with a suitably scaled exponent is relatively
> simple and just leaves the choice of "exponent" to be decided.
>
> (c)    Neither format contains any "context" information about the WDM
> system in general.
>
> The format proposed in [Otani]. avoids the above three issues and enhances
> common control plane operations as follows:
>
> (a)    The format is integer based, hence avoids issues with floating
> point comparisons.
>
> (b)   The format is based on the widely recognized ITU-T standard grids
> (ITU-T G.694.1 and .2) and fosters interoperability more than potentially
> any other choice.
>
> (c)    The ITU-T grids come in various widths and hence have an inherent
> growth path.
>
> (d)   The ITU-T grids come in both frequency (G.694.1) and wavelength (
> G.694.2) flavored versions an both are incorporated in the [Otani] label
> format.
>
> (e)    The format includes information on the grid spacing which is
> important WDM context information useful in many label selection processes.
> For example a tunable laser associated with a 50GHz spacing WDM system
> could specify acceptable label range via the inclusive range label set
> mechanism.  Note that only those frequencies (labels) that fall on the
> grid are supported and not intermediate frequencies.
>
>
> At the CCAMP WG meeting in Vancouver it was pointed out (by Lou Berger)
> that since a lambda label already exists and that existing implementations
> may make use of it that the proposed label of [Otani] would be better off
> referred to as a "G.694 label". With such a change I think that this label
> format (and accompanying draft) should move forward as a working group
> document.
>
> Comments, suggestions, issues?
>
> Regards
>
> Greg B.
>
> --
> ===================================================
> Dr Greg Bernstein, Grotto Networking (510) 573-2237
>
>
>
>
> --
> ===================================================
> Dr Greg Bernstein, Grotto Networking (510) 573-2237
>
>
>

------=_Part_23283_11296360.1198176832020
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

hey Greg,<br>When you have a minute, can you send out the proposal for the slight tweak? <br>I put these together to make things simpler and they&#39;re perfect :)<br>Richard.<br><br><div class="gmail_quote">On Dec 20, 2007 7:39 AM, Greg Bernstein &lt;
<a href="mailto:[email-masked]">[email-masked]</a>&gt; wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

<div bgcolor="#ffffff" text="#000000">
Hi folks I&#39;ve gotten a couple of questions on my note, so I wanted to
clarify. The essence of the discussion below is to show that&nbsp; no
significantly simpler
method exists to specify a global label for lambdas (in either
frequency or wavelength) and that the label of [Otani] has the
advantage of being based on a widely
accepted and used standard.&nbsp; I do not think that we need to modify the
label of [Otani] in any significant way, though I have discussed with
the authors a slight &quot;tweak&quot; to the CWDM format to more closely mirror
the DWDM format.<br>
<br>
Regards<br>
<br>
Greg B.<div><div></div><div class="Wj3C7c"><br>
<br>
Greg Bernstein wrote:
<blockquote type="cite">
  <p>Hi folks, at the Vancouver meeting the lambda label format of
Otani,
et. al.<a href="http://tools.ietf.org/html/draft-otani-ccamp-gmpls-lambda-labels-01.txt" target="_blank">
draft-otani-ccamp-gmpls-lambda-labels-01.txt</a> [Otani] was presented
for a second time and a few new issues seemed to arise. I&#39;m writing
this note to see if we can resolve these on the list so this work can
move forward, since the label format is valuable, in general, to the
control of wavelength switched optical networks (WSON).<br>
  </p>
  <p>First, a general 32 bit lambda label has been
defined in RFC3471.<span>&nbsp; </span>This previous label does
not directly relate
to either the wavelength or frequency of the light used in a lambda LSP
in a standardized way (folks can use the 32 bits as they see fit).<br>
To come up with a completely general &quot;lambda label&quot; one could/should
define both a (i)
wavelength label specified in meters and (ii) a frequency label
specified in
Hertz (Hz).<span>&nbsp; </span>These could be specified
either with a 32 bit IEEE floating point number or via a suitable 32
bit
integer by suitably adjusting the base units.<span>&nbsp;
  </span>We could represent the frequency via a 32 bit integer in MHz,
then a
193.1THz light source could be characterized by the integer
193,100,000.
Similarly we could represent the wavelength label via a 32 bit integer
in pico
meters (10-12 meters), then a 1550nm wavelength could be characterized
by the
integer 1,550,000.</p>
  <p>&nbsp;Now any of the previous formats
could
be used with the 32
bit lambda label already defined.<span>&nbsp; </span>The
problem here is to pick a format for interoperability and compatibility
with
potentially common wavelength switched control operations.<br>
  Issues with the previously mentioned formats:</p>
  <p style="margin-left: 0.5in; text-indent: -0.25in;"><span>(a)<span style="font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-size-adjust: none; font-stretch: normal;">
&nbsp;&nbsp;&nbsp;
  </span></span>While
floating point numbers provide great flexibility, as a label they have
issues
when it comes to comparison operations.<span>&nbsp; </span></p>
  <p style="margin-left: 0.5in; text-indent: -0.25in;"><span>(b)<span style="font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-size-adjust: none; font-stretch: normal;">
&nbsp;&nbsp;
  </span></span>An
integer format with a suitably scaled exponent is relatively simple and
just
leaves the choice of "exponent" to be decided.</p>
  <p style="margin-left: 0.5in; text-indent: -0.25in;"><span>(c)<span style="font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-size-adjust: none; font-stretch: normal;">
&nbsp;&nbsp;&nbsp;
  </span></span>Neither
format contains any "context" information about the WDM system in
general.</p>
  <p>The format proposed in [Otani]. avoids the above
three
issues and enhances common control plane operations as follows:</p>
  <p style="margin-left: 0.5in; text-indent: -0.25in;"><span>(a)<span style="font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-size-adjust: none; font-stretch: normal;">
&nbsp;&nbsp;&nbsp;
  </span></span>The
format is integer based, hence avoids issues with floating point
comparisons.</p>
  <p style="margin-left: 0.5in; text-indent: -0.25in;"><span>(b)<span style="font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-size-adjust: none; font-stretch: normal;">
&nbsp;&nbsp;
  </span></span>The
format is based on the widely recognized ITU-T standard grids (ITU-T
G.694.1 and .2) and
fosters interoperability more than potentially any other choice.&nbsp;<span></span></p>
  <p style="margin-left: 0.5in; text-indent: -0.25in;"><span>(c)<span style="font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-size-adjust: none; font-stretch: normal;">
&nbsp;&nbsp;&nbsp;
  </span></span>The
ITU-T grids come in various widths and hence have an inherent growth
path.</p>
  <p style="margin-left: 0.5in; text-indent: -0.25in;"><span>(d)<span style="font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-size-adjust: none; font-stretch: normal;">
&nbsp;&nbsp;
  </span></span>The
ITU-T grids come in both frequency (G.694.1) and wavelength (G.694.2)
flavored
versions an both are incorporated in the [Otani] label format.</p>
  <p style="margin-left: 0.5in; text-indent: -0.25in;"><span>(e)<span style="font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-size-adjust: none; font-stretch: normal;">
&nbsp;&nbsp;&nbsp;
  </span></span>The
format includes information on the grid spacing which is important WDM
context
information useful in many label selection processes.<span>&nbsp; </span>For
example a tunable laser associated with a
50GHz spacing WDM system could specify acceptable label range via the
inclusive
range label set mechanism.<span>&nbsp; </span>Note that
only those frequencies (labels) that fall on the grid are supported and
not
intermediate frequencies.</p>
  <p>&nbsp;<br>
At the CCAMP WG meeting in Vancouver it was pointed out (by Lou Berger)
that
since a lambda label already exists and that existing implementations
may make
use of it that the proposed label of [Otani] would be better off
referred to as a
"G.694 label". With such a change I think that this label format (and
accompanying draft) should move forward as a working group document.<br>
  </p>
  <p>Comments, suggestions, issues?<br>
  </p>
  <p>Regards<br>
  </p>
  <p>Greg B.<br>
  </p>
  <pre cols="72">-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237

  </pre>
</blockquote>
<br>
<pre cols="72">-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237

</pre>
</div></div></div>

</blockquote></div><br>

------=_Part_23283_11296360.1198176832020--

Delivery-date: Thu, 20 Dec 2007 17:35:17 +0000
Date: Thu, 20 Dec 2007 09:32:01 -0800
From: Greg Bernstein <[email-masked]>
To: Adrian Farrel <[email-masked]>
CC: [email-masked]
Subject: Re: Liaison received from ITU-T on T-MPLS ring protection

Hi all, it seems to me there maybe some implications for GMPLS based on 
previous experience with "software based 4F-BLSRs", that is rings that 
are setup on portions of a mesh network to provide fast redundant 
protection using SDH like ring switching mechanisms.
These types of rings which are applicable to a number of layers 
(optical, SDH, whatever) have traditionally had interoperability 
problems across vendors.  This has typically involved how to share the 
"ring map" information (see section 17.1 of the liaison attachment). In 
addition "nodes" need information on connections added and dropped so 
they can prevent mis-connection (the "squelching" process).

Obviously one way to keep track of a ring map is to "mark" a link as 
belonging to a particular ring and distribute this info via GMPLS routing.

Regards

Greg B.

Adrian Farrel wrote:
> Hi,
>
> We received a liaison from the ITU-T that reads as follows...
>
>   SG15 Q9 has nearly completed its work on a recommendation for
>   T-MPLS Ring Protection - G.8132. It is targeted to consent this
>   new recommendation in the next SG15 plenary meeting scheduled
>   for Feb., 2008.
>
>   We have attached the latest draft for your information and
>   comments.
>
> We are requested to comment by 11th February 2008.
>
> At first glance, this work appears to concentrate on the data plane 
> only and so is not within our scope. The MPLS working group was also 
> copied and can handle any issues concerning the MPLS data plane.
>
> As always, you can see all incoming and outgoing communications for 
> CCAMP at www.olddog.co.uk/ccamp.htm
>
> Thanks,
> Adrian
>
>
>

-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237

Delivery-date: Thu, 20 Dec 2007 15:42:36 +0000
Date: Thu, 20 Dec 2007 07:39:06 -0800
From: Greg Bernstein <[email-masked]>
To: ccamp <[email-masked]>
Subject: Re: On Labels for Wavelength Switched Optical Networks...

This is a multi-part message in MIME format.
--------------040304080106020609050803
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi folks I've gotten a couple of questions on my note, so I wanted to 
clarify. The essence of the discussion below is to show that  no 
significantly simpler method exists to specify a global label for 
lambdas (in either frequency or wavelength) and that the label of 
[Otani] has the advantage of being based on a widely accepted and used 
standard.  I do not think that we need to modify the label of [Otani] in 
any significant way, though I have discussed with the authors a slight 
"tweak" to the CWDM format to more closely mirror the DWDM format.

Regards

Greg B.

Greg Bernstein wrote:
>
> Hi folks, at the Vancouver meeting the lambda label format of Otani, 
> et. al. draft-otani-ccamp-gmpls-lambda-labels-01.txt 
> <http://tools.ietf.org/html/draft-otani-ccamp-gmpls-lambda-labels-01.txt> 
> [Otani] was presented for a second time and a few new issues seemed to 
> arise. I'm writing this note to see if we can resolve these on the 
> list so this work can move forward, since the label format is 
> valuable, in general, to the control of wavelength switched optical 
> networks (WSON).
>
> First, a general 32 bit lambda label has been defined in RFC3471.  
> This previous label does not directly relate to either the wavelength 
> or frequency of the light used in a lambda LSP in a standardized way 
> (folks can use the 32 bits as they see fit).
> To come up with a completely general "lambda label" one could/should 
> define both a (i) wavelength label specified in meters and (ii) a 
> frequency label specified in Hertz (Hz).  These could be specified 
> either with a 32 bit IEEE floating point number or via a suitable 32 
> bit integer by suitably adjusting the base units.  We could represent 
> the frequency via a 32 bit integer in MHz, then a 193.1THz light 
> source could be characterized by the integer 193,100,000. Similarly we 
> could represent the wavelength label via a 32 bit integer in pico 
> meters (10-12 meters), then a 1550nm wavelength could be characterized 
> by the integer 1,550,000.
>
>  Now any of the previous formats could be used with the 32 bit lambda 
> label already defined.  The problem here is to pick a format for 
> interoperability and compatibility with potentially common wavelength 
> switched control operations.
> Issues with the previously mentioned formats:
>
> (a)    While floating point numbers provide great flexibility, as a 
> label they have issues when it comes to comparison operations. 
>
> (b)   An integer format with a suitably scaled exponent is relatively 
> simple and just leaves the choice of "exponent" to be decided.
>
> (c)    Neither format contains any "context" information about the WDM 
> system in general.
>
> The format proposed in [Otani]. avoids the above three issues and 
> enhances common control plane operations as follows:
>
> (a)    The format is integer based, hence avoids issues with floating 
> point comparisons.
>
> (b)   The format is based on the widely recognized ITU-T standard 
> grids (ITU-T G.694.1 and .2) and fosters interoperability more than 
> potentially any other choice. 
>
> (c)    The ITU-T grids come in various widths and hence have an 
> inherent growth path.
>
> (d)   The ITU-T grids come in both frequency (G.694.1) and wavelength 
> (G.694.2) flavored versions an both are incorporated in the [Otani] 
> label format.
>
> (e)    The format includes information on the grid spacing which is 
> important WDM context information useful in many label selection 
> processes.  For example a tunable laser associated with a 50GHz 
> spacing WDM system could specify acceptable label range via the 
> inclusive range label set mechanism.  Note that only those frequencies 
> (labels) that fall on the grid are supported and not intermediate 
> frequencies.
>
>  
> At the CCAMP WG meeting in Vancouver it was pointed out (by Lou 
> Berger) that since a lambda label already exists and that existing 
> implementations may make use of it that the proposed label of [Otani] 
> would be better off referred to as a "G.694 label". With such a change 
> I think that this label format (and accompanying draft) should move 
> forward as a working group document.
>
> Comments, suggestions, issues?
>
> Regards
>
> Greg B.
>
> -- 
> ===================================================
> Dr Greg Bernstein, Grotto Networking (510) 573-2237
>
>   

-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237

--------------040304080106020609050803
Content-Type: text/html; charset=ISO-8859-1
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">
</head>
<body bgcolor="#ffffff" text="#000000">
Hi folks I've gotten a couple of questions on my note, so I wanted to
clarify. The essence of the discussion below is to show that&nbsp; no
significantly simpler
method exists to specify a global label for lambdas (in either
frequency or wavelength) and that the label of [Otani] has the
advantage of being based on a widely
accepted and used standard.&nbsp; I do not think that we need to modify the
label of [Otani] in any significant way, though I have discussed with
the authors a slight "tweak" to the CWDM format to more closely mirror
the DWDM format.<br>
<br>
Regards<br>
<br>
Greg B.<br>
<br>
Greg Bernstein wrote:
<blockquote cite="mid:[email-masked]"
 type="cite">
  <p>Hi folks, at the Vancouver meeting the lambda label format of
Otani,
et. al.<a moz-do-not-send="true"
 href="http://tools.ietf.org/html/draft-otani-ccamp-gmpls-lambda-labels-01.txt">
draft-otani-ccamp-gmpls-lambda-labels-01.txt</a> [Otani] was presented
for a second time and a few new issues seemed to arise. I'm writing
this note to see if we can resolve these on the list so this work can
move forward, since the label format is valuable, in general, to the
control of wavelength switched optical networks (WSON).<br>
  </p>
  <p class="MsoNormal">First, a general 32 bit lambda label has been
defined in RFC3471.<span style="">&nbsp; </span>This previous label does
not directly relate
to either the wavelength or frequency of the light used in a lambda LSP
in a standardized way (folks can use the 32 bits as they see fit).<br>
To come up with a completely general "lambda label" one could/should
define both a (i)
wavelength label specified in meters and (ii) a frequency label
specified in
Hertz (Hz).<span style="">&nbsp; </span>These could be specified
either with a 32 bit IEEE floating point number or via a suitable 32
bit
integer by suitably adjusting the base units.<span style="">&nbsp;
  </span>We could represent the frequency via a 32 bit integer in MHz,
then a
193.1THz light source could be characterized by the integer
193,100,000.
Similarly we could represent the wavelength label via a 32 bit integer
in pico
meters (10-12 meters), then a 1550nm wavelength could be characterized
by the
integer 1,550,000.</p>
  <p class="MsoNormal"><o:p>&nbsp;</o:p>Now any of the previous formats
could
be used with the 32
bit lambda label already defined.<span style="">&nbsp; </span>The
problem here is to pick a format for interoperability and compatibility
with
potentially common wavelength switched control operations.<br>
  <o:p></o:p>Issues with the previously mentioned formats:</p>
  <p class="MsoNormal" style="margin-left: 0.5in; text-indent: -0.25in;"><!--[if !supportLists]--><span
 style="">(a)<span
 style="font-family: &quot;Times New Roman&quot;; font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-size-adjust: none; font-stretch: normal;">&nbsp;&nbsp;&nbsp;
  </span></span><!--[endif]-->While
floating point numbers provide great flexibility, as a label they have
issues
when it comes to comparison operations.<span style="">&nbsp; </span></p>
  <p class="MsoNormal" style="margin-left: 0.5in; text-indent: -0.25in;"><!--[if !supportLists]--><span
 style="">(b)<span
 style="font-family: &quot;Times New Roman&quot;; font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-size-adjust: none; font-stretch: normal;">&nbsp;&nbsp;
  </span></span><!--[endif]-->An
integer format with a suitably scaled exponent is relatively simple and
just
leaves the choice of &#8220;exponent&#8221; to be decided.</p>
  <p class="MsoNormal" style="margin-left: 0.5in; text-indent: -0.25in;"><!--[if !supportLists]--><span
 style="">(c)<span
 style="font-family: &quot;Times New Roman&quot;; font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-size-adjust: none; font-stretch: normal;">&nbsp;&nbsp;&nbsp;
  </span></span><!--[endif]-->Neither
format contains any &#8220;context&#8221; information about the WDM system in
general.</p>
  <p class="MsoNormal">The format proposed in [Otani]. avoids the above
three
issues and enhances common control plane operations as follows:</p>
  <p class="MsoNormal" style="margin-left: 0.5in; text-indent: -0.25in;"><!--[if !supportLists]--><span
 style="">(a)<span
 style="font-family: &quot;Times New Roman&quot;; font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-size-adjust: none; font-stretch: normal;">&nbsp;&nbsp;&nbsp;
  </span></span><!--[endif]-->The
format is integer based, hence avoids issues with floating point
comparisons.</p>
  <p class="MsoNormal" style="margin-left: 0.5in; text-indent: -0.25in;"><!--[if !supportLists]--><span
 style="">(b)<span
 style="font-family: &quot;Times New Roman&quot;; font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-size-adjust: none; font-stretch: normal;">&nbsp;&nbsp;
  </span></span><!--[endif]-->The
format is based on the widely recognized ITU-T standard grids (ITU-T
G.694.1 and .2) and
fosters interoperability more than potentially any other choice.&nbsp;<span
 style=""></span></p>
  <p class="MsoNormal" style="margin-left: 0.5in; text-indent: -0.25in;"><!--[if !supportLists]--><span
 style="">(c)<span
 style="font-family: &quot;Times New Roman&quot;; font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-size-adjust: none; font-stretch: normal;">&nbsp;&nbsp;&nbsp;
  </span></span><!--[endif]-->The
ITU-T grids come in various widths and hence have an inherent growth
path.</p>
  <p class="MsoNormal" style="margin-left: 0.5in; text-indent: -0.25in;"><!--[if !supportLists]--><span
 style="">(d)<span
 style="font-family: &quot;Times New Roman&quot;; font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-size-adjust: none; font-stretch: normal;">&nbsp;&nbsp;
  </span></span><!--[endif]-->The
ITU-T grids come in both frequency (G.694.1) and wavelength (G.694.2)
flavored
versions an both are incorporated in the [Otani] label format.</p>
  <p class="MsoNormal" style="margin-left: 0.5in; text-indent: -0.25in;"><!--[if !supportLists]--><span
 style="">(e)<span
 style="font-family: &quot;Times New Roman&quot;; font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-size-adjust: none; font-stretch: normal;">&nbsp;&nbsp;&nbsp;
  </span></span><!--[endif]-->The
format includes information on the grid spacing which is important WDM
context
information useful in many label selection processes.<span style="">&nbsp; </span>For
example a tunable laser associated with a
50GHz spacing WDM system could specify acceptable label range via the
inclusive
range label set mechanism.<span style="">&nbsp; </span>Note that
only those frequencies (labels) that fall on the grid are supported and
not
intermediate frequencies.</p>
  <p class="MsoNormal"><o:p>&nbsp;</o:p><br>
At the CCAMP WG meeting in Vancouver it was pointed out (by Lou Berger)
that
since a lambda label already exists and that existing implementations
may make
use of it that the proposed label of [Otani] would be better off
referred to as a
&#8220;G.694 label&#8221;. With such a change I think that this label format (and
accompanying draft) should move forward as a working group document.<br>
  </p>
  <p class="MsoNormal">Comments, suggestions, issues?<br>
  </p>
  <p class="MsoNormal">Regards<br>
  </p>
  <p class="MsoNormal">Greg B.<br>
  </p>
  <pre class="moz-signature" cols="72">-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237

  </pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237

</pre>
</body>
</html>

--------------040304080106020609050803--

Delivery-date: Mon, 17 Dec 2007 22:01:55 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Ross Callon" <[email-masked]>
Cc: <[email-masked]>, "WG Milestone Tracker" <[email-masked]>, <[email-masked]>
Subject: Please publish draft-ietf-ccamp-gmpls-mln-eval-05
Date: Mon, 17 Dec 2007 21:28:10 -0000

Hi,

Here is the proto write-up for draft-ietf-ccamp-gmpls-mln-eval-05

Thanks,
Adrian

===

Proto-write-up for draft-ietf-ccamp-gmpls-mln-eval-05

Intended status : Informational

Recommend that this I-D is progressed in parallel with 
draft-ietf-ccamp-gmpls-mln-reqs-07.txt requested for publication at
the same time.

> (1.a)  Who is the Document Shepherd for this document?  Has the
>        Document Shepherd personally reviewed this version of the
>        document and, in particular, does he or she believe this
>        version is ready for forwarding to the IESG for publication?

Adrian Farrel is the document shepherd.
He has personally reviewed the I-D and believes it is ready for
forwarding to the IESG for publication.

> (1.b)  Has the document had adequate review both from key WG members
>        and from key non-WG members?  Does the Document Shepherd have
>        any concerns about the depth or breadth of the reviews that
>        have been performed?

Long list of authors/contributors/acknowledgees.

This document has been reviewed by the CCAMP working group and received
some comments at IETF meetings and on the mailing list. 

In addition, the I-D received thorough review on liaison from Question
14 of Study Group 15 of the ITU-T.

These reviews have been sufficiently deep and broad.

> (1.c)  Does the Document Shepherd have concerns that the document
>        needs more review from a particular or broader perspective,
>        e.g., security, operational complexity, someone familiar with
>        AAA, internationalization or XML?

No concerns.

> (1.d)  Does the Document Shepherd have any specific concerns or
>        issues with this document that the Responsible Area Director
>        and/or the IESG should be aware of?  For example, perhaps he
>        or she is uncomfortable with certain parts of the document, or
>        has concerns whether there really is a need for it.  In any
>        event, if the WG has discussed those issues and has indicated
>        that it still wishes to advance the document, detail those
>        concerns here.  Has an IPR disclosure related to this document
>        been filed?  If so, please include a reference to the
>        disclosure and summarize the WG discussion and conclusion on
>        this issue.

The document is sound.

> (1.e)  How solid is the WG consensus behind this document?  Does it
>        represent the strong concurrence of a few individuals, with
>        others being silent, or does the WG as a whole understand and
>        agree with it?

There were no problems with consensus for this document.

> (1.f)  Has anyone threatened an appeal or otherwise indicated extreme
>        discontent?  If so, please summarise the areas of conflict in
>        separate email messages to the Responsible Area Director.  (It
>        should be in a separate email because this questionnaire is
>        entered into the ID Tracker.)

No threats. No discontent.

> (1.g)  Has the Document Shepherd personally verified that the
>        document satisfies all ID nits?  (See
>        http://www.ietf.org/ID-Checklist.html and
>        http://tools.ietf.org/tools/idnits/).  Boilerplate checks are
>        not enough; this check needs to be thorough.  Has the document
>        met all formal review criteria it needs to, such as the MIB
>        Doctor, media type and URI type reviews?

All checks made.

> (1.h)  Has the document split its references into normative and
>        informative?  Are there normative references to documents that
>        are not ready for advancement or are otherwise in an unclear
>        state?  If such normative references exist, what is the
>        strategy for their completion?  Are there normative references
>        that are downward references, as described in [RFC3967]?  If
>        so, list these downward references to support the Area
>        Director in the Last Call procedure for them [RFC3967].

References split.
No downrefs.

> (1.i)  Has the Document Shepherd verified that the document IANA
>        consideration section exists and is consistent with the body
>        of the document?  If the document specifies protocol
>        extensions, are reservations requested in appropriate IANA
>        registries?  Are the IANA registries clearly identified?  If
>        the document creates a new registry, does it define the
>        proposed initial contents of the registry and an allocation
>        procedure for future registrations?  Does it suggest a
>        reasonable name for the new registry?  See [RFC2434].  If the
>        document describes an Expert Review process has Shepherd
>        conferred with the Responsible Area Director so that the IESG
>        can appoint the needed Expert during the IESG Evaluation?

This is an Informational I-D.
A null IANA section is present.

> (1.j)  Has the Document Shepherd verified that sections of the
>        document that are written in a formal language, such as XML
>        code, BNF rules, MIB definitions, etc., validate correctly in
>        an automated checker?

No such sections.

> (1.k)  The IESG approval announcement includes a Document
>        Announcement Write-Up.  Please provide such a Document
>        Announcement Write-Up.  Recent examples can be found in the
>        "Action" announcements for approved documents.  The approval
>        announcement contains the following sections:
>
>        Technical Summary
>           Relevant content can frequently be found in the abstract
>           and/or introduction of the document.  If not, this may be
>           an indication that there are deficiencies in the abstract
>           or introduction.

This document provides an evaluation of Generalized Multi-Protocol
Label Switching (GMPLS) protocols and mechanisms against the
requirements for Multi-Layer Networks (MLN) and Multi-Region Networks
(MRN). In addition, this document identifies areas where additional
protocol extensions or procedures are needed to satisfy these
requirements, and provides guidelines for potential extensions.

>        Working Group Summary
>           Was there anything in WG process that is worth noting?  For
>           example, was there controversy about particular points or
>           were there decisions where the consensus was particularly
>           rough?

Nothing of note.

>        Document Quality
>           Are there existing implementations of the protocol?  Have a
>           significant number of vendors indicated their plan to
>           implement the specification?  Are there any reviewers that
>           merit special mention as having done a thorough review,
>           e.g., one that resulted in important changes or a
>           conclusion that the document had no substantive issues?  If
>           there was a MIB Doctor, Media Type or other expert review,
>           what was its course (briefly)?  In the case of a Media Type
>           review, on what date was the request posted?

This is an Informational I-D with no protocol specifications.
Expert review of multi-layer network architecture was received from
the ITU-T.

Delivery-date: Mon, 17 Dec 2007 21:30:10 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Ross Callon" <[email-masked]>
Cc: <[email-masked]>, "WG Milestone Tracker" <[email-masked]>, <[email-masked]>
Subject: Please publish draft-ietf-ccamp-gmpls-mln-reqs-07
Date: Mon, 17 Dec 2007 21:25:39 -0000

Here is the proto write-up for draft-ietf-ccamp-gmpls-mln-reqs-07

Thanks,
Adrian

===

Proto-write-up for draft-ietf-ccamp-gmpls-mln-reqs-07

Intended status : Informational

Recommend that this I-D is progressed in parallel with
draft-ietf-ccamp-gmpls-mln-eval-05.txt requested for publication at
the same time.

> (1.a)  Who is the Document Shepherd for this document?  Has the
>        Document Shepherd personally reviewed this version of the
>        document and, in particular, does he or she believe this
>        version is ready for forwarding to the IESG for publication?

Adrian Farrel is the document shepherd.
He has personally reviewed the I-D and believes it is ready for
forwarding to the IESG for publication.

> (1.b)  Has the document had adequate review both from key WG members
>        and from key non-WG members?  Does the Document Shepherd have
>        any concerns about the depth or breadth of the reviews that
>        have been performed?

Long list of authors/contributors.

This document has been reviewed by the CCAMP working group and
discussed quite extensively at IETF meetings and on the mailing list.

In addition, the I-D received thorough review on liaison from Question
14 of Study Group 15 of the ITU-T.

These reviews have been sufficiently deep and broad.

> (1.c)  Does the Document Shepherd have concerns that the document
>        needs more review from a particular or broader perspective,
>        e.g., security, operational complexity, someone familiar with
>        AAA, internationalization or XML?

No concerns.

> (1.d)  Does the Document Shepherd have any specific concerns or
>        issues with this document that the Responsible Area Director
>        and/or the IESG should be aware of?  For example, perhaps he
>        or she is uncomfortable with certain parts of the document, or
>        has concerns whether there really is a need for it.  In any
>        event, if the WG has discussed those issues and has indicated
>        that it still wishes to advance the document, detail those
>        concerns here.  Has an IPR disclosure related to this document
>        been filed?  If so, please include a reference to the
>        disclosure and summarize the WG discussion and conclusion on
>        this issue.

The document is sound.

An IPR disclosure can be found at https://datatracker.ietf.org/ipr/518/
and was filed against the -00 version of this I-D when it was still an
individual submission.

This was brought to the attention of the working group, but no-one had
any issues. Since this is an Informational Requirements I-D, it might
be unlikely that there would be any implementation of the I-D to be
impacted by the IPR claim.

> (1.e)  How solid is the WG consensus behind this document?  Does it
>        represent the strong concurrence of a few individuals, with
>        others being silent, or does the WG as a whole understand and
>        agree with it?

There were no problems with consensus for this document.

> (1.f)  Has anyone threatened an appeal or otherwise indicated extreme
>        discontent?  If so, please summarise the areas of conflict in
>        separate email messages to the Responsible Area Director.  (It
>        should be in a separate email because this questionnaire is
>        entered into the ID Tracker.)

No threats. No discontent.

> (1.g)  Has the Document Shepherd personally verified that the
>        document satisfies all ID nits?  (See
>        http://www.ietf.org/ID-Checklist.html and
>        http://tools.ietf.org/tools/idnits/).  Boilerplate checks are
>        not enough; this check needs to be thorough.  Has the document
>        met all formal review criteria it needs to, such as the MIB
>        Doctor, media type and URI type reviews?

All checks made.

> (1.h)  Has the document split its references into normative and
>        informative?  Are there normative references to documents that
>        are not ready for advancement or are otherwise in an unclear
>        state?  If such normative references exist, what is the
>        strategy for their completion?  Are there normative references
>        that are downward references, as described in [RFC3967]?  If
>        so, list these downward references to support the Area
>        Director in the Last Call procedure for them [RFC3967].

References split.
No downrefs.

> (1.i)  Has the Document Shepherd verified that the document IANA
>        consideration section exists and is consistent with the body
>        of the document?  If the document specifies protocol
>        extensions, are reservations requested in appropriate IANA
>        registries?  Are the IANA registries clearly identified?  If
>        the document creates a new registry, does it define the
>        proposed initial contents of the registry and an allocation
>        procedure for future registrations?  Does it suggest a
>        reasonable name for the new registry?  See [RFC2434].  If the
>        document describes an Expert Review process has Shepherd
>        conferred with the Responsible Area Director so that the IESG
>        can appoint the needed Expert during the IESG Evaluation?

This is an Informational I-D.
A null IANA section is present.

> (1.j)  Has the Document Shepherd verified that sections of the
>        document that are written in a formal language, such as XML
>        code, BNF rules, MIB definitions, etc., validate correctly in
>        an automated checker?

No such sections.

> (1.k)  The IESG approval announcement includes a Document
>        Announcement Write-Up.  Please provide such a Document
>        Announcement Write-Up.  Recent examples can be found in the
>        "Action" announcements for approved documents.  The approval
>        announcement contains the following sections:
>
>        Technical Summary
>           Relevant content can frequently be found in the abstract
>           and/or introduction of the document.  If not, this may be
>           an indication that there are deficiencies in the abstract
>           or introduction.

Most of the initial efforts to utilize Generalized MPLS (GMPLS)
have been related to environments hosting devices with a single
switching capability. The complexity raised by the control of such
data planes is similar to that seen in classical IP/MPLS networks.
By extending MPLS to support multiple switching technologies, GMPLS
provides a comprehensive framework for the control of a multi-
layered network of either a single switching technology or multiple
switching technologies.

In GMPLS, a switching technology domain defines a region, and a
network of multiple switching types is referred to in this document
as a Multi-Region Network (MRN). When referring in general to a
layered network, which may consist of either a single or multiple
regions, this document uses the term, Multi-Layer Network (MLN).

This document defines a framework for GMPLS based multi-region/
multi-layer networks and lists a set of functional requirements.

>        Working Group Summary
>           Was there anything in WG process that is worth noting?  For
>           example, was there controversy about particular points or
>           were there decisions where the consensus was particularly
>           rough?

There was some unresolved debate about the term "virtual TE link" and
whether it should be replaced with "potential TE link". However, since
the former had been in use for a long time and was used in published
RFCs, and since there was not great support for a change, we retained
"virtual".

>        Document Quality
>           Are there existing implementations of the protocol?  Have a
>           significant number of vendors indicated their plan to
>           implement the specification?  Are there any reviewers that
>           merit special mention as having done a thorough review,
>           e.g., one that resulted in important changes or a
>           conclusion that the document had no substantive issues?  If
>           there was a MIB Doctor, Media Type or other expert review,
>           what was its course (briefly)?  In the case of a Media Type
>           review, on what date was the request posted?

This is an Informational I-D with no protocol specifications.
Expert review of multi-layer network architecture was received from
the ITU-T.

Delivery-date: Mon, 17 Dec 2007 21:17:52 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Update: draft-ietf-ccamp-gmpls-mln-eval-05.txt 
Date: Mon, 17 Dec 2007 21:16:32 -0000

Hi,

Only changes are format and I-D nits necessary to advance the I-D to the AD 
for review.

Adrian
----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, December 17, 2007 9:10 PM
Subject: I-D Action:draft-ietf-ccamp-gmpls-mln-eval-05.txt

>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           : Evaluation of existing GMPLS Protocols against Multi 
> Layer and Multi Region Networks (MLN/MRN)
> Author(s)       : J. Le Roux, et al.
> Filename        : draft-ietf-ccamp-gmpls-mln-eval-05.txt
> Pages           : 16
> Date            : 2007-12-17
>
> This document provides an evaluation of Generalized Multi-Protocol
> Label Switching (GMPLS) protocols and mechanisms against the
> requirements for Multi-Layer Networks (MLN) and Multi-Region Networks
> (MRN). In addition, this document identifies areas where additional
> protocol extensions or procedures are needed to satisfy these
> requirements, and provides guidelines for potential extensions.Conventions
> used in this document
>
> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
> document are to be interpreted as described in RFC-2119.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-mln-eval-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-gmpls-mln-eval-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-gmpls-mln-eval-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.
>

--------------------------------------------------------------------------------

> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/i-d-announce
> 

Delivery-date: Mon, 17 Dec 2007 21:12:31 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D Action:draft-ietf-ccamp-gmpls-mln-eval-05.txt 
Date: Mon, 17 Dec 2007 16:10:02 -0500

--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           : Evaluation of existing GMPLS Protocols against Multi Layer and Multi Region Networks (MLN/MRN)
	Author(s)       : J. Le Roux, et al.
	Filename        : draft-ietf-ccamp-gmpls-mln-eval-05.txt
	Pages           : 16
	Date            : 2007-12-17

This document provides an evaluation of Generalized Multi-Protocol
Label Switching (GMPLS) protocols and mechanisms against the
requirements for Multi-Layer Networks (MLN) and Multi-Region Networks
(MRN). In addition, this document identifies areas where additional
protocol extensions or procedures are needed to satisfy these
requirements, and provides guidelines for potential extensions.Conventions
used in this document

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-mln-eval-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-gmpls-mln-eval-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-gmpls-mln-eval-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-gmpls-mln-eval-05.txt

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

Content-Type: text/plain
Content-ID:     <2007-12-17160517.I-D\@ietf.org>

--OtherAccess--

--NextPart--

Delivery-date: Mon, 17 Dec 2007 16:25:53 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Liaison received from ITU-T on T-MPLS ring protection
Date: Mon, 17 Dec 2007 16:18:45 -0000

 Hi,

We received a liaison from the ITU-T that reads as follows...

   SG15 Q9 has nearly completed its work on a recommendation for
   T-MPLS Ring Protection - G.8132. It is targeted to consent this
   new recommendation in the next SG15 plenary meeting scheduled
   for Feb., 2008.

   We have attached the latest draft for your information and
   comments.

We are requested to comment by 11th February 2008.

At first glance, this work appears to concentrate on the data plane only and 
so is not within our scope. The MPLS working group was also copied and can 
handle any issues concerning the MPLS data plane.

As always, you can see all incoming and outgoing communications for CCAMP at 
www.olddog.co.uk/ccamp.htm

Thanks,
Adrian 

Delivery-date: Mon, 17 Dec 2007 14:58:21 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Draft response to the OIF
Date: Mon, 17 Dec 2007 14:50:46 -0000

Hi,

The OIF sent us a communication (http://www.olddog.co.uk/oif2007_382_01.pdf) 
with some specific questions about the use of GMPLS protocols.

Here is a draft response. Thanks to Lou Berger for the bulk of this text.

Comments please before I send this around Christmas.

Thanks,
Adrian
===

To : Lyndon Ong, OIF TC Chair <[email-masked]>
Cc: Ross Callon, IETF Routing Area Director <[email-masked]>
    David Ward, IETF Routing Area Director <[email-masked]>

Subject: Response to Your Questions about GMPLS Protocol Usage

Dear Lyndon,

Thanks for your communication dated 29th November 2007 and your subsequent 
email exchange with clarifications.

Please find below responses from CCAMP experts to the questions you posed.

May we take this oportunity to stress that we are open to receiving such 
questions in a less formal way either directly or through the CCAMP mailing 
list, and may be able to provide timely responses during the course of your 
testing events.

> 1) One of the features provided in the OIF UNI 2.0 is the ability to
> non-disruptively modify service attributes associated with an LSP. The
> modification of the service attributes is limited to LSPs that were
> initiated using Shared Explicit filter style. Modification is performed
> by signaling a new LSP that utilizes the same Tunnel ID as the original
> LSP but with the new service parameters. Once the new LSP state is
> established, the original LSP state is removed.

There are two distinct options for modifying an LSP. The first is "in-place" 
modification where a new trigger Path message is sent for an existing LSP. 
The second is the "make-before-break" approach to tunnel/service 
modification first introduced in RFC 3209. You appear to be refering to the 
latter case since you mention a new LSP.

> Non-disruptive modification was demonstrated in the 2007
> interoperability test by modifying the bandwidth of an LSP realized by a
> SONET/SDH VCAT group. In the process of testing, a number of questions
> arose regarding the RESV message flow. These questions included:
>
> - How many RESV messages are expected to be generated? Is it one since
>   the resources in use by both LSPs are the same, or two since the LSPs
>   are handled through separate signaling sessions.

In make-before-break, each LSP is signaled independently.  Per LSP Resv 
messages should be expected.  Assuming the old LSP is in-place at the time 
of signaling the new LSP, and only one Path message is issued, then only one 
Resv would be expected. That is, a Resv for the new LSP, but no further Resv 
for the existing LSP.

When the old LSP is also modified as part of the make-before-break, e.g., to 
update administrative status prior to alarm-free tear-down, then a Resv 
message on the old LSP may also be generated.

> - What is the bandwidth amount that should be reflected in the RESV
>   messages? If separate RESV messages are generated for both LSPs, is it
>   the bandwidth requested in the corresponding PATH message? Or is it
>   the actual bandwidth being provided by the connection at the time the
>   RESV message is generated?

According to RFC 4606:

    For a particular sender in a session, the contents of the FLOWSPEC
    object received in a Resv message SHOULD be identical to the contents
    of the SENDER_TSPEC object received in the corresponding Path
    message.  If the objects do not match, a ResvErr message with a
    "Traffic Control Error/Bad Flowspec value" error SHOULD be generated.

 Again, in make-before-break, each LSP is signaled independently.

> In the interop test both approaches were observed. To facilitate the
> subsequent demonstration, receivers were expected to handle both cases.
>
> 2) In the process of testing, we found that not all implementations
> included Explicit Route Objects (ERO) in PATH messages when performing
> graceful deletion, even though earlier PATH messages for the LSP had
> included an ERO. For some intermediate node implementations, the lack of
> the ERO was seen as removing the 'pinned' nature of the connection,
> causing the node to interpret the PATH message as requiring a new path
> computation which may end up using a different route. Other
> implementations utilized the Session and Sender Template to relate the
> received PATH message with the existing connection thereby identifying
> the path the message should be forwarded on. This approach was taken by
> these implementations since inclusion of an ERO is not mandatory. We
> would appreciate CCAMP's thoughts on what the behavior should be.

As described in RFC 2205, Path and Resv messages are idempotent.  This means 
that any Path message reflects full state, and differences between one Path 
message and a subsequent Path message may be reasonably considered an 
explicit change. Therefore, while there is no explicit requirement stated in 
RFC 3473, it is typical to only modify the Admin Status Object in Path 
messages sent in connection to RFC 3473 section 7.2.1. deletion procedures 
(i.e. to include the full ERO as on previous Path messages).

It may be observed, however, that while an implementation detecting a change 
in ERO (such as the removal of the ERO) may legitimately opt to reroute, 
that implementation should also note the change in Admin Status associated 
with the graceful deletion and may "assume" that such a reroute would be a 
waste of time. Further, in a transport system, implementaitons should only 
perform local reroutes (deviating from in-place LSPs) with extreme caution 
since these risk impacting traffic.

> 3) In the process of testing, we found cases where the update of a
> link's attributes (i.e. available capacity) was not being done by
> advertising an updated LSA using the same LSAid, but by flushing the old
> LSA followed by generation of a new LSA with a new LSAid. Since the
> LSAid for Opaque LSAs is not tied to the resource being advertised
> (i.e. the resource is identified using TLVs in the Opaque LSA, not using
> the LSAid as is done with IPv4 OSPF LSAs), this can cause a problem as
> it causes the order that the LSAs are processed to become important. We
> would appreciate CCAMP's thoughts on what the behavior should be.

The OSPF WG, is the proper WG to respond to this as they are the 
authoritative source on OSPF technology.  From our perspective, RFC 2328 
dictates the use of the same Link State ID when advertising a change in a 
link's information.  While it is certainly possible to advertise a change 
via issuing an LSA with a new Link State ID and flushing old state, from the 
perspective of OSPF this is not a change in link state, rather a completely 
new link.

> 4) Finally, in the process of testing, we found cases where established
> connections were deleted based on node restart procedures in RFC
> 3473. R163 of the OIF Carrier requirements (liaised to IETF in 12/2006)
> states deletion of established connections as the result of control
> plane failure (including node restart) shall not occur. It has been
> identified this could also occur when a number of cascaded nodes restart
> at the same time. We would appreciate CCAMP's thoughts on ways to
> prevent deletion of established connections from occurring when a node
> restarts.

 Without specific details, it's impossible to address the found cases or to 
identify if they were due to implementation or specification issues.

More broadly, RFC 3473 does not require the removal of forwarding state, 
even in the case of state synchronization errors, and implementations may 
take different action (such as reporting the condition to a management 
station). An implementation at a restarting node may consider that the lack 
of control plane state at its neighbor indicates that the removal of 
forwarding plane state has been attempted through the control plane while 
the restarting node was down and should follow local policy in determining 
how to react.

We would also like to direct you to RFC 5063 and 
draft-ietf-ccamp-gr-description which may provide additional relevant 
information.

We hope this addresses your questions.

Best regards,
Adrian Farrel and Deborah Brungard
IETF CCAMP working group co-chairs 

Delivery-date: Mon, 17 Dec 2007 13:44:10 +0000
Date: Mon, 17 Dec 2007 22:39:55 +0900
From: Tomohiro Otani <[email-masked]>
To: Diego Caviglia <[email-masked]>, Greg Bernstein <[email-masked]>
Cc: ccamp <[email-masked]>
Subject: Re: On Labels for Wavelength Switched Optical Networks...

Hi Greg and Diego,

Thank you for your initiation and clarification.

As Diego clearly pointed out, we actually rely on the data plane which=20
is especially
defined by ITU-T. All transmitters, MUX/DEMUXs, ROADMs and WSS's follow
the ITU-T frequency (wavelength) grid now. In that sense, it is=20
advantageous for us to
compliant with that specification in terms of the control plane.

Furthermore, taking advantage of this e-mail message, I would like to=20
clarify, again, the
label format definition. During the meeting, there seems to be an=20
misunderstanding about
the label definition. It has some bits to indicate a wavelength spacing,=20
but this info. is utilized
only to calculate the wavelength value for switching, not to control the=20
channel spacing of
the node itself.

Regards,

Tomo

Diego Caviglia =E3=81=95=E3=82=93=E3=81=AF=E6=9B=B8=E3=81=8D=E3=81=BE=E3=81=
=97=E3=81=9F:
>
> HI Greg,
>
> Thanks for this very useful summary.
>
> I=E2=80=99m one of the author of this ID so my comment is not fully neu=
tral J=20
> btw in IETF we always state that the data plane is not part of our=20
> work and in-fact we rely as much as possible on other standard bodies=20
> (IEEE, ITU-T, =E2=80=A6) for data plane definition.
>
> For G.709 and G.707 (SDH) we used as label what was defined in the=20
> ITU-T. As example the RFC4606 defines the SONET/SDH label as extension=20
> of the numbering scheme defined in G.707.
>
> My view is that we already have a standard body (ITU-T) that defined=20
> how to identify a wavelength and that definition fits well in our 32=20
> bits format so IMHO it is straightforward to use that definition.
>
> My two cents
>
>
> Diego
>
> -----------------------------------------------------------------------=
-
>
> *From:* [email-masked] [mailto:[email-masked]] *On=20
> Behalf Of *Greg Bernstein
> *Sent:* venerd=C3=AC 14 dicembre 2007 17.17
> *To:* ccamp
> *Subject:* On Labels for Wavelength Switched Optical Networks...
>
> Hi folks, at the Vancouver meeting the lambda label format of Otani,=20
> et. al. draft-otani-ccamp-gmpls-lambda-labels-01.txt=20
> <http://tools.ietf.org/html/draft-otani-ccamp-gmpls-lambda-labels-01.tx=
t>=20
> [Otani] was presented for a second time and a few new issues seemed to=20
> arise. I'm writing this note to see if we can resolve these on the=20
> list so this work can move forward, since the label format is=20
> valuable, in general, to the control of wavelength switched optical=20
> networks (WSON).
>
> First, a general 32 bit lambda label has been defined in RFC3471. This=20
> previous label does not directly relate to either the wavelength or=20
> frequency of the light used in a lambda LSP in a standardized way=20
> (folks can use the 32 bits as they see fit).
> To come up with a completely general "lambda label" one could/should=20
> define both a (i) wavelength label specified in meters and (ii) a=20
> frequency label specified in Hertz (Hz). These could be specified=20
> either with a 32 bit IEEE floating point number or via a suitable 32=20
> bit integer by suitably adjusting the base units. We could represent=20
> the frequency via a 32 bit integer in MHz, then a 193.1THz light=20
> source could be characterized by the integer 193,100,000. Similarly we=20
> could represent the wavelength label via a 32 bit integer in pico=20
> meters (10-12 meters), then a 1550nm wavelength could be characterized=20
> by the integer 1,550,000.
>
> Now any of the previous formats could be used with the 32 bit lambda=20
> label already defined. The problem here is to pick a format for=20
> interoperability and compatibility with potentially common wavelength=20
> switched control operations.
> Issues with the previously mentioned formats:
>
> (a) While floating point numbers provide great flexibility, as a label=20
> they have issues when it comes to comparison operations.
>
> (b) An integer format with a suitably scaled exponent is relatively=20
> simple and just leaves the choice of =E2=80=9Cexponent=E2=80=9D to be d=
ecided.
>
> (c) Neither format contains any =E2=80=9Ccontext=E2=80=9D information a=
bout the WDM=20
> system in general.
>
> The format proposed in [Otani]. avoids the above three issues and=20
> enhances common control plane operations as follows:
>
> (a) The format is integer based, hence avoids issues with floating=20
> point comparisons.
>
> (b) The format is based on the widely recognized ITU-T standard grids=20
> (ITU-T G.694.1 and .2) and fosters interoperability more than=20
> potentially any other choice.
>
> (c) The ITU-T grids come in various widths and hence have an inherent=20
> growth path.
>
> (d) The ITU-T grids come in both frequency (G.694.1) and wavelength=20
> (G.694.2) flavored versions an both are incorporated in the [Otani]=20
> label format.
>
> (e) The format includes information on the grid spacing which is=20
> important WDM context information useful in many label selection=20
> processes. For example a tunable laser associated with a 50GHz spacing=20
> WDM system could specify acceptable label range via the inclusive=20
> range label set mechanism. Note that only those frequencies (labels)=20
> that fall on the grid are supported and not intermediate frequencies.
>
>
> At the CCAMP WG meeting in Vancouver it was pointed out (by Lou=20
> Berger) that since a lambda label already exists and that existing=20
> implementations may make use of it that the proposed label of [Otani]=20
> would be better off referred to as a =E2=80=9CG.694 label=E2=80=9D. Wit=
h such a change=20
> I think that this label format (and accompanying draft) should move=20
> forward as a working group document.
>
> Comments, suggestions, issues?
>
> Regards
>
> Greg B.
>
> --=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
> Dr Greg Bernstein, Grotto Networking (510) 573-2237
> =20

Delivery-date: Mon, 17 Dec 2007 09:02:41 +0000
Content-class: urn:content-classes:message
Subject: RE: On Labels for Wavelength Switched Optical Networks...
Date: Mon, 17 Dec 2007 09:59:20 +0100
From: "Diego Caviglia" <[email-masked]>
To: "Greg Bernstein" <[email-masked]>, "ccamp" <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C8408B.1556104D
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

HI Greg,

            Thanks for this very useful summary.

=20

I'm one of the author of this ID so my comment is not fully neutral :-) =
btw in IETF we always state that the data plane is not part of our work =
and in-fact we rely as much as possible on other standard bodies (IEEE, =
ITU-T, ...) for data plane definition.

=20

For G.709 and G.707 (SDH) we used as label what was defined in the =
ITU-T.  As example the RFC4606 defines the SONET/SDH label as extension =
of the numbering scheme defined in G.707.

=20

My view is that we already have a standard body (ITU-T) that defined how =
to identify a wavelength and that definition fits well in our 32 bits =
format so IMHO it is straightforward to use that definition.

=20

My two cents

Diego

=20

________________________________

From: [email-masked] [mailto:[email-masked]] On =
Behalf Of Greg Bernstein
Sent: venerd=EC 14 dicembre 2007 17.17
To: ccamp
Subject: On Labels for Wavelength Switched Optical Networks...

=20

Hi folks, at the Vancouver meeting the lambda label format of Otani, et. =
al. draft-otani-ccamp-gmpls-lambda-labels-01.txt =
<http://tools.ietf.org/html/draft-otani-ccamp-gmpls-lambda-labels-01.txt>=
  [Otani] was presented for a second time and a few new issues seemed to =
arise. I'm writing this note to see if we can resolve these on the list =
so this work can move forward, since the label format is valuable, in =
general, to the control of wavelength switched optical networks (WSON).

First, a general 32 bit lambda label has been defined in RFC3471.  This =
previous label does not directly relate to either the wavelength or =
frequency of the light used in a lambda LSP in a standardized way (folks =
can use the 32 bits as they see fit).
To come up with a completely general "lambda label" one could/should =
define both a (i) wavelength label specified in meters and (ii) a =
frequency label specified in Hertz (Hz).  These could be specified =
either with a 32 bit IEEE floating point number or via a suitable 32 bit =
integer by suitably adjusting the base units.  We could represent the =
frequency via a 32 bit integer in MHz, then a 193.1THz light source =
could be characterized by the integer 193,100,000. Similarly we could =
represent the wavelength label via a 32 bit integer in pico meters =
(10-12 meters), then a 1550nm wavelength could be characterized by the =
integer 1,550,000.

 Now any of the previous formats could be used with the 32 bit lambda =
label already defined.  The problem here is to pick a format for =
interoperability and compatibility with potentially common wavelength =
switched control operations.
Issues with the previously mentioned formats:

(a)    While floating point numbers provide great flexibility, as a =
label they have issues when it comes to comparison operations. =20

(b)   An integer format with a suitably scaled exponent is relatively =
simple and just leaves the choice of "exponent" to be decided.

(c)    Neither format contains any "context" information about the WDM =
system in general.

The format proposed in [Otani]. avoids the above three issues and =
enhances common control plane operations as follows:

(a)    The format is integer based, hence avoids issues with floating =
point comparisons.

(b)   The format is based on the widely recognized ITU-T standard grids =
(ITU-T G.694.1 and .2) and fosters interoperability more than =
potentially any other choice.=20

(c)    The ITU-T grids come in various widths and hence have an inherent =
growth path.

(d)   The ITU-T grids come in both frequency (G.694.1) and wavelength =
(G.694.2) flavored versions an both are incorporated in the [Otani] =
label format.

(e)    The format includes information on the grid spacing which is =
important WDM context information useful in many label selection =
processes.  For example a tunable laser associated with a 50GHz spacing =
WDM system could specify acceptable label range via the inclusive range =
label set mechanism.  Note that only those frequencies (labels) that =
fall on the grid are supported and not intermediate frequencies.

=20
At the CCAMP WG meeting in Vancouver it was pointed out (by Lou Berger) =
that since a lambda label already exists and that existing =
implementations may make use of it that the proposed label of [Otani] =
would be better off referred to as a "G.694 label". With such a change I =
think that this label format (and accompanying draft) should move =
forward as a working group document.

Comments, suggestions, issues?

Regards

Greg B.

--=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
Dr Greg Bernstein, Grotto Networking (510) 573-2237
=20

------_=_NextPart_001_01C8408B.1556104D
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

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

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<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"place"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"City"/>
<!--[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:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";
	color:black;}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:blue;
	text-decoration:underline;}
p
	{mso-margin-top-alt:auto;
	margin-right:0cm;
	mso-margin-bottom-alt:auto;
	margin-left:0cm;
	font-size:12.0pt;
	font-family:"Times New Roman";
	color:black;}
pre
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";
	color:black;}
span.EmailStyle19
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
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 bgcolor=3Dwhite 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 =
Greg,<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'>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
Thanks for this very useful
summary.<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&#8217;m one of the author of this =
ID so
my comment is not fully neutral </span></font><font size=3D2 =
color=3Dnavy
face=3DWingdings><span =
style=3D'font-size:10.0pt;font-family:Wingdings;color:navy'>J</span></fon=
t><font
size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:navy'> btw in IETF we always state that the data plane is not part =
of our
work and in-fact we rely as much as possible on other standard bodies =
(IEEE,
ITU-T, &#8230;) for data plane definition.<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'>For G.709 and G.707 (SDH) we used =
as label
what was defined in the ITU-T.=A0 As example the RFC4606 defines the =
SONET/SDH
label as extension of the numbering scheme defined in =
G.707.<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'>My view is that we already have a =
standard
body (ITU-T) that defined how to identify a wavelength and that =
definition fits
well in our 32 bits format so IMHO it is straightforward to use that
definition.<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'>My two =
cents<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'><br>
Diego<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 style=3D'border:none;border-left:solid blue 1.5pt;padding:0cm 0cm =
0cm 4.0pt'>

<div>

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

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

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

<p class=3DMsoNormal><b><font size=3D2 color=3Dblack face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma;color:windowtext;font-weight=
:bold'>From:</span></font></b><font
size=3D2 color=3Dblack face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma;
color:windowtext'> [email-masked] =
[mailto:[email-masked]] <b><span
style=3D'font-weight:bold'>On Behalf Of </span></b>Greg Bernstein<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> venerd=EC 14 =
dicembre 2007
17.17<br>
<b><span style=3D'font-weight:bold'>To:</span></b> ccamp<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> On Labels for =
Wavelength
Switched Optical Networks...</span></font><font color=3Dblack><span
style=3D'color:windowtext'><o:p></o:p></span></font></p>

</div>

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

<p><font size=3D3 color=3Dblack face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt'>Hi
folks, at the <st1:City w:st=3D"on"><st1:place =
w:st=3D"on">Vancouver</st1:place></st1:City>
meeting the lambda label format of Otani, et. al.<a
href=3D"http://tools.ietf.org/html/draft-otani-ccamp-gmpls-lambda-labels-=
01.txt">
draft-otani-ccamp-gmpls-lambda-labels-01.txt</a> [Otani] was presented =
for a
second time and a few new issues seemed to arise. I'm writing this note =
to see
if we can resolve these on the list so this work can move forward, since =
the
label format is valuable, in general, to the control of wavelength =
switched
optical networks (WSON).<o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3D3 color=3Dblack face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt'>First,
a general 32 bit lambda label has been defined in RFC3471.&nbsp; This =
previous
label does not directly relate to either the wavelength or frequency of =
the
light used in a lambda LSP in a standardized way (folks can use the 32 =
bits as
they see fit).<br>
To come up with a completely general &quot;lambda label&quot; one =
could/should
define both a (i) wavelength label specified in meters and (ii) a =
frequency
label specified in Hertz (Hz).&nbsp; These could be specified either =
with a 32
bit IEEE floating point number or via a suitable 32 bit integer by =
suitably
adjusting the base units.&nbsp; We could represent the frequency via a =
32 bit
integer in MHz, then a 193.1THz light source could be characterized by =
the
integer 193,100,000. Similarly we could represent the wavelength label =
via a 32
bit integer in pico meters (10-12 meters), then a 1550nm wavelength =
could be
characterized by the integer 1,550,000.<o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><u1:p><font
size=3D3 color=3Dblack face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt'>&nbsp;</u1:p>Now
any of the previous formats could be used with the 32 bit lambda label =
already
defined.&nbsp; The problem here is to pick a format for interoperability =
and
compatibility with potentially common wavelength switched control =
operations.<br>
<u1:p></u1:p>Issues with the previously mentioned =
formats:<o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
margin-left:36.0pt;text-indent:-18.0pt'><font size=3D3 color=3Dblack
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>(a)<span
style=3D'font-size-adjust: none;font-stretch: =
normal'></span></font><font size=3D1><span
style=3D'font-size:7.0pt'>&nbsp;&nbsp;&nbsp; </span></span></font>While =
floating
point numbers provide great flexibility, as a label they have issues =
when it
comes to comparison operations.&nbsp; <o:p></o:p></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
margin-left:36.0pt;text-indent:-18.0pt'><font size=3D3 color=3Dblack
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>(b)<span
style=3D'font-size-adjust: none;font-stretch: =
normal'></span></font><font size=3D1><span
style=3D'font-size:7.0pt'>&nbsp;&nbsp; </span></span></font>An integer =
format
with a suitably scaled exponent is relatively simple and just leaves the =
choice
of &#8220;exponent&#8221; to be decided.<o:p></o:p></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
margin-left:36.0pt;text-indent:-18.0pt'><font size=3D3 color=3Dblack
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>(c)<span
style=3D'font-size-adjust: none;font-stretch: =
normal'></span></font><font size=3D1><span
style=3D'font-size:7.0pt'>&nbsp;&nbsp;&nbsp; =
</span></span></font>Neither format
contains any &#8220;context&#8221; information about the WDM system in =
general.<o:p></o:p></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3D3 color=3Dblack face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt'>The
format proposed in [Otani]. avoids the above three issues and enhances =
common
control plane operations as follows:<o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
margin-left:36.0pt;text-indent:-18.0pt'><font size=3D3 color=3Dblack
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>(a)<span
style=3D'font-size-adjust: none;font-stretch: =
normal'></span></font><font size=3D1><span
style=3D'font-size:7.0pt'>&nbsp;&nbsp;&nbsp; </span></span></font>The =
format is
integer based, hence avoids issues with floating point =
comparisons.<o:p></o:p></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
margin-left:36.0pt;text-indent:-18.0pt'><font size=3D3 color=3Dblack
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>(b)<span
style=3D'font-size-adjust: none;font-stretch: =
normal'></span></font><font size=3D1><span
style=3D'font-size:7.0pt'>&nbsp;&nbsp; </span></span></font>The format =
is based
on the widely recognized ITU-T standard grids (ITU-T G.694.1 and .2) and
fosters interoperability more than potentially any other =
choice.&nbsp;<o:p></o:p></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
margin-left:36.0pt;text-indent:-18.0pt'><font size=3D3 color=3Dblack
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>(c)<span
style=3D'font-size-adjust: none;font-stretch: =
normal'></span></font><font size=3D1><span
style=3D'font-size:7.0pt'>&nbsp;&nbsp;&nbsp; </span></span></font>The =
ITU-T grids
come in various widths and hence have an inherent growth =
path.<o:p></o:p></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
margin-left:36.0pt;text-indent:-18.0pt'><font size=3D3 color=3Dblack
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>(d)<span
style=3D'font-size-adjust: none;font-stretch: =
normal'></span></font><font size=3D1><span
style=3D'font-size:7.0pt'>&nbsp;&nbsp; </span></span></font>The ITU-T =
grids come
in both frequency (G.694.1) and wavelength (G.694.2) flavored versions =
an both
are incorporated in the [Otani] label format.<o:p></o:p></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
margin-left:36.0pt;text-indent:-18.0pt'><font size=3D3 color=3Dblack
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>(e)<span
style=3D'font-size-adjust: none;font-stretch: =
normal'></span></font><font size=3D1><span
style=3D'font-size:7.0pt'>&nbsp;&nbsp;&nbsp; </span></span></font>The =
format
includes information on the grid spacing which is important WDM context
information useful in many label selection processes.&nbsp; For example =
a
tunable laser associated with a 50GHz spacing WDM system could specify
acceptable label range via the inclusive range label set =
mechanism.&nbsp; Note
that only those frequencies (labels) that fall on the grid are supported =
and
not intermediate frequencies.<o:p></o:p></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><u1:p><font
size=3D3 color=3Dblack face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt'>&nbsp;<br>
</u1:p>At the CCAMP WG meeting in Vancouver it was pointed out (by Lou =
Berger)
that since a lambda label already exists and that existing =
implementations may
make use of it that the proposed label of [Otani] would be better off =
referred
to as a &#8220;G.694 label&#8221;. With such a change I think that this =
label
format (and accompanying draft) should move forward as a working group
document.<o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3D3 color=3Dblack face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt'>Comments,
suggestions, issues?<o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3D3 color=3Dblack face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt'>Regards<o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3D3 color=3Dblack face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt'>Greg
B.<o:p></o:p></span></font></p>

<pre cols=3D72><font size=3D2 color=3Dblack face=3D"Courier New"><span
style=3D'font-size:10.0pt'>-- <o:p></o:p></span></font></pre><pre><font =
size=3D2
color=3Dblack 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<o:p></o:p></span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>Dr Greg Bernstein, Grotto Networking (510) =
573-2237<o:p></o:p></span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></pre></div>

</div>

</body>

</html>

------_=_NextPart_001_01C8408B.1556104D--

Delivery-date: Mon, 17 Dec 2007 02:52:54 +0000
Date: Mon, 17 Dec 2007 10:49:15 +0800
From: Dan Li <[email-masked]>
Subject: Re: On Labels for Wavelength Switched Optical Networks...
To: Greg Bernstein <[email-masked]>, ccamp <[email-masked]>

This is a multi-part message in MIME format.

--Boundary_(ID_Ad810cjgjsTDLe8cI94HZA)
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT

Hi Greg,

For the last part of your email, do you mean we need a field in the 32bit label to indicate this is a G.694 label?

Thanks,

Dan

  ----- Original Message ----- 
  From: Greg Bernstein 
  To: ccamp 
  Sent: Saturday, December 15, 2007 12:16 AM
  Subject: On Labels for Wavelength Switched Optical Networks...

  Hi folks, at the Vancouver meeting the lambda label format of Otani, et. al. draft-otani-ccamp-gmpls-lambda-labels-01.txt [Otani] was presented for a second time and a few new issues seemed to arise. I'm writing this note to see if we can resolve these on the list so this work can move forward, since the label format is valuable, in general, to the control of wavelength switched optical networks (WSON).

  First, a general 32 bit lambda label has been defined in RFC3471.  This previous label does not directly relate to either the wavelength or frequency of the light used in a lambda LSP in a standardized way (folks can use the 32 bits as they see fit).
  To come up with a completely general "lambda label" one could/should define both a (i) wavelength label specified in meters and (ii) a frequency label specified in Hertz (Hz).  These could be specified either with a 32 bit IEEE floating point number or via a suitable 32 bit integer by suitably adjusting the base units.  We could represent the frequency via a 32 bit integer in MHz, then a 193.1THz light source could be characterized by the integer 193,100,000. Similarly we could represent the wavelength label via a 32 bit integer in pico meters (10-12 meters), then a 1550nm wavelength could be characterized by the integer 1,550,000.

   Now any of the previous formats could be used with the 32 bit lambda label already defined.  The problem here is to pick a format for interoperability and compatibility with potentially common wavelength switched control operations.
  Issues with the previously mentioned formats:

  <!--[if !supportLists]-->(a)    <!--[endif]-->While floating point numbers provide great flexibility, as a label they have issues when it comes to comparison operations.  

  <!--[if !supportLists]-->(b)   <!--[endif]-->An integer format with a suitably scaled exponent is relatively simple and just leaves the choice of "exponent" to be decided.

  <!--[if !supportLists]-->(c)    <!--[endif]-->Neither format contains any "context" information about the WDM system in general.

  The format proposed in [Otani]. avoids the above three issues and enhances common control plane operations as follows:

  <!--[if !supportLists]-->(a)    <!--[endif]-->The format is integer based, hence avoids issues with floating point comparisons.

  <!--[if !supportLists]-->(b)   <!--[endif]-->The format is based on the widely recognized ITU-T standard grids (ITU-T G.694.1 and .2) and fosters interoperability more than potentially any other choice. 

  <!--[if !supportLists]-->(c)    <!--[endif]-->The ITU-T grids come in various widths and hence have an inherent growth path.

  <!--[if !supportLists]-->(d)   <!--[endif]-->The ITU-T grids come in both frequency (G.694.1) and wavelength (G.694.2) flavored versions an both are incorporated in the [Otani] label format.

  <!--[if !supportLists]-->(e)    <!--[endif]-->The format includes information on the grid spacing which is important WDM context information useful in many label selection processes.  For example a tunable laser associated with a 50GHz spacing WDM system could specify acceptable label range via the inclusive range label set mechanism.  Note that only those frequencies (labels) that fall on the grid are supported and not intermediate frequencies.

  At the CCAMP WG meeting in Vancouver it was pointed out (by Lou Berger) that since a lambda label already exists and that existing implementations may make use of it that the proposed label of [Otani] would be better off referred to as a "G.694 label". With such a change I think that this label format (and accompanying draft) should move forward as a working group document.

  Comments, suggestions, issues?

  Regards

  Greg B.

-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237

--Boundary_(ID_Ad810cjgjsTDLe8cI94HZA)
Content-type: text/html; charset=iso-8859-1
Content-transfer-encoding: base64

--Boundary_(ID_Ad810cjgjsTDLe8cI94HZA)--

Delivery-date: Fri, 14 Dec 2007 19:12:23 +0000
Date: Fri, 14 Dec 2007 17:07:50 +0100
From: Huub van Helvoort <[email-masked]>
To: Aaron Daubman <[email-masked]>
CC: [email-masked]
Subject: Re: Question on draft-ietf-ccamp-gmpls-vcat-lcas and VCG Member Sharing

Hello Aaron,

See my replies in-line [hvh]:

> I have been looking over draft-ietf-ccamp-gmpls-vcat-lcas-03, as well
> as G.707 and G.7042, and have not been able to reconcile how the
> member sharing functionality would be accomplished.
> 
> Am I understanding this feature correctly:
> - A member that was not previously part of a VCG may be hitlessly added to a VCG

[hvh] an LSP only becomes member of a VCG if it is assigned to that
particalar VCG by the management system (usinf ASON/GMPLS).
When assigned it will have the IDLE state.

> - A member of another VCG (presumably IDLE) may be removed from that
> VCG and added to another as demand dictates

[hvh] actually this will involve two steps:
- remove (= unassign) the member from one VGG by mamnagement
- add (= assign) the member to (another) VCG by management
You are right in assuming that only IDLE members should be
removed, although the LCAS protocol is robust enough to
withstand removal of NORM/EOS?DNU members.

> - There could be a pool of provisioned but IDLE members of some
> 'shared' VCG that can be added to or removed from others as necessary

[hvh] right, if you mean that the path is provisioned

> If the above is (basically) correct, what functionality would carry this out?

[hvh] the management sytem, note that this has to be perfromed at both
ends (source AND sink) of the VCG. Note also that the (un-)asignment is
NOT supported by the LCAS protocol.

> I assume that one would have to modify the GID of such members on the
> fly... and LCAS doesn't seem to currently maintain this functionality.

[hvh] No, as soon as an LSP bcomes a member of a VCG the GID will be
inserted automatically by the termination function, it does not have
to be provisioned. Added members will always have the IDLE state.

> Would this be left up to the implementation of the NMS if it supports
> GMPLS, or are (portions) of these features being added to LCAS?

[hvh] as mentioned above (un-)assignemnt is initiated by mangement
the LCAS procedure does the hitless delete/add of a member (payload).

> In particular, I am wondering what signaling in G.7042 would allow the
> addition of a new member to an existing VCG as stated below:
> """
>    Following the addition of the new label to the LSP, LCAS may be used
>    in-band to add the new label into the existing VCAT group.  LCAS
>    signaling for this function is described in [ITU-T-G.7042].
> """

[hvh] this is the last step, the LCAS function takes care of the hitless
addition by synchronising source and sink.

> As far as I have been able to tell, LCAS currently can only modify
> pre-existing members of a VCG.  I have not been able to identify any
> functionality which would allow a new member to be added to a VCG - am
> I missing something?

[hvh] the assigning of an LSP to a VCG is management reponsability
it will then become member of that VCG. The addition/removal of a
member for active participation in the VCG is initiated by management
and finished by the LCAS protocol.

> Perhaps I am misunderstand LCAS' ADD functionality.  It is my
> understanding that an LCAS ADD does not actually add a new member to a
> VCG, but merely sets an IDLE member of a VCG to become active in the
> VCG (e.g. NORM/EOS). Regardless of whether a VCG member is IDLE or
> in-use, it will share the same GID as all other members of the VCG.

[hvh] your understanding is right.

> Any clarification would be much appreciated.

I hope I did, if you need more clarification you can find it
on the site below.

Cheers, Huub.

-- 
================================================================
                   http://www.van-helvoort.eu/
================================================================
Always remember that you are unique...just like everyone else...

Delivery-date: Fri, 14 Dec 2007 17:06:46 +0000
Content-class: urn:content-classes:message
Subject: RE: Question on draft-ietf-ccamp-gmpls-vcat-lcas and VCG Member Sharing
Date: Fri, 14 Dec 2007 17:05:47 -0000
From: "Trevor Wilson" <[email-masked]>
To: "Aaron Daubman" <[email-masked]>, <[email-masked]>

 Aaron,

Please see my responses in-line below; annotated by [TW on/TW off]

Regards,

Trevor

Trevor Wilson
Nortel Networks (UK)
Tel:    +44 2890 363701
ESN:  751 3701
E-mail:   [email-masked]

Confidentiality Notice: This message and any attachments may contain
information that is privileged and confidential. If you have reason to
believe that you are not the intended recipient or a person responsible
for delivering this message to an intended recipient, you are hereby
notified that any review, dissemination, distribution, or copying of
this message is strictly prohibited. If you have reason to believe that
you are not the intended recipient or a person responsible for
delivering this message to an intended recipient, please contact the
sender immediately by reply email and destroy all copies of the original
message.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Aaron Daubman
Sent: 14 December 2007 15:34
To: [email-masked]
Subject: Question on draft-ietf-ccamp-gmpls-vcat-lcas and VCG Member
Sharing

Greetings,

Apologies in advance if it is inappropriate to pose such questions
here...

I have been looking over draft-ietf-ccamp-gmpls-vcat-lcas-03, as well as
G.707 and G.7042, and have not been able to reconcile how the member
sharing functionality would be accomplished.

Am I understanding this feature correctly:
- A member that was not previously part of a VCG may be hitlessly added
to a VCG
[TW on]
Correct
[TW off]
- A member of another VCG (presumably IDLE) may be removed from that VCG
and added to another as demand dictates
[TW on]
Correct
[TW off]
- There could be a pool of provisioned but IDLE members of some 'shared'
VCG that can be added to or removed from others as necessary
[TW on]
Hmmm....
A VCG member, even in the IDLE state is still a member of ONE VCG. It
can of course be removed from that VCG and provisioned into another VCG.
This is outside the scope of the LCAS Recommendation G.7042.This
movement from one VCG to another VCG is a management action and does not
require the use of the LCAS protocol.
[TW off]

If the above is (basically) correct, what functionality would carry this
out?

I assume that one would have to modify the GID of such members on the
fly... and LCAS doesn't seem to currently maintain this functionality.
[TW on]
All members of a VCG will have the same GID. If a member belongs to
another VCG it will have a different GID. Only active VCG member's GIDs
will be used at the source.
[TW off]

Would this be left up to the implementation of the NMS if it supports
GMPLS, or are (portions) of these features being added to LCAS?
[TW on]
Allocation of a member to a VCG is a management function and not part pf
the LCAS protocol.
[TW off]

In particular, I am wondering what signaling in G.7042 would allow the
addition of a new member to an existing VCG as stated below:
"""
   Following the addition of the new label to the LSP, LCAS may be used
   in-band to add the new label into the existing VCAT group.  LCAS
   signaling for this function is described in [ITU-T-G.7042].
"""
[TW on]
After a member is provisioned to the VCG it will be in the IDLE state;
thereafter it can be ADDed to the VCG active group by the ADD command.
[TW on]

As far as I have been able to tell, LCAS currently can only modify
pre-existing members of a VCG.  I have not been able to identify any
functionality which would allow a new member to be added to a VCG - am I
missing something?
[TW on]
No. You haven't missed anything. As stated previously in my reply:
inclusion of a member into a VCG is a management function initially put
into the IDLE state and thereafter ADDed to the active VCG by the ADD
command.
[TW off]

Perhaps I am misunderstand LCAS' ADD functionality.  It is my
understanding that an LCAS ADD does not actually add a new member to a
VCG, but merely sets an IDLE member of a VCG to become active in the VCG
(e.g. NORM/EOS). Regardless of whether a VCG member is IDLE or in-use,
it will share the same GID as all other members of the VCG.
[TW on]
Correct]
TW off]

Any clarification would be much appreciated.

Thank you,
     Aaron

Delivery-date: Fri, 14 Dec 2007 16:39:31 +0000
Date: Fri, 14 Dec 2007 08:38:19 -0800
From: Greg Bernstein <[email-masked]>
To: Aaron Daubman <[email-masked]>
CC: [email-masked]
Subject: Re: Question on draft-ietf-ccamp-gmpls-vcat-lcas and VCG Member Sharing

Hi Aaron, see comments below.

Aaron Daubman wrote:
> Greetings,
>
> Apologies in advance if it is inappropriate to pose such questions here...
>
> I have been looking over draft-ietf-ccamp-gmpls-vcat-lcas-03, as well
> as G.707 and G.7042, and have not been able to reconcile how the
> member sharing functionality would be accomplished.
>
> Am I understanding this feature correctly:
> - A member that was not previously part of a VCG may be hitlessly added to a VCG
>   
Yes.
> - A member of another VCG (presumably IDLE) may be removed from that
> VCG and added to another as demand dictates
>   
Yes.
> - There could be a pool of provisioned but IDLE members of some
> 'shared' VCG that can be added to or removed from others as necessary
>   
No. The pool is of server layer connections between the same 
"endpoints", that could be put into one VCG or another.
> If the above is (basically) correct, what functionality would carry this out?
>
> I assume that one would have to modify the GID of such members on the
> fly... and LCAS doesn't seem to currently maintain this functionality.
>   
--> GID == Group IDentification, a pseudo random bit sequence that is 
used to identify one LCAS VCAT group from another and transmitted in the 
LCAS control packet from source to sink. This "control packet" is sent 
in overhead bytes/bits that accompany the server layer signal. It is the 
source LCAS entities responsibility to set this information not GMPLS 
signaling. After successfully establishing the lower layer connection 
via GMPLS, the internal LCAS entity at the source should be notified so 
that it can set its value. How this would be done is out of scope of the 
draft and an internal matter.
> Would this be left up to the implementation of the NMS if it supports
> GMPLS, or are (portions) of these features being added to LCAS?
>   
--> Either the NMS(?) software or control plane software supporting 
GMPLS would need to talk to the LCAS entity.
> In particular, I am wondering what signaling in G.7042 would allow the
> addition of a new member to an existing VCG as stated below:
> """
>    Following the addition of the new label to the LSP, LCAS may be used
>    in-band to add the new label into the existing VCAT group.  LCAS
>    signaling for this function is described in [ITU-T-G.7042].
> """
>
> As far as I have been able to tell, LCAS currently can only modify
> pre-existing members of a VCG.  I have not been able to identify any
> functionality which would allow a new member to be added to a VCG - am
> I missing something?
>   
--> GMPLS can set up connections. LCAS is used to add them to a group.
> Perhaps I am misunderstand LCAS' ADD functionality.  It is my
> understanding that an LCAS ADD does not actually add a new member to a
> VCG, but merely sets an IDLE member of a VCG to become active in the
> VCG (e.g. NORM/EOS). Regardless of whether a VCG member is IDLE or
> in-use, it will share the same GID as all other members of the VCG.
>   
--> Yes. A bit of a misunderstanding.  As you say you'd first need the 
LCAS entity to set the GID (so we know this connection should be part of 
the group) and when that's successful we should be in the IDLE state and 
from their we can issue the ADD message. The key is that LCAS can't set 
up a new connection only put an existing connection into use (we use 
GMPLS to set up the connection).
> Any clarification would be much appreciated.
>   
Hope this helps.
Greg B.
> Thank you,
>      Aaron

-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237

Delivery-date: Fri, 14 Dec 2007 16:18:46 +0000
Date: Fri, 14 Dec 2007 08:16:53 -0800
From: Greg Bernstein <[email-masked]>
To: ccamp <[email-masked]>
Subject: On Labels for Wavelength Switched Optical Networks...

This is a multi-part message in MIME format.
--------------040908000103070203060209
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi folks, at the Vancouver meeting the lambda label format of Otani, et. 
al. draft-otani-ccamp-gmpls-lambda-labels-01.txt 
<http://tools.ietf.org/html/draft-otani-ccamp-gmpls-lambda-labels-01.txt> 
[Otani] was presented for a second time and a few new issues seemed to 
arise. I'm writing this note to see if we can resolve these on the list 
so this work can move forward, since the label format is valuable, in 
general, to the control of wavelength switched optical networks (WSON).

First, a general 32 bit lambda label has been defined in RFC3471.  This 
previous label does not directly relate to either the wavelength or 
frequency of the light used in a lambda LSP in a standardized way (folks 
can use the 32 bits as they see fit).
To come up with a completely general "lambda label" one could/should 
define both a (i) wavelength label specified in meters and (ii) a 
frequency label specified in Hertz (Hz).  These could be specified 
either with a 32 bit IEEE floating point number or via a suitable 32 bit 
integer by suitably adjusting the base units.  We could represent the 
frequency via a 32 bit integer in MHz, then a 193.1THz light source 
could be characterized by the integer 193,100,000. Similarly we could 
represent the wavelength label via a 32 bit integer in pico meters 
(10-12 meters), then a 1550nm wavelength could be characterized by the 
integer 1,550,000.

 Now any of the previous formats could be used with the 32 bit lambda 
label already defined.  The problem here is to pick a format for 
interoperability and compatibility with potentially common wavelength 
switched control operations.
Issues with the previously mentioned formats:

(a)    While floating point numbers provide great flexibility, as a 
label they have issues when it comes to comparison operations. 

(b)   An integer format with a suitably scaled exponent is relatively 
simple and just leaves the choice of "exponent" to be decided.

(c)    Neither format contains any "context" information about the WDM 
system in general.

The format proposed in [Otani]. avoids the above three issues and 
enhances common control plane operations as follows:

(a)    The format is integer based, hence avoids issues with floating 
point comparisons.

(b)   The format is based on the widely recognized ITU-T standard grids 
(ITU-T G.694.1 and .2) and fosters interoperability more than 
potentially any other choice. 

(c)    The ITU-T grids come in various widths and hence have an inherent 
growth path.

(d)   The ITU-T grids come in both frequency (G.694.1) and wavelength 
(G.694.2) flavored versions an both are incorporated in the [Otani] 
label format.

(e)    The format includes information on the grid spacing which is 
important WDM context information useful in many label selection 
processes.  For example a tunable laser associated with a 50GHz spacing 
WDM system could specify acceptable label range via the inclusive range 
label set mechanism.  Note that only those frequencies (labels) that 
fall on the grid are supported and not intermediate frequencies.

At the CCAMP WG meeting in Vancouver it was pointed out (by Lou Berger) 
that since a lambda label already exists and that existing 
implementations may make use of it that the proposed label of [Otani] 
would be better off referred to as a "G.694 label". With such a change I 
think that this label format (and accompanying draft) should move 
forward as a working group document.

Comments, suggestions, issues?

Regards

Greg B.

-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237

--------------040908000103070203060209
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
</head>
<body bgcolor="#ffffff" text="#000000">
<p>Hi folks, at the Vancouver meeting the lambda label format of Otani,
et. al.<a
 href="http://tools.ietf.org/html/draft-otani-ccamp-gmpls-lambda-labels-01.txt">
draft-otani-ccamp-gmpls-lambda-labels-01.txt</a> [Otani] was presented
for a second time and a few new issues seemed to arise. I'm writing
this note to see if we can resolve these on the list so this work can
move forward, since the label format is valuable, in general, to the
control of wavelength switched optical networks (WSON).<br>
</p>
<p class="MsoNormal">First, a general 32 bit lambda label has been
defined in RFC3471.<span style="">&nbsp; </span>This previous label does
not directly relate
to either the wavelength or frequency of the light used in a lambda LSP
in a standardized way (folks can use the 32 bits as they see fit).<br>
To come up with a completely general "lambda label" one could/should
define both a (i)
wavelength label specified in meters and (ii) a frequency label
specified in
Hertz (Hz).<span style="">&nbsp; </span>These could be specified
either with a 32 bit IEEE floating point number or via a suitable 32
bit
integer by suitably adjusting the base units.<span style="">&nbsp;
</span>We could represent the frequency via a 32 bit integer in MHz,
then a
193.1THz light source could be characterized by the integer
193,100,000.
Similarly we could represent the wavelength label via a 32 bit integer
in pico
meters (10-12 meters), then a 1550nm wavelength could be characterized
by the
integer 1,550,000.</p>
<p class="MsoNormal"><o:p>&nbsp;</o:p>Now any of the previous formats could
be used with the 32
bit lambda label already defined.<span style="">&nbsp; </span>The
problem here is to pick a format for interoperability and compatibility
with
potentially common wavelength switched control operations.<br>
<o:p></o:p>Issues with the previously mentioned formats:</p>
<p class="MsoNormal" style="margin-left: 0.5in; text-indent: -0.25in;"><!--[if !supportLists]--><span
 style="">(a)<span
 style="font-family: &quot;Times New Roman&quot;; font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-size-adjust: none; font-stretch: normal;">&nbsp;&nbsp;&nbsp;
</span></span><!--[endif]-->While
floating point numbers provide great flexibility, as a label they have
issues
when it comes to comparison operations.<span style="">&nbsp; </span></p>
<p class="MsoNormal" style="margin-left: 0.5in; text-indent: -0.25in;"><!--[if !supportLists]--><span
 style="">(b)<span
 style="font-family: &quot;Times New Roman&quot;; font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-size-adjust: none; font-stretch: normal;">&nbsp;&nbsp;
</span></span><!--[endif]-->An
integer format with a suitably scaled exponent is relatively simple and
just
leaves the choice of &#8220;exponent&#8221; to be decided.</p>
<p class="MsoNormal" style="margin-left: 0.5in; text-indent: -0.25in;"><!--[if !supportLists]--><span
 style="">(c)<span
 style="font-family: &quot;Times New Roman&quot;; font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-size-adjust: none; font-stretch: normal;">&nbsp;&nbsp;&nbsp;
</span></span><!--[endif]-->Neither
format contains any &#8220;context&#8221; information about the WDM system in
general.</p>
<p class="MsoNormal">The format proposed in [Otani]. avoids the above
three
issues and enhances common control plane operations as follows:</p>
<p class="MsoNormal" style="margin-left: 0.5in; text-indent: -0.25in;"><!--[if !supportLists]--><span
 style="">(a)<span
 style="font-family: &quot;Times New Roman&quot;; font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-size-adjust: none; font-stretch: normal;">&nbsp;&nbsp;&nbsp;
</span></span><!--[endif]-->The
format is integer based, hence avoids issues with floating point
comparisons.</p>
<p class="MsoNormal" style="margin-left: 0.5in; text-indent: -0.25in;"><!--[if !supportLists]--><span
 style="">(b)<span
 style="font-family: &quot;Times New Roman&quot;; font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-size-adjust: none; font-stretch: normal;">&nbsp;&nbsp;
</span></span><!--[endif]-->The
format is based on the widely recognized ITU-T standard grids (ITU-T
G.694.1 and .2) and
fosters interoperability more than potentially any other choice.&nbsp;<span
 style=""></span></p>
<p class="MsoNormal" style="margin-left: 0.5in; text-indent: -0.25in;"><!--[if !supportLists]--><span
 style="">(c)<span
 style="font-family: &quot;Times New Roman&quot;; font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-size-adjust: none; font-stretch: normal;">&nbsp;&nbsp;&nbsp;
</span></span><!--[endif]-->The
ITU-T grids come in various widths and hence have an inherent growth
path.</p>
<p class="MsoNormal" style="margin-left: 0.5in; text-indent: -0.25in;"><!--[if !supportLists]--><span
 style="">(d)<span
 style="font-family: &quot;Times New Roman&quot;; font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-size-adjust: none; font-stretch: normal;">&nbsp;&nbsp;
</span></span><!--[endif]-->The
ITU-T grids come in both frequency (G.694.1) and wavelength (G.694.2)
flavored
versions an both are incorporated in the [Otani] label format.</p>
<p class="MsoNormal" style="margin-left: 0.5in; text-indent: -0.25in;"><!--[if !supportLists]--><span
 style="">(e)<span
 style="font-family: &quot;Times New Roman&quot;; font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-size-adjust: none; font-stretch: normal;">&nbsp;&nbsp;&nbsp;
</span></span><!--[endif]-->The
format includes information on the grid spacing which is important WDM
context
information useful in many label selection processes.<span style="">&nbsp; </span>For
example a tunable laser associated with a
50GHz spacing WDM system could specify acceptable label range via the
inclusive
range label set mechanism.<span style="">&nbsp; </span>Note that
only those frequencies (labels) that fall on the grid are supported and
not
intermediate frequencies.</p>
<p class="MsoNormal"><o:p>&nbsp;</o:p><br>
At the CCAMP WG meeting in Vancouver it was pointed out (by Lou Berger)
that
since a lambda label already exists and that existing implementations
may make
use of it that the proposed label of [Otani] would be better off
referred to as a
&#8220;G.694 label&#8221;. With such a change I think that this label format (and
accompanying draft) should move forward as a working group document.<br>
</p>
<p class="MsoNormal">Comments, suggestions, issues?<br>
</p>
<p class="MsoNormal">Regards<br>
</p>
<p class="MsoNormal">Greg B.<br>
</p>
<pre class="moz-signature" cols="72">-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237

</pre>
</body>
</html>

--------------040908000103070203060209--

Delivery-date: Fri, 14 Dec 2007 15:36:15 +0000
Date: Fri, 14 Dec 2007 10:33:30 -0500
From: "Aaron Daubman" <[email-masked]>
To: [email-masked]
Subject: Question on draft-ietf-ccamp-gmpls-vcat-lcas and VCG Member Sharing

Greetings,

Apologies in advance if it is inappropriate to pose such questions here...

I have been looking over draft-ietf-ccamp-gmpls-vcat-lcas-03, as well
as G.707 and G.7042, and have not been able to reconcile how the
member sharing functionality would be accomplished.

Am I understanding this feature correctly:
- A member that was not previously part of a VCG may be hitlessly added to a VCG
- A member of another VCG (presumably IDLE) may be removed from that
VCG and added to another as demand dictates
- There could be a pool of provisioned but IDLE members of some
'shared' VCG that can be added to or removed from others as necessary

If the above is (basically) correct, what functionality would carry this out?

I assume that one would have to modify the GID of such members on the
fly... and LCAS doesn't seem to currently maintain this functionality.

Would this be left up to the implementation of the NMS if it supports
GMPLS, or are (portions) of these features being added to LCAS?

In particular, I am wondering what signaling in G.7042 would allow the
addition of a new member to an existing VCG as stated below:
"""
   Following the addition of the new label to the LSP, LCAS may be used
   in-band to add the new label into the existing VCAT group.  LCAS
   signaling for this function is described in [ITU-T-G.7042].
"""

As far as I have been able to tell, LCAS currently can only modify
pre-existing members of a VCG.  I have not been able to identify any
functionality which would allow a new member to be added to a VCG - am
I missing something?

Perhaps I am misunderstand LCAS' ADD functionality.  It is my
understanding that an LCAS ADD does not actually add a new member to a
VCG, but merely sets an IDLE member of a VCG to become active in the
VCG (e.g. NORM/EOS). Regardless of whether a VCG member is IDLE or
in-use, it will share the same GID as all other members of the VCG.

Any clarification would be much appreciated.

Thank you,
     Aaron

Envelope-to: [email-masked]
Delivery-date: Wed, 12 Dec 2007 23:07:37 +0000
To: [email-masked], [email-masked]
Subject:  RFC 5073 on IGP Routing Protocol Extensions for Discovery of Traffic Engineering Node Capabilities
From: [email-masked]
Cc: [email-masked], [email-masked]
Message-Id: <[email-masked]>
Date: Wed, 12 Dec 2007 15:05:01 -0800 (PST)

A new Request for Comments is now available in online RFC libraries.

        RFC 5073

        Title:      IGP Routing Protocol Extensions for 
                    Discovery of Traffic Engineering Node Capabilities 
        Author:     J.P. Vasseur, Ed.,
                    J.L. Le Roux, Ed.
        Status:     Standards Track
        Date:       December 2007
        Mailbox:    [email-masked], 
                    [email-masked]
        Pages:      13
        Characters: 27004
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-ccamp-te-node-cap-05.txt

        URL:        http://www.rfc-editor.org/rfc/rfc5073.txt

It is highly desired, in several cases, to take into account Traffic
Engineering (TE) node capabilities during Multi Protocol Label
Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineered Label
Switched Path (TE-LSP) selection, such as, for instance, the
capability to act as a branch Label Switching Router (LSR) of a
Point-To-MultiPoint (P2MP) LSP.  This requires advertising these
capabilities within the Interior Gateway Protocol (IGP).  For that
purpose, this document specifies Open Shortest Path First (OSPF) and
Intermediate System-Intermediate System (IS-IS) traffic engineering
extensions for the advertisement of control plane and data plane
traffic engineering node capabilities.  [STANDARDS TRACK]

This document is a product of the Common Control and Measurement Plane
Working Group of the IETF.

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.Please refer to the current edition of the Internet
 Official Protocol Standards (STD 1) for the standardization state and
 status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [email-masked].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [email-masked].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [email-masked] with the message body 

help: ways_to_get_rfcs. For example:

        To: [email-masked]
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to
[email-masked].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.

The RFC Editor Team
USC/Information Sciences Institute

...

Delivery-date: Mon, 10 Dec 2007 14:14:46 +0000
Cc: Ashok Narayanan <[email-masked]>, Jukka Manner MJ <[email-masked]>, allan GUILLOU <[email-masked]>, [email-masked], tsvwg tsvwg <[email-masked]>, Le Faucheur Francois <[email-masked]>
From: Francois Le Faucheur IMAP <[email-masked]>
Subject: Re: CCAMP Vancouver comments on draft-ietf-tsvwg-rsvp-proxy-proto
Date: Mon, 10 Dec 2007 15:12:10 +0100
To: [email-masked]

Hi,

Just following up on the good suggestions we received during the rsvp- 
proxy-proto preso in CCAMP WG.
Below is a recap of the comments and proposed changes to rsvp-proxy- 
proto in order to reflect those.
Comments welcome.

Thanks again to CCAMP WG.

Francois

1) Processing of "Downstream Errors" by Sender
====================================

With Notify approach, the sender not only has to support Notify, but  
it also has to process  "downstream errors". It is worth making this  
explicit.

To that effect, I propose that:
Under  section "3.2.  Sender Notification via Notify Message".
We replace:
"
    Note, however, that such benefits come at the cost of more
    sophistication and of a requirement for RSVP routers and senders to
    support the Notify messages and procedures defined in [RFC3473].
"
by
"
    Note, however, that such benefits come with some costs including :
	o more sophistication
	o a requirement for RSVP routers and senders to
            support the Notify messages and procedures defined in  
[RFC3473]
	o a requirement for senders to process downstream error messages.
"

2) Sending Notify in-addition/instead of PathErr
====================================

Current text does not discuss whether the two methods (PathErr and  
Notify) are exclusive or additive (ie use Notify in addition to  
PathErr). There was also concern expressed about Notify messages  
being less reliable than PathErr and thus it may be safer to get  
Notify issued in-addition to PathErr (and not instead). On the other  
hands there are environments where not sending the PathErr (ie send  
Notify only) could help scalability.

Hence we propose a recommended approach on the safe side (ie send  
both Notify and PathErr) with an optional approach allowing better  
scalability (ie send Notify only). To that effect, I propose that:
At the end of section "3.2.  Sender Notification via Notify Message",
We add:
"
When the method of sender notification via Notify message is used, it  
is RECOMMENDED that the RSVP Receiver Proxy also issues sender  
notification via a PathErr message. This maximizes the chances that  
the notification reaches the sender in all situations (e.g. even if  
some RSVP routers do not support the Notify procedure, or if a Notify  
message gets dropped). However, for controlled environments (e.g.  
where all RSVP routers are known to support Notify procedures) and  
where it is desirable to minimize the volume of signaling, the RSVP  
Receiver Proxy MAY rely exclusively on sender notification via Notify  
message and thus not issue sender notification via PathErr message.
"

Delivery-date: Sat, 08 Dec 2007 04:53:34 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D Action:draft-ietf-ccamp-gmpls-ason-routing-ospf-04.txt 
Date: Fri, 07 Dec 2007 23:50:02 -0500

--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 Extensions for ASON Routing
	Author(s)       : D. Papadimitriou, I. Property
	Filename        : draft-ietf-ccamp-gmpls-ason-routing-ospf-04.txt
	Pages           : 23
	Date            : 2007-12-07

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.

D.Papadimitriou - Expires June 2008

  [page 1]

draft-dimitri-ccamp-gmpls-ason-routing-ospf-04.txt

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-ospf-04.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-04.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-04.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-04.txt

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

Content-Type: text/plain
Content-ID:     <2007-12-07234038.I-D\@ietf.org>

--OtherAccess--

--NextPart--

Delivery-date: Thu, 06 Dec 2007 19:24:17 +0000
Date: Thu, 06 Dec 2007 20:23:05 +0100
From: Loa Andersson <[email-masked]>
Organization: Acreo AB
To: [email-masked]
CC: [email-masked], [email-masked],  [email-masked], [email-masked], [email-masked]
Subject: Re: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt

yes - that was what I asked :)

/Loa

[email-masked] wrote:
> Loa,
>> With that it we should just go ahead and accept this as a
>> ccamp work item.
> If you are asking whether this should be adopted as a WG item then I am in favour.
> 
> regards, neil
> 
> 
>> -----Original Message-----
>> From: Loa Andersson [mailto:[email-masked]] 
>> Sent: 05 December 2007 20:37
>> To: Dan Li
>> Cc: Diego Caviglia; Harrison,N,Neil,DMN R; Attila Takacs; 
>> [email-masked]; [email-masked]
>> Subject: Re: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt
>>
>>
>> All,
>>
>> I'm normally a bit careful with models "layer networks" that 
>> seems to be a rather cumbersome way of explaining the 
>> obvious; however in this case when it is used demonstrate 
>> that no layer violation is at hand I is inclined to accept 
>> that result.
>>
>> I also agree with Dan that it seems to be a good idea to use 
>> RSVP-TE to provision OAM functionality is a good idea.
>>
>> With that it we should just go ahead and accept this as a
>> ccamp work item.
>>
>> /Loa
>>
>> Dan Li wrote:
>>> MessageHi,
>>>
>>> I think there is a misunderstanding with respect to the 
>> objective of 
>>> this draft.
>>>
>>> As I read this draft, it describes how to extend the RSVP protocol
>> to support the configuration/enable the OAM function of Ethernet LSP,
>>
>> which I think is a good thing to do, it is not saying to use signaling
>>
>> protocol to do the OAM work. But anyway, it may be necessary 
>> to clarify
>>
>> the objective at the beginning of this draft.
>>> Regards,
>>>
>>> Dan
>>>
>>>
>>>   ----- Original Message ----- 
>>>   From: Diego Caviglia 
>>>   To: [email-masked] ; Attila Takacs ; 
>> [email-masked] 
>>>   Cc: [email-masked] 
>>>   Sent: Thursday, December 06, 2007 12:27 AM
>>>   Subject: RE: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt
>>>
>>>
>>>   Hi Neil,
>>>
>>>              Yes I totally agree with your analysis.
>>>
>>>    
>>>
>>>   The is not going to redefine or reinvent the OAM that, as 
>> Thomas as 
>>> pointed out, is done by IEEE, the ID just specify how to 
>> use a control 
>>> plane mechanism (GMPLS) set-up at the same time data plane 
>> circuit and 
>>> the related OAM.
>>>
>>>    
>>>
>>>   Frankly specking I don't see any layer violation here.
>>>
>>>    
>>>
>>>   BR
>>>
>>>    
>>>
>>>   Diego
>>>
>>>    
>>>
>>>
>>>
>> ----------------------------------------------------------------------
>>> --------
>>>
>>>   From: [email-masked] [mailto:[email-masked]] 
>>>   Sent: martedì 4 dicembre 2007 22.55
>>>   To: Attila Takacs; [email-masked]; Diego Caviglia
>>>   Cc: [email-masked]
>>>   Subject: RE: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt
>>>
>>>    
>>>
>>>   I'm puzzled.  I read the draft and thought it was 
>> excellent.  It is addressing an important operational issue, 
>> ie a critical operational OAM requirement is to ensure that 
>> whatever mechanism (MP or CP) is used to set-up/tear-down a 
>> connection (so this only applies to co-cs or co-ps 
>> modes....the cl-ps mode does not have connections of course) 
>> is harmonised to the activation/deactivation of the 
>> OAM.....specifically a CV/CC flow.   If we don't ensure this 
>> then there will be obvious operational problems.  This is 
>> essentially what the draft is about.
>>>    
>>>
>>>   Further, GMPLS is a generic OOB CP technique.....it is not a 
>>> specific layer network technology per se (but it is 
>> specific in it's 
>>> choice of signalling and routing components).  So one can apply a 
>>> largely similar (GMPLS) CP technique to all co-cs mode technologies 
>>> (whether they are partitioning a space, freq or time resource - see 
>>> Note) and co-ps mode technologies (which only applies to 
>> partitioning 
>>> a time resource - see Note) on the assumption that the 
>> technology is 
>>> correctly architected in the DP for the mode considered.  
>> It's pretty 
>>> hard not to correctly architect the co-cs mode, but it's 
>> quite easy to 
>>> incorrectly architect the co-ps mode, eg one can't violate 
>> the rules 
>>> of a connection in the co-cs mode but one can in the co-ps mode.
>>>
>>>    
>>>
>>>   Note - When we partition a time resource in regular 
>> time-slices we 
>>> create a co-cs mode layer network.  When we partition a 
>> time resource 
>>> in irregular time-slices we create a co-ps mode layer 
>> network.  More 
>>> information on labelling and resource partitioning can be 
>> found in the 
>>> work on unified modelling (of networks) in G.800.
>>>
>>>    
>>>
>>>   regards, Neil
>>>
>>>     -----Original Message-----
>>>     From: [email-masked] 
>> [mailto:[email-masked]] On Behalf Of Attila Takacs
>>>     Sent: 05 December 2007 02:03
>>>     To: Thomas Nadeau; Diego Caviglia
>>>     Cc: [email-masked]
>>>     Subject: RE: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt
>>>
>>>     Hi Tom,
>>>
>>>     please see inline.
>>>
>>>     Best regards,
>>>
>>>     Attila
>>>
>>>        
>>>
>>>
>>>
>> ----------------------------------------------------------------------
>>> ----
>>>
>>>       From: Thomas Nadeau [mailto:[email-masked]] 
>>>       Sent: Wednesday, December 05, 2007 2:19 AM
>>>       To: Diego Caviglia
>>>       Cc: Attila Takacs; [email-masked]; 
>> [email-masked]
>>>       Subject: Re: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt
>>>
>>>        
>>>
>>>       On Dec 4, 2007, at 7:33 PM, Diego Caviglia wrote:
>>>
>>>
>>>
>>>
>>>
>>>       Hi Thomas,
>>>
>>>                        My understanding of the ID was that 
>> RSVP-TE can 
>>> be used to 'piggyback' CFM set-up, otherwise the scenario 
>> is: usage of 
>>> RSVP-TE to set-up the LSP and NMS (meaning everything that is not 
>>> control plane) to enable to CFM for the LSP.
>>>
>>>        
>>>
>>>       As I understand it, the IEEE is working on set-up of CFM (and 
>>> MEPs), as are some vendors I know. *)
>>>
>>>       This to me seems like the right way to do this.
>>>
>>>        
>>>
>>>     IEEE specified CFM and MIBs to setup CFM.
>>>
>>>     Diego's summary is correct: one can use an NMS or a 
>> control plane 
>>> to setup the data plane. In this case we propose to use 
>> GMPLS to setup 
>>> the data plane: both forwarding + OAM.
>>>
>>>         From your comment I see that you're not happy with the fact 
>>> the ID is so technology specific am I right?
>>>
>>>        
>>>
>>>       Precisely; its gluing CFM to RSVP-TE/GMPLS as a transport.
>>>
>>>     I do not see your point with gluing. What do you mean by "as 
>>> transport"? GMPLS is just controlling OAM, CFM is run solely in the 
>>> data plane.
>>>
>>>      
>>>
>>>      
>>>
>>>         If yes do you agree with the fact that could be useful in 
>>> general to use the same signaling 'session' to set-up the 
>> LSP and to 
>>> enable the CFM?
>>>
>>>        
>>>
>>>       No, I do not agree.  Again, if CFM is to be set-up 
>> e2e, let the 
>>> IEEE define this. Leave GMPLS to CCAMP.
>>>
>>>      
>>>
>>>      
>>>
>>>     Sorry, I cannot follow.
>>>
>>>      
>>>
>>>      
>>>
>>>        
>>>
>>>        
>>>
>>>        
>>>
>>>       --Tom
>>>
>>>        
>>>
>>>        
>>>
>>>
>>>
>>>
>>>
>>>        Best Regards
>>>
>>>
>>>       Diego
>>>
>>>
>>>
>> ----------------------------------------------------------------------
>>> ----
>>>
>>>       From: [email-masked] 
>> [mailto:[email-masked]] On Behalf Of Thomas Nadeau
>>>       Sent: martedì 4 dicembre 2007 11.30
>>>       To: Attila Takacs
>>>       Cc: [email-masked]; [email-masked]
>>>       Subject: Re: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt
>>>
>>>       On Dec 4, 2007, at 1:51 PM, Attila Takacs wrote:
>>>
>>>
>>>
>>>
>>>
>>>
>>>       Hi Thomas,
>>>
>>>       Thank you for the comments!
>>>
>>>       Please see answers inline.
>>>
>>>       Best regards,
>>>       Attila
>>>
>>>
>>>
>> ----------------------------------------------------------------------
>>> --
>>>
>>>         From: Thomas Nadeau [mailto:[email-masked]] 
>>>         Sent: Tuesday, December 04, 2007 2:58 PM
>>>         To: [email-masked]
>>>         Cc: Attila Takacs; [email-masked]
>>>         Subject: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt
>>>
>>>         After reading this draft, I have some questions/comments.
>>>
>>>         1) Overall, I am concerned that the definition of a new TLV 
>>> and these procedures represent
>>>
>>>         what amounts to a laying violation and ask that the 
>> ADs take a 
>>> look at this
>>>
>>>         approach closely. This is similar to the 
>> now-rejected approach 
>>> that was proposed
>>>
>>>         in the l2vpn WG about munging CFM + PWs.  To my 
>> reading, this 
>>> is essentially
>>>
>>>         the same thing. If you want to run CFM, run it 
>> natively over 
>>> the ethernet interfaces and
>>>
>>>         have no regard for the underlying topology (GMPLS, PWs, 
>>> etc...) otherwise you
>>>
>>>         will be creating a mess for implementations and 
>>> interoperability.
>>>
>>>       The application of the draft is exactly for what you 
>> are calling 
>>> out: when CFM is run natively over the Ethernet interfaces. The 
>>> document focuses on GELS and Ethernet LSPs. That is, to 
>> establish CFM 
>>> entities for GMPLS controlled Ethernet LSPs. Hence, I think 
>> there is 
>>> no layer violation issue.
>>>
>>>                 This solution specifically only works for GMPLS 
>>> ethernet LSPs, right?
>>>
>>>       What do I do if I want to set up MPLS ethernet LSPs 
>> (i.e.: PWs) 
>>> and do CFM over those? Oh,
>>>
>>>       that is a different solution, right?  Then what do I do if I 
>>> want to run CFM over some new type of
>>>
>>>       ethernet LSP in the future? More protocol hacks?  The 
>> point is 
>>> to use CFM over an ethernet interface
>>>
>>>       without the underlying layers knowing. This is good 
>> networking 
>>> architecture design, that simplifies
>>>
>>>       implementations and makes them more robust, as well as makes 
>>> using them operationally much
>>>
>>>       easier.
>>>
>>>           2) The introductory sections in this draft give a lot of 
>>> discussion about fast fault detection. I
>>>
>>>           am puzzled by this given that GMPLS networks tend to run 
>>> over quickly self-healing
>>>
>>>           optical infrastructures. Is it therefore truly 
>> necessary to 
>>> motivate this work by
>>>
>>>           requiring fast CFMs?
>>>
>>>         It is right that frequent CCMs are not required if 
>> the layers 
>>> below Ethernet handle protection. However, the ID focuses 
>> on Ethernet 
>>> LSPs where Ethernet is not just a single hop above a 
>> transport LSP. In 
>>> this case Ethernet layer (for clarity GELS) may provide 
>> protection for 
>>> Ethernet LSPs. In any case,  the whole point of the ID is 
>> to allow for 
>>> the appropriate configuration of CFM for Ethernet LSPs with GMPLS.
>>>
>>>           3) This document does not cover E-LMI. Why not?
>>>
>>>         E-LMI is run over the MEF UNI. The ID focuses on 
>> Ethernet LSPs 
>>> within a network.
>>>
>>>           For the purposes of this document, we only 
>> discuss Ethernet 
>>> OAM
>>>
>>>              [IEEE-CFM] aspects that are relevant for the 
>> connectivity 
>>> monitoring
>>>
>>>              of bidirectional point-to-point PBB-TE connections.
>>>
>>>           4) Is this the right place to define this 
>> document or should 
>>> this be done in GELS?
>>>
>>>         Well, GELS is done in CCAMP...this seems to be the right 
>>> place.
>>>
>>>           5)   In section 2 you make the following statement:
>>>
>>>           2.  GMPLS RSVP-TE Extensions
>>>
>>>               To simplify the configuration of connectivity 
>>> monitoring, when an
>>>
>>>              Ethernet LSP is signalled the associated MEPs 
>> should be 
>>> automatically
>>>
>>>               established.  Further more, GMPLS signalling 
>> should be 
>>> able to
>>>
>>>             enable/disable connectivity monitoring of a particular 
>>> Ethernet LSP.
>>>
>>>           To my point in #1 above, you should use the native CFM 
>>> functionality over the ethernet interface and signal
>>>
>>>           those capabilities to the bridges at both ends using the 
>>> IEEE CFM signaling procedures (when and if they
>>>
>>>           are created).  If you want to test the underlying GMPLS 
>>> LSP(s), then you should use some
>>>
>>>           other mechanism defined for that layer such as the work 
>>> stated in draft-ali-ccamp-gmpls-LSP-ping-traceroute-00.txt
>>>
>>>         See the note to your point #1. There is no relation to the 
>>> gmpls-LSP-ping draft.
>>>
>>>                 The point I am making is that perhaps it should.
>>>
>>>                 --Tom
>>>
>>>        
>>>
>>
>> -- 
>> 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]
>>
>> This email was Anti Virus checked by Astaro Security Gateway. 
> http://www.astaro.com
> 
> 
> 

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

This email was Anti Virus checked by Astaro Security Gateway. http://www.astaro.com

Delivery-date: Thu, 06 Dec 2007 19:17:07 +0000
Content-class: urn:content-classes:message
Subject: RE: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt
Date: Thu, 6 Dec 2007 19:14:17 -0000
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>

Loa,
> With that it we should just go ahead and accept this as a
> ccamp work item.
If you are asking whether this should be adopted as a WG item then I am =
in favour.

regards, neil

> -----Original Message-----
> From: Loa Andersson [mailto:[email-masked]]=20
> Sent: 05 December 2007 20:37
> To: Dan Li
> Cc: Diego Caviglia; Harrison,N,Neil,DMN R; Attila Takacs;=20
> [email-masked]; [email-masked]
> Subject: Re: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt
>=20
>=20
> All,
>=20
> I'm normally a bit careful with models "layer networks" that=20
> seems to be a rather cumbersome way of explaining the=20
> obvious; however in this case when it is used demonstrate=20
> that no layer violation is at hand I is inclined to accept=20
> that result.
>=20
> I also agree with Dan that it seems to be a good idea to use=20
> RSVP-TE to provision OAM functionality is a good idea.
>=20
> With that it we should just go ahead and accept this as a
> ccamp work item.
>=20
> /Loa
>=20
> Dan Li wrote:
> > MessageHi,
> >=20
> > I think there is a misunderstanding with respect to the=20
> objective of=20
> > this draft.
> >=20
> > As I read this draft, it describes how to extend the RSVP protocol
>=20
> to support the configuration/enable the OAM function of Ethernet LSP,
>=20
> which I think is a good thing to do, it is not saying to use signaling
>=20
> protocol to do the OAM work. But anyway, it may be necessary=20
> to clarify
>=20
> the objective at the beginning of this draft.
> >=20
> > Regards,
> >=20
> > Dan
> >=20
> >=20
> >   ----- Original Message -----=20
> >   From: Diego Caviglia=20
> >   To: [email-masked] ; Attila Takacs ;=20
> [email-masked]=20
> >   Cc: [email-masked]=20
> >   Sent: Thursday, December 06, 2007 12:27 AM
> >   Subject: RE: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt
> >=20
> >=20
> >   Hi Neil,
> >=20
> >              Yes I totally agree with your analysis.
> >=20
> >   =20
> >=20
> >   The is not going to redefine or reinvent the OAM that, as=20
> Thomas as=20
> > pointed out, is done by IEEE, the ID just specify how to=20
> use a control=20
> > plane mechanism (GMPLS) set-up at the same time data plane=20
> circuit and=20
> > the related OAM.
> >=20
> >   =20
> >=20
> >   Frankly specking I don't see any layer violation here.
> >=20
> >   =20
> >=20
> >   BR
> >=20
> >   =20
> >=20
> >   Diego
> >=20
> >   =20
> >=20
> >=20
> >=20
> ----------------------------------------------------------------------
> > --------
> >=20
> >   From: [email-masked] [mailto:[email-masked]]=20
> >   Sent: marted=EC 4 dicembre 2007 22.55
> >   To: Attila Takacs; [email-masked]; Diego Caviglia
> >   Cc: [email-masked]
> >   Subject: RE: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt
> >=20
> >   =20
> >=20
> >   I'm puzzled.  I read the draft and thought it was=20
> excellent.  It is addressing an important operational issue,=20
> ie a critical operational OAM requirement is to ensure that=20
> whatever mechanism (MP or CP) is used to set-up/tear-down a=20
> connection (so this only applies to co-cs or co-ps=20
> modes....the cl-ps mode does not have connections of course)=20
> is harmonised to the activation/deactivation of the=20
> OAM.....specifically a CV/CC flow.   If we don't ensure this=20
> then there will be obvious operational problems.  This is=20
> essentially what the draft is about.
> >=20
> >   =20
> >=20
> >   Further, GMPLS is a generic OOB CP technique.....it is not a=20
> > specific layer network technology per se (but it is=20
> specific in it's=20
> > choice of signalling and routing components).  So one can apply a=20
> > largely similar (GMPLS) CP technique to all co-cs mode technologies=20
> > (whether they are partitioning a space, freq or time resource - see=20
> > Note) and co-ps mode technologies (which only applies to=20
> partitioning=20
> > a time resource - see Note) on the assumption that the=20
> technology is=20
> > correctly architected in the DP for the mode considered. =20
> It's pretty=20
> > hard not to correctly architect the co-cs mode, but it's=20
> quite easy to=20
> > incorrectly architect the co-ps mode, eg one can't violate=20
> the rules=20
> > of a connection in the co-cs mode but one can in the co-ps mode.
> >=20
> >   =20
> >=20
> >   Note - When we partition a time resource in regular=20
> time-slices we=20
> > create a co-cs mode layer network.  When we partition a=20
> time resource=20
> > in irregular time-slices we create a co-ps mode layer=20
> network.  More=20
> > information on labelling and resource partitioning can be=20
> found in the=20
> > work on unified modelling (of networks) in G.800.
> >=20
> >   =20
> >=20
> >   regards, Neil
> >=20
> >     -----Original Message-----
> >     From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Attila Takacs
> >     Sent: 05 December 2007 02:03
> >     To: Thomas Nadeau; Diego Caviglia
> >     Cc: [email-masked]
> >     Subject: RE: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt
> >=20
> >     Hi Tom,
> >=20
> >     please see inline.
> >=20
> >     Best regards,
> >=20
> >     Attila
> >=20
> >       =20
> >=20
> >=20
> >=20
> ----------------------------------------------------------------------
> > ----
> >=20
> >       From: Thomas Nadeau [mailto:[email-masked]]=20
> >       Sent: Wednesday, December 05, 2007 2:19 AM
> >       To: Diego Caviglia
> >       Cc: Attila Takacs; [email-masked];=20
> [email-masked]
> >       Subject: Re: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt
> >=20
> >       =20
> >=20
> >       On Dec 4, 2007, at 7:33 PM, Diego Caviglia wrote:
> >=20
> >=20
> >=20
> >=20
> >=20
> >       Hi Thomas,
> >=20
> >                        My understanding of the ID was that=20
> RSVP-TE can=20
> > be used to 'piggyback' CFM set-up, otherwise the scenario=20
> is: usage of=20
> > RSVP-TE to set-up the LSP and NMS (meaning everything that is not=20
> > control plane) to enable to CFM for the LSP.
> >=20
> >       =20
> >=20
> >       As I understand it, the IEEE is working on set-up of CFM (and=20
> > MEPs), as are some vendors I know. *)
> >=20
> >       This to me seems like the right way to do this.
> >=20
> >       =20
> >=20
> >     IEEE specified CFM and MIBs to setup CFM.
> >=20
> >     Diego's summary is correct: one can use an NMS or a=20
> control plane=20
> > to setup the data plane. In this case we propose to use=20
> GMPLS to setup=20
> > the data plane: both forwarding + OAM.
> >=20
> >         From your comment I see that you're not happy with the fact=20
> > the ID is so technology specific am I right?
> >=20
> >       =20
> >=20
> >       Precisely; its gluing CFM to RSVP-TE/GMPLS as a transport.
> >=20
> >     I do not see your point with gluing. What do you mean by "as=20
> > transport"? GMPLS is just controlling OAM, CFM is run solely in the=20
> > data plane.
> >=20
> >     =20
> >=20
> >     =20
> >=20
> >         If yes do you agree with the fact that could be useful in=20
> > general to use the same signaling 'session' to set-up the=20
> LSP and to=20
> > enable the CFM?
> >=20
> >       =20
> >=20
> >       No, I do not agree.  Again, if CFM is to be set-up=20
> e2e, let the=20
> > IEEE define this. Leave GMPLS to CCAMP.
> >=20
> >     =20
> >=20
> >     =20
> >=20
> >     Sorry, I cannot follow.
> >=20
> >     =20
> >=20
> >     =20
> >=20
> >       =20
> >=20
> >       =20
> >=20
> >       =20
> >=20
> >       --Tom
> >=20
> >       =20
> >=20
> >       =20
> >=20
> >=20
> >=20
> >=20
> >=20
> >        Best Regards
> >=20
> >=20
> >       Diego
> >=20
> >=20
> >=20
> ----------------------------------------------------------------------
> > ----
> >=20
> >       From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Thomas Nadeau
> >       Sent: marted=EC 4 dicembre 2007 11.30
> >       To: Attila Takacs
> >       Cc: [email-masked]; [email-masked]
> >       Subject: Re: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt
> >=20
> >       On Dec 4, 2007, at 1:51 PM, Attila Takacs wrote:
> >=20
> >=20
> >=20
> >=20
> >=20
> >=20
> >       Hi Thomas,
> >=20
> >       Thank you for the comments!
> >=20
> >       Please see answers inline.
> >=20
> >       Best regards,
> >       Attila
> >=20
> >=20
> >=20
> ----------------------------------------------------------------------
> > --
> >=20
> >         From: Thomas Nadeau [mailto:[email-masked]]=20
> >         Sent: Tuesday, December 04, 2007 2:58 PM
> >         To: [email-masked]
> >         Cc: Attila Takacs; [email-masked]
> >         Subject: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt
> >=20
> >         After reading this draft, I have some questions/comments.
> >=20
> >         1) Overall, I am concerned that the definition of a new TLV=20
> > and these procedures represent
> >=20
> >         what amounts to a laying violation and ask that the=20
> ADs take a=20
> > look at this
> >=20
> >         approach closely. This is similar to the=20
> now-rejected approach=20
> > that was proposed
> >=20
> >         in the l2vpn WG about munging CFM + PWs.  To my=20
> reading, this=20
> > is essentially
> >=20
> >         the same thing. If you want to run CFM, run it=20
> natively over=20
> > the ethernet interfaces and
> >=20
> >         have no regard for the underlying topology (GMPLS, PWs,=20
> > etc...) otherwise you
> >=20
> >         will be creating a mess for implementations and=20
> > interoperability.
> >=20
> >       The application of the draft is exactly for what you=20
> are calling=20
> > out: when CFM is run natively over the Ethernet interfaces. The=20
> > document focuses on GELS and Ethernet LSPs. That is, to=20
> establish CFM=20
> > entities for GMPLS controlled Ethernet LSPs. Hence, I think=20
> there is=20
> > no layer violation issue.
> >=20
> >                 This solution specifically only works for GMPLS=20
> > ethernet LSPs, right?
> >=20
> >       What do I do if I want to set up MPLS ethernet LSPs=20
> (i.e.: PWs)=20
> > and do CFM over those? Oh,
> >=20
> >       that is a different solution, right?  Then what do I do if I=20
> > want to run CFM over some new type of
> >=20
> >       ethernet LSP in the future? More protocol hacks?  The=20
> point is=20
> > to use CFM over an ethernet interface
> >=20
> >       without the underlying layers knowing. This is good=20
> networking=20
> > architecture design, that simplifies
> >=20
> >       implementations and makes them more robust, as well as makes=20
> > using them operationally much
> >=20
> >       easier.
> >=20
> >           2) The introductory sections in this draft give a lot of=20
> > discussion about fast fault detection. I
> >=20
> >           am puzzled by this given that GMPLS networks tend to run=20
> > over quickly self-healing
> >=20
> >           optical infrastructures. Is it therefore truly=20
> necessary to=20
> > motivate this work by
> >=20
> >           requiring fast CFMs?
> >=20
> >         It is right that frequent CCMs are not required if=20
> the layers=20
> > below Ethernet handle protection. However, the ID focuses=20
> on Ethernet=20
> > LSPs where Ethernet is not just a single hop above a=20
> transport LSP. In=20
> > this case Ethernet layer (for clarity GELS) may provide=20
> protection for=20
> > Ethernet LSPs. In any case,  the whole point of the ID is=20
> to allow for=20
> > the appropriate configuration of CFM for Ethernet LSPs with GMPLS.
> >=20
> >           3) This document does not cover E-LMI. Why not?
> >=20
> >         E-LMI is run over the MEF UNI. The ID focuses on=20
> Ethernet LSPs=20
> > within a network.
> >=20
> >           For the purposes of this document, we only=20
> discuss Ethernet=20
> > OAM
> >=20
> >              [IEEE-CFM] aspects that are relevant for the=20
> connectivity=20
> > monitoring
> >=20
> >              of bidirectional point-to-point PBB-TE connections.
> >=20
> >           4) Is this the right place to define this=20
> document or should=20
> > this be done in GELS?
> >=20
> >         Well, GELS is done in CCAMP...this seems to be the right=20
> > place.
> >=20
> >           5)   In section 2 you make the following statement:
> >=20
> >           2.  GMPLS RSVP-TE Extensions
> >=20
> >               To simplify the configuration of connectivity=20
> > monitoring, when an
> >=20
> >              Ethernet LSP is signalled the associated MEPs=20
> should be=20
> > automatically
> >=20
> >               established.  Further more, GMPLS signalling=20
> should be=20
> > able to
> >=20
> >             enable/disable connectivity monitoring of a particular=20
> > Ethernet LSP.
> >=20
> >           To my point in #1 above, you should use the native CFM=20
> > functionality over the ethernet interface and signal
> >=20
> >           those capabilities to the bridges at both ends using the=20
> > IEEE CFM signaling procedures (when and if they
> >=20
> >           are created).  If you want to test the underlying GMPLS=20
> > LSP(s), then you should use some
> >=20
> >           other mechanism defined for that layer such as the work=20
> > stated in draft-ali-ccamp-gmpls-LSP-ping-traceroute-00.txt
> >=20
> >         See the note to your point #1. There is no relation to the=20
> > gmpls-LSP-ping draft.
> >=20
> >                 The point I am making is that perhaps it should.
> >=20
> >                 --Tom
> >=20
> >       =20
> >=20
>=20
>=20
> --=20
> Loa Andersson
>=20
> 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]
>=20
> This email was Anti Virus checked by Astaro Security Gateway.=20
http://www.astaro.com

Delivery-date: Thu, 06 Dec 2007 16:24:03 +0000
Date: Thu, 06 Dec 2007 17:21:38 +0100
From: dimitri papadimitriou <[email-masked]>
Reply-To:  [email-masked]
To: Adrian Farrel <[email-masked]>
CC: Loa Andersson <[email-masked]>, ccamp <[email-masked]>
Subject: Re: GELS: what happened alternatively what will happen

adrian, all

my suggestion is to focus the work on a step-wise basis

we have a requirement doc. and an architecture doc. that can at this 
point in time be the main focus wrt workplan setup by the chairs (note 
there was no timeline associated when the email detailing the workplan 
was sent during summer time). they deserve to be commented and discussed 
on the list also (if that is still possible). in order to accelerate the 
process we might even propose certain deadlines/milestones for such 
commenting phases.

concerning the strict protocol work, per Ethernet fwd'ing techno 
solution/spec is not the right approach imho. what we should do is work 
on the protocol mechanisms label distribution, resource reservation, 
source explicit routing, re-routing, etc. and the protocol elements 
label, tspecs, etc. This such that it becomes possible to articulate 
them wrt to the Ethernet fwd'ing technos and not define the Ethernet 
control elements on a per-techno basis. i am not saying this is 
necessarily possible  for all Ethernet fwd'ing technos but it is the 
role of the former documents to determine how far we could progress with 
such approach.

Reasons are:

a) techno-specific elements have always been minimized in RFC 3945 arch. 
(technos do not impact the core GMPLS protocol arch. and processing, 
remember the early good days of an LSR associated to any kind of 
switching node)

b) on a practical basis, does it make sense to have X GMPLS protocol 
specs (and so implementations) because there are X (foreseen) Ethernet 
fwd'ing techno that could fit ?

c) how these different control elements are going to easily interoperate 
(wrt to the interoperability of the fwd'ing components) ?

thanks,
-d.

Adrian Farrel wrote:
> Hi Loa,
> 
> Deborah and I want to move the Ethernet I-Ds forward (into the WG) as 
> quickly as possible, but we also need to organise our thoughts.
> 
> Can you give us a couple of days to work out what we want to do with the 
> drafts, and in what order?
> 
> In the mean time, a reminder to the whole WG that they should review and 
> comment on the list. Questions and issues are welcomed. Suggested text 
> is best.
> 
> Thanks,
> Adrian
> 
> ----- Original Message ----- From: "Loa Andersson" <[email-masked]>
> To: "ccamp" <[email-masked]>
> Sent: Thursday, December 06, 2007 2:28 AM
> Subject: what happened alternatively what will happen
> 
> 
>> Adrian and Deborah,
>>
>> yesterday a set of IDs on GMPLS control of Ethernet were presented;
>> given that I remember correctly the author of the requirement draft
>> said they think that the draft will be ready to become a working
>> group document after next IETF meeting.
>>
>> The authors of the architecture draft for GMPLS controlled Ethernet
>> and the protocol extensions for control of PBT-TE networks requested
>> that their draft should be accepted as working group documents.
>>
>> No sense of the room were taken or "take it to the list" statement.
>>
>> What's the plan?
>>
>> /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]
>>
>> This email was Anti Virus checked by Astaro Security Gateway. 
>> http://www.astaro.com
>>
>>
>>
> 
> 
> 
> 
> .
> 

Delivery-date: Thu, 06 Dec 2007 15:00:26 +0000
Date: Thu, 6 Dec 2007 06:58:03 -0800 (PST)
From: Igor Bryskin <[email-masked]>
Subject: Re: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt
To: Attila Takacs <[email-masked]>, Wataru Imajuku <[email-masked]>
Cc: [email-masked]

--0-913381410-1196953083=:79554
Content-Type: text/plain; charset=iso-2022-jp

Hi Watatru,

Although I understand, I think, your point - Enabling/disabling  of alarm reporting and enabling/disabling of OAM for a given connection may seem similar in spirit - I agree with Attila and Adrian: the two   functions are very distinct and we certainly don't want to overload the A-bit.

Cheers,
Igor

----- Original Message ----
From: Attila Takacs <[email-masked]>
To: Wataru Imajuku <[email-masked]>
Cc: [email-masked]
Sent: Wednesday, December 5, 2007 10:07:37 PM
Subject: RE: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt

Hi 
Wataru,

Just 
adding to Adrian's points...

I 
think it is useful to separate A and M bits. When the LSP is 
put in administratively down, e.g.,  to avoid it is carrying traffic for 
any reason, it would be still useful to run data plane OAM 
so one knows the data plane is in tact when the LSP is 
put back operational. That is,  A=1, M=0. On the other 
hand, e.g., in the case of planed maintenance, one might want to turn data plane 
OAM off as well, having A=1, M=1.

Regarding the I bit, I think even if GMPLS alarm communication is 
disabled, the actual monitoring of data plane connectivity is needed, again 
to have the up to date status of the data plane.

In 
summary, I think having a separate M bit is useful, and accounts 
for flexibility.

Best 
regards,

Attila

  
  
  From: Wataru Imajuku 
  [mailto:[email-masked]] 
Sent: Wednesday, December 05, 
  2007 9:53 PM
To: Attila Takacs
Cc: 
  [email-masked]
Subject: RE: 
  draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt

Hi, Attila

 I understand this proposal automates manual 
  configuration to set CFM interval in data plane.
 Control of CFM 
  interval is new issue which GMPLS signaling mechanism has not 
  covered.
 Although you outline Ethernet OAM functionality in section 
  2, I think it is better to describe what is difference and what is common in 
  OAM functionality compared to circuit switched technologies 
which GMPLS 
  has been covered.

 On the other hand, I could not understand why 
  do you need M bit in Admin Status Object.
 Why do not use A=1 
  ?
 Is the objective of M bit to stop sending CCM temporally 
  ?

Best Regards
Wataru

At 04:37 07/12/06, Attila Takacs 
  wrote:

  "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"> 
Hi all,
 
Neil's and Dan's summary are exact. Thanks for your 
    comments!
 
Maybe 
    the title of the ID caused the misunderstanding, it would say more if it 
    would read: "GMPLS RSVP-TE Extensions to *Control* Ethernet 
    OAM".
Nevertheless, when updating the ID we will clarify our point even 
    more.
 
Best 
    regards,
Attila

      From: Dan Li [mailto:[email-masked]] 

      Sent: Wednesday, December 05, 2007 6:01 PM

      To: Diego Caviglia; [email-masked]; Attila Takacs; 
      [email-masked]

      Cc: [email-masked]

      Subject: Re: 
      draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt

      Hi,

      I think there is a misunderstanding with respect to the objective of 
      this draft. 

      As I read this draft, it describes how to extend the RSVP protocol to 
      support the configuration/enable the OAM function of Ethernet LSP, which I 
      think is a good thing to do, it is not saying to use signaling protocol to 
      do the OAM work. But anyway, it may be necessary to clarify the objective 
      at the beginning of this draft.

      Regards,

      Dan

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

      From: Diego 
      Caviglia 

      To: [email-masked] ; Attila Takacs ; [email-masked] 

      Cc: [email-masked] 

      Sent: Thursday, December 06, 2007 12:27 AM

      Subject: RE: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt

      Hi Neil,

                 Yes I 
      totally agree with your analysis.

      The is not going to redefine or 
      reinvent the OAM that, as Thomas as pointed out, is done by IEEE, the ID 
      just specify how to use a control plane mechanism (GMPLS) set-up at the 
      same time data plane circuit and the related OAM.

      Frankly specking I don$BCU(B see any 
      layer violation here.

      BR

      Diego

      

      From: [email-masked] [mailto:[email-masked]] 

      Sent: marted$B!&(B4 dicembre 2007 22.55

      To: Attila Takacs; [email-masked]; Diego 
      Caviglia

      Cc: [email-masked]

      Subject: RE: 
      draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt

      I'm puzzled.  I 
      read the draft and thought it was excellent.  It is addressing an 
      important operational issue, ie a critical operational OAM requirement is 
      to ensure that whatever mechanism (MP or CP) is used to set-up/tear-down a 
      connection (so this only applies to co-cs or co-ps modes....the cl-ps mode 
      does not have connections of course) is harmonised to the 
      activation/deactivation of the OAM.....specifically a CV/CC 
      flow.   If we don't ensure this then there will be obvious 
      operational problems.  This is essentially what the draft is 
      about.

      Further, GMPLS is a 
      generic OOB CP technique.....it is not a specific layer network technology 
      per se (but it is specific in it's choice of signalling and routing 
      components).  So one can apply a largely similar (GMPLS) CP technique 
      to all co-cs mode technologies (whether they are partitioning a space, 
      freq or time resource - see Note) and co-ps mode technologies (which only 
      applies to partitioning a time resource - see Note) on the assumption that 
      the technology is correctly architected in the DP for the mode 
      considered.  It's pretty hard not to correctly architect the co-cs 
      mode, but it's quite easy to incorrectly architect the co-ps mode, eg one 
      can't violate the rules of a connection in the co-cs mode but one can in 
      the co-ps mode.

      Note - When we 
      partition a time resource in regular time-slices we create a co-cs mode 
      layer network.  When we partition a time resource in irregular 
      time-slices we create a co-ps mode layer network.  More information 
      on labelling and resource partitioning can be found in the work on unified 
      modelling (of networks) in G.800.

      regards, 
      Neil

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

      From: [email-masked] [mailto:[email-masked]] On Behalf Of 
      Attila Takacs

      Sent: 05 December 2007 02:03

      To: Thomas Nadeau; Diego Caviglia

      Cc: [email-masked]

      Subject: RE: 
      draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt

      Hi Tom,

      please see 
inline.

      Best regards,

      Attila

      

      From: Thomas Nadeau [mailto:[email-masked]] 

      Sent: Wednesday, December 05, 2007 2:19 AM

      To: Diego Caviglia

      Cc: Attila Takacs; [email-masked]; 
[email-masked]

      Subject: Re: 
      draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt

      On Dec 4, 2007, at 7:33 PM, Diego 
      Caviglia wrote:

      Hi Thomas,

      My understanding of the ID was that RSVP-TE can be used to $BAQ(Biggyback$B!)(BCFM 
      set-up, otherwise the scenario is: usage of RSVP-TE to set-up the LSP and 
      NMS (meaning everything that is not control plane) to enable to CFM for 
      the LSP.

      As I understand it, the IEEE is working 
      on set-up of CFM (and MEPs), as are some vendors I know. *)

      This to me seems like the right way to do 
      this.

 IEEE specified CFM and MIBs to setup CFM. 

Diego's summary is 
    correct: one can use an NMS or a control plane to setup the data plane. In 
    this case we propose to use GMPLS to setup the data plane: both forwarding + 
    OAM.

        From your comment 
        I see that you$BCS(Be not happy with the fact the ID is so technology 
        specific am I right?  

Precisely; its gluing CFM to RSVP-TE/GMPLS as a 
      transport. 
I 
    do not see your point with gluing. What do you mean by "as transport"? GMPLS 
    is just controlling OAM, CFM is run solely in the data 
    plane.

      

        If yes do you 
        agree with the fact that could be useful in general to use the same 
        signaling $BAT(Bession$B!)(Bto set-up the LSP and to enable the 
        CFM?

No, I do not agree.  Again, if CFM is to be 
      set-up e2e, let the IEEE define this. Leave GMPLS to 
    CCAMP.

Sorry, I cannot follow.

      

      

      --Tom

      

       Best Regards

      Diego

      From: [email-masked] [mailto:[email-masked]] 
      On Behalf Of Thomas Nadeau

      Sent: marted$B!&(B4 dicembre 2007 11.30

      To: Attila Takacs

      Cc: [email-masked]; [email-masked]

      Subject: Re: 
      draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt

      On Dec 4, 2007, at 1:51 PM, Attila Takacs 
      wrote:

      Hi Thomas,

      Thank you for the 
      comments!

      Please see answers 
      inline.

      Best regards,

      Attila

      From: Thomas Nadeau [mailto:[email-masked]] 

      Sent: Tuesday, December 04, 2007 2:58 PM

      To: [email-masked]

      Cc: Attila Takacs; [email-masked]

      Subject: 
      draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt

      After reading this draft, I have some 
      questions/comments.

      1) Overall, I am concerned that the 
      definition of a new TLV and these procedures represent 

      what amounts to a laying violation and 
      ask that the ADs take a look at this

      approach closely. This is similar to the 
      now-rejected approach that was proposed

      in the l2vpn WG about munging CFM + 
      PWs.  To my reading, this is essentially

      the same thing. If you want to run CFM, 
      run it natively over the ethernet interfaces and

      have no regard for the underlying 
      topology (GMPLS, PWs, etc...) otherwise you 

      will be creating a mess for 
      implementations and interoperability. 

The application of the draft is exactly for what you are calling out: 
    when CFM is run natively over the Ethernet interfaces. The document focuses 
    on GELS and Ethernet LSPs. That is, to establish CFM entities for GMPLS 
    controlled Ethernet LSPs. Hence, I think there is no layer violation 
    issue.

    This solution specifically only works for GMPLS ethernet LSPs, 
    right?  

What do I do if I want to 
    set up MPLS ethernet LSPs (i.e.: PWs) and do CFM over those? 
    Oh,

that is a different solution, 
    right?  Then what do I do if I want to run CFM over some new type 
    of

ethernet LSP in the future? 
    More protocol hacks?  The point is to use CFM over an ethernet 
    interface

without the underlying 
    layers knowing. This is good networking architecture design, that 
    simplifies

implementations and 
    makes them more robust, as well as makes using them operationally 
    much

easier. 

        2) The introductory sections in this 
        draft give a lot of discussion about fast fault detection. 
        I

        am puzzled by this given that GMPLS 
        networks tend to run over quickly self-healing

        optical infrastructures. Is it 
        therefore truly necessary to motivate this work by

        requiring fast 
      CFMs?

It is 
      right that frequent CCMs are not required if the layers below Ethernet 
      handle protection. However, the ID focuses on Ethernet LSPs where Ethernet 
      is not just a single hop above a transport LSP. In this case Ethernet 
      layer (for clarity GELS) may provide protection for Ethernet LSPs. In any 
      case,  the whole point of the ID is to allow for the appropriate 
      configuration of CFM for Ethernet LSPs with GMPLS.

        3) This document does not cover E-LMI. 
        Why not?

E-LMI is run over the MEF UNI. The ID focuses on Ethernet LSPs 
      within a network.

        For the purposes of this 
        document, we only discuss Ethernet OAM

           [IEEE-CFM] aspects that are 
        relevant for the connectivity monitoring

           of bidirectional 
        point-to-point PBB-TE connections.  

        4) Is this the right place to define 
        this document or should this be done in 
      GELS?

Well, 
      GELS is done in CCAMP...this seems to be the right place.

        5)   In section 2 you make the 
        following statement:

        2.  GMPLS RSVP-TE 
        Extensions

            To simplify the 
        configuration of connectivity monitoring, when an

           Ethernet LSP is signalled 
        the associated MEPs should be automatically

            established.  
        Further more, GMPLS signalling should be able to

          enable/disable connectivity 
        monitoring of a particular Ethernet LSP.

        To my point in #1 above, you should use 
        the native CFM functionality over the ethernet interface and 
        signal

        those capabilities to the bridges at 
        both ends using the IEEE CFM signaling procedures (when and if 
        they

        are created).  If you want to test 
        the underlying GMPLS LSP(s), then you should use some

        other mechanism defined for that layer 
        such as the work stated in draft-ali-ccamp-gmpls-LSP-ping-traceroute-00.txt

See the note to your point #1. There is no 
      relation to the gmpls-LSP-ping draft. 
         
    The point I am making is that perhaps it should.

    --Tom

   -------------------------------------
Wataru Imajuku, 
  Ph.D.@NTT Network Innovation Labs
TEL: +81-46-859-4315
FAX: 
  +81-46-859-5541

      ____________________________________________________________________________________
Looking for last minute shopping deals?  
Find them fast with Yahoo! Search.  http://tools.search.yahoo.com/newsearch/category.php?category=shopping
--0-913381410-1196953083=:79554
Content-Type: text/html; charset=iso-2022-jp

<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:times new roman, new york, times, serif;font-size:12pt"><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;">Hi Watatru,<br><br>Although I understand, I think, your point - Enabling/disabling&nbsp; of alarm reporting and enabling/disabling of OAM for a given connection may seem similar in spirit - I agree with Attila and Adrian: the two&nbsp;  functions are very distinct and we certainly don't want to overload the A-bit.<br><br>Cheers,<br>Igor<br><br><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;">----- Original Message ----<br>From: Attila Takacs &lt;[email-masked]&gt;<br>To: Wataru Imajuku &lt;[email-masked]&gt;<br>Cc: [email-masked]<br>Sent: Wednesday, December 5, 2007 10:07:37 PM<br>Subject: RE: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt<br><br>

<div><span class="434585301-06122007"><font color="#0000ff" face="Arial" size="2">Hi 
Wataru,</font></span></div>
<div><span class="434585301-06122007"><font color="#0000ff" face="Arial" size="2"></font></span>&nbsp;</div>
<div><span class="434585301-06122007"><font color="#0000ff" face="Arial" size="2">Just 
adding to Adrian's points...</font></span></div>
<div><span class="434585301-06122007"><font color="#0000ff" face="Arial" size="2"></font></span>&nbsp;</div>
<div><span class="434585301-06122007"><font color="#0000ff" face="Arial" size="2">I 
think it is useful to separate A and M bits. </font></span><span class="434585301-06122007"><font color="#0000ff" face="Arial" size="2">When the LSP is 
put in administratively down, e.g., &nbsp;to avoid it is carrying traffic for 
any reason,&nbsp;it would be still useful to run data plane OAM 
so&nbsp;one&nbsp;knows the data plane is in tact&nbsp;when&nbsp;the LSP&nbsp;is 
put back operational.&nbsp;That is, &nbsp;A=1, M=0. </font></span><span class="434585301-06122007"><font color="#0000ff" face="Arial" size="2">On the other 
hand, e.g., in the case of planed maintenance, one might want to turn data plane 
OAM off as well, having A=1, M=1.</font></span></div>
<div><span class="434585301-06122007"><font color="#0000ff" face="Arial" size="2"></font></span>&nbsp;</div>
<div><span class="434585301-06122007"><font color="#0000ff" face="Arial" size="2">Regarding the I bit, I think even if GMPLS alarm communication is 
disabled, the actual monitoring of data plane connectivity&nbsp;is needed, again 
to have&nbsp;the up to date status of the data plane.</font></span></div>
<div><span class="434585301-06122007"><font color="#0000ff" face="Arial" size="2"></font></span>&nbsp;</div>
<div><span class="434585301-06122007"><font color="#0000ff" face="Arial" size="2">In 
summary, I think having a separate M bit is useful, and&nbsp;accounts 
for&nbsp;flexibility.</font></span></div>
<div><span class="434585301-06122007"><font color="#0000ff" face="Arial" size="2"></font></span>&nbsp;</div>
<div><span class="434585301-06122007"><font color="#0000ff" face="Arial" size="2">Best 
regards,</font></span></div>
<div><span class="434585301-06122007"><font color="#0000ff" face="Arial" size="2">Attila</font></span></div>
<div><span class="434585301-06122007"><font color="#0000ff" face="Arial" size="2"></font></span>&nbsp;</div>
<div><span class="434585301-06122007"><font color="#0000ff" face="Arial" size="2"></font></span>&nbsp;</div><font color="#0000ff" face="Arial" size="2"></font><br>
<blockquote dir="ltr" style="border-left: 2px solid rgb(0, 0, 255); padding-left: 5px; margin-left: 5px; margin-right: 0px;">
  <div class="OutlookMessageHeader" dir="ltr" align="left" lang="en-us">
  <hr tabindex="-1">
  <font face="Tahoma" size="2"><b>From:</b> Wataru Imajuku 
  [mailto:[email-masked]] <br><b>Sent:</b> Wednesday, December 05, 
  2007 9:53 PM<br><b>To:</b> Attila Takacs<br><b>Cc:</b> 
  [email-masked]<br><b>Subject:</b> RE: 
  draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt<br></font><br></div>
  <div></div>Hi, Attila<br><br>&nbsp;I understand this proposal automates manual 
  configuration to set CFM interval in data plane.<br>&nbsp;Control of CFM 
  interval is new issue which GMPLS signaling mechanism has not 
  covered.<br>&nbsp;Although you outline Ethernet OAM functionality in section 
  2, I think it is better to describe what is difference and what is common in 
  OAM functionality compared to circuit switched technologies <br>which GMPLS 
  has been covered.<br><br>&nbsp;On the other hand, I could not understand why 
  do you need M bit in Admin Status Object.<br>&nbsp;Why do not use A=1 
  ?<br>&nbsp;Is the objective of M bit to stop sending CCM temporally 
  ?<br><br>Best Regards<br>Wataru<br><br>At 04:37 07/12/06, Attila Takacs 
  wrote:<br>
  <blockquote type="cite">"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"&gt; <br><font color="#0000ff" face="arial" size="2">Hi all,<br></font>&nbsp;<br><font color="#0000ff" face="arial" size="2">Neil's and Dan's summary are exact. Thanks for your 
    comments!<br></font>&nbsp;<br><font color="#0000ff" face="arial" size="2">Maybe 
    the title of the ID caused the misunderstanding, it would say more if it 
    would read: "GMPLS RSVP-TE Extensions to *Control* Ethernet 
    OAM".<br>Nevertheless, when updating the ID we will clarify our point even 
    more.<br></font>&nbsp;<br><font color="#0000ff" face="arial" size="2">Best 
    regards,<br>Attila<br></font><br>
    <dl>
      <SPAN style="width:100%;height:2px;border-bottom:1px solid rgb(212,208,200); border-top:1px solid rgb(128,128,128);background-color:black;overflow:hidden; margin:8px 0px;"></SPAN>

      <dd><font face="tahoma" size="2">From: Dan Li [<a rel="nofollow" ymailto="mailto:[email-masked]" target="_blank" href="mailto:[email-masked]">mailto:[email-masked]</a>] <br>
      </font></dd><dd><font face="tahoma" size="2">Sent: Wednesday, December 05, 2007 6:01 PM<br>
      </font></dd><dd><font face="tahoma" size="2">To: Diego Caviglia; [email-masked]; Attila Takacs; 
      [email-masked]<br>
      </font></dd><dd><font face="tahoma" size="2">Cc: [email-masked]<br>
      </font></dd><dd><font face="tahoma" size="2">Subject: Re: 
      draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt<br></font><br>
      </dd><dd>Hi,<br>
      </dd><dd><br>&nbsp;
      </dd><dd>I think there is a misunderstanding with respect to the objective of 
      this draft. <br>
      </dd><dd><br>&nbsp;
      </dd><dd>As I read this draft, it describes how to extend the RSVP protocol to 
      support the configuration/enable the OAM function of Ethernet LSP, which I 
      think is a good thing to do, it is not saying to use signaling protocol to 
      do the OAM work. But anyway, it may be necessary to clarify the objective 
      at the beginning of this draft.<br>
      </dd><dd><br>&nbsp;
      </dd><dd>Regards,<br>
      </dd><dd><br>&nbsp;
      </dd><dd>Dan<br>
      </dd><dd><br>&nbsp;
      </dd><dd><br>&nbsp;
      </dd><dd>----- Original Message ----- <br>
      </dd><dd>From: <a rel="nofollow" ymailto="mailto:[email-masked]" target="_blank" href="mailto:[email-masked]">Diego 
      Caviglia</a> <br>
      </dd><dd>To: <a rel="nofollow" ymailto="mailto:[email-masked]" target="_blank" href="mailto:[email-masked]">[email-masked]</a> ; <a rel="nofollow" ymailto="mailto:[email-masked]" target="_blank" href="mailto:[email-masked]">Attila Takacs</a> ; <a rel="nofollow" ymailto="mailto:[email-masked]" target="_blank" href="mailto:[email-masked]">[email-masked]</a> <br>
      </dd><dd>Cc: <a rel="nofollow" ymailto="mailto:[email-masked]" target="_blank" href="mailto:[email-masked]">[email-masked]</a> 
<br>
      </dd><dd>Sent: Thursday, December 06, 2007 12:27 AM<br>
      </dd><dd>Subject: RE: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt<br><br>
      </dd><dd><font color="#000080" face="arial" size="2">Hi Neil,<br></font><br>
      </dd><dd><font color="#000080" face="arial" size="2">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Yes I 
      totally agree with your analysis.<br></font><br>
      </dd><dd><font color="#000080" face="arial" size="2"><br></font><br>&nbsp;
      </dd><dd><font color="#000080" face="arial" size="2">The is not going to redefine or 
      reinvent the OAM that, as Thomas as pointed out, is done by IEEE, the ID 
      just specify how to use a control plane mechanism (GMPLS) set-up at the 
      same time data plane circuit and the related OAM.<br></font><br>
      </dd><dd><font color="#000080" face="arial" size="2"><br></font><br>&nbsp;
      </dd><dd><font color="#000080" face="arial" size="2">Frankly specking I don$BCU(B see any 
      layer violation here.<br></font><br>
      </dd><dd><font color="#000080" face="arial" size="2"><br></font><br>&nbsp;
      </dd><dd><font color="#000080" face="arial" size="2">BR<br></font><br>
      </dd><dd><font color="#000080" face="arial" size="2"><br></font><br>&nbsp;
      </dd><dd><font color="#000080" face="arial" size="2">Diego<br></font><br>
      </dd><dd><font color="#000080" face="arial" size="2"><br>
      </font><SPAN style="width:100%;height:2px;border-bottom:1px solid rgb(212,208,200); border-top:1px solid rgb(128,128,128);background-color:black;overflow:hidden; margin:8px 0px;"></SPAN>

<font color="#000080" face="arial" size="2">      </font><div align="center"></div>
      </dd><dd><font face="tahoma" size="2">From: <a rel="nofollow" ymailto="mailto:[email-masked]" target="_blank" href="mailto:[email-masked]">[email-masked]</a> [<a rel="nofollow" ymailto="mailto:[email-masked]" target="_blank" href="mailto:[email-masked]">mailto:[email-masked]</a>] <br>
      </font></dd><dd><font face="tahoma" size="2">Sent: marted$B!&(B4 dicembre 2007 22.55<br>
      </font></dd><dd><font face="tahoma" size="2">To: Attila Takacs; <a rel="nofollow" ymailto="mailto:[email-masked]" target="_blank" href="mailto:[email-masked]">[email-masked]</a>; Diego 
      Caviglia<br>
      </font></dd><dd><font face="tahoma" size="2">Cc: <a rel="nofollow" ymailto="mailto:[email-masked]" target="_blank" href="mailto:[email-masked]">[email-masked]</a><br>
      </font></dd><dd><font face="tahoma" size="2">Subject: RE: 
      draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt<br></font><br>
      </dd><dd><font face="times new roman"><br></font><br>&nbsp;
      </dd><dd><font color="#800000" face="comic sans ms" size="2">I'm puzzled.&nbsp; I 
      read the draft and thought it was excellent.&nbsp; It is addressing an 
      important operational issue, ie a critical operational OAM requirement is 
      to ensure that whatever mechanism (MP or CP) is used to set-up/tear-down a 
      connection (so this only applies to co-cs or co-ps modes....the cl-ps mode 
      does not have connections of course) is harmonised to the 
      activation/deactivation of the OAM.....specifically a CV/CC 
      flow.&nbsp;&nbsp; If we don't ensure this then there will be obvious 
      operational problems.&nbsp; This is essentially what the draft is 
      about.<br></font><br>
      </dd><dd><font face="times new roman"><br></font><br>&nbsp;
      </dd><dd><font color="#800000" face="comic sans ms" size="2">Further, GMPLS is a 
      generic OOB CP technique.....it is not a specific layer network technology 
      per se (but it is specific in it's choice of signalling and routing 
      components).&nbsp; So one can apply a largely similar (GMPLS) CP technique 
      to all co-cs mode technologies (whether they are partitioning a space, 
      freq or time resource - see Note) and co-ps mode technologies (which only 
      applies to partitioning a time resource - see Note) on the assumption that 
      the technology is correctly architected in the DP for the mode 
      considered.&nbsp; It's pretty hard not to correctly architect the co-cs 
      mode, but it's quite easy to incorrectly architect the co-ps mode, eg one 
      can't violate the rules of a connection in the co-cs mode but one can in 
      the co-ps mode.<br></font><br>
      </dd><dd><font face="times new roman"><br></font><br>&nbsp;
      </dd><dd><font color="#800000" face="comic sans ms" size="2">Note - When we 
      partition a time resource in regular time-slices we create a co-cs mode 
      layer network.&nbsp; When we partition a time resource in irregular 
      time-slices we create a co-ps mode layer network.&nbsp; More information 
      on labelling and resource partitioning can be found in the work on unified 
      modelling (of networks) in G.800.<br></font><br>
      </dd><dd><font face="times new roman"><br></font><br>&nbsp;
      </dd><dd><font color="#800000" face="comic sans ms" size="2">regards, 
      Neil<br></font><br>
      </dd><dd><font face="tahoma" size="2">-----Original Message-----<br>
      </font></dd><dd><font face="tahoma" size="2">From: [email-masked] [<a rel="nofollow" ymailto="mailto:[email-masked]" target="_blank" href="mailto:[email-masked]">mailto:[email-masked]</a>] On Behalf Of 
      Attila Takacs<br>
      </font></dd><dd><font face="tahoma" size="2">Sent: 05 December 2007 02:03<br>
      </font></dd><dd><font face="tahoma" size="2">To: Thomas Nadeau; Diego Caviglia<br>
      </font></dd><dd><font face="tahoma" size="2">Cc: [email-masked]<br>
      </font></dd><dd><font face="tahoma" size="2">Subject: RE: 
      draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt<br></font><br>
      </dd><dd><font color="#0000ff" face="arial" size="2">Hi Tom,<br></font><br>
      </dd><dd><font color="#0000ff" face="arial" size="2">please see 
inline.<br></font><br>
      </dd><dd><font color="#0000ff" face="arial" size="2">Best regards,<br></font><br>
      </dd><dd><font color="#0000ff" face="arial" size="2">Attila<br></font><br>
      </dd><dd><font face="times new roman"><br>
      </font><SPAN style="width:100%;height:2px;border-bottom:1px solid rgb(212,208,200); border-top:1px solid rgb(128,128,128);background-color:black;overflow:hidden; margin:8px 0px;"></SPAN>

<font face="times new roman">      </font><div align="center"></div>
      </dd><dd><font face="tahoma" size="2">From: Thomas Nadeau [<a rel="nofollow" ymailto="mailto:[email-masked]" target="_blank" href="mailto:[email-masked]">mailto:[email-masked]</a>] <br>
      </font></dd><dd><font face="tahoma" size="2">Sent: Wednesday, December 05, 2007 2:19 AM<br>
      </font></dd><dd><font face="tahoma" size="2">To: Diego Caviglia<br>
      </font></dd><dd><font face="tahoma" size="2">Cc: Attila Takacs; [email-masked]; 
[email-masked]<br>
      </font></dd><dd><font face="tahoma" size="2">Subject: Re: 
      draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt<br></font><br>
      </dd><dd><font face="times new roman"><br></font><br>&nbsp;
      </dd><dd><font face="times new roman">On Dec 4, 2007, at 7:33 PM, Diego 
      Caviglia wrote:<br></font><br><font face="times new roman"><br><br></font>
      </dd><dd><font color="#000080" face="arial" size="2">Hi Thomas,<br></font><br>
      </dd><dd><font color="#000080" face="arial" size="2">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      My understanding of the ID was that RSVP-TE can be used to $BAQ(Biggyback$B!)(BCFM 
      set-up, otherwise the scenario is: usage of RSVP-TE to set-up the LSP and 
      NMS (meaning everything that is not control plane) to enable to CFM for 
      the LSP.<br></font><br>
      </dd><dd><font face="times new roman"><br></font><br>&nbsp;
      </dd><dd><font face="times new roman">As I understand it, the IEEE is working 
      on set-up of CFM (and MEPs), as are some vendors I know. *)<br></font><br>
      </dd><dd><font face="times new roman">This to me seems like the right way to do 
      this.<br></font><br>
      </dd><dd><font face="times new roman"><br></font><br>&nbsp;</dd></dl><font color="#0000ff" face="arial" size="2">IEEE specified CFM and MIBs to setup CFM. 
    <br></font><br><font color="#0000ff" face="arial" size="2">Diego's summary is 
    correct: one can use an NMS or a control plane to setup the data plane. In 
    this case we propose to use GMPLS to setup the data plane: both forwarding + 
    OAM.<br></font>
    <blockquote type="cite">
      <dl><br>
        <dd><font color="#144fae" face="times new roman" size="2">From your comment 
        I see that you$BCS(Be not happy with the fact the ID is so technology 
        specific am I right?&nbsp; <br></font><br></dd></dl><font face="times new roman">&nbsp;<br></font><br><font face="times new roman">Precisely; its gluing CFM to RSVP-TE/GMPLS as a 
      transport. </font></blockquote><br><font color="#0000ff" face="arial" size="2">I 
    do not see your point with gluing. What do you mean by "as transport"? GMPLS 
    is just controlling OAM, CFM is run solely in the data 
    plane.<br></font><br><font face="times new roman">&nbsp;<br></font><br><font face="times new roman">&nbsp;<br></font>
    <blockquote type="cite">
      <dl><br>
        <dd><font color="#144fae" face="times new roman" size="2">If yes do you 
        agree with the fact that could be useful in general to use the same 
        signaling $BAT(Bession$B!)(Bto set-up the LSP and to enable the 
        CFM?<br></font><br></dd></dl><font face="times new roman">&nbsp;<br></font><br><font face="times new roman">No, I do not agree.&nbsp; Again, if CFM is to be 
      set-up e2e, let the IEEE define this. Leave GMPLS to 
    CCAMP.</font></blockquote><br><font face="times new roman">&nbsp;<br></font><br><font face="times new roman">&nbsp;<br></font><br><font color="#0000ff" face="arial" size="2">Sorry, I cannot follow.<br></font><br><font face="times new roman">&nbsp;<br></font><br><font face="times new roman">&nbsp;<br></font>
    <dl><br>
      <dd><font face="times new roman"><br></font><br>&nbsp;
      </dd><dd><font face="times new roman"><br></font><br>&nbsp;
      </dd><dd><font face="times new roman"><br></font><br>&nbsp;
      </dd><dd><font face="times new roman">--Tom<br></font><br>
      </dd><dd><font face="times new roman"><br></font><br>&nbsp;
      </dd><dd><font face="times new roman"><br></font><br><font face="times new roman"><br><br></font>&nbsp;
      </dd><dd><font color="#000080" face="arial" size="2">&nbsp;</font><font color="#144fae" face="arial" size="2">Best Regards<br></font><br><font color="#000080" face="arial" size="2"><br>
      </font></dd><dd><font color="#000080" face="arial" size="2">Diego<br>
      </font><SPAN style="width:100%;height:2px;border-bottom:1px solid rgb(212,208,200); border-top:1px solid rgb(128,128,128);background-color:black;overflow:hidden; margin:8px 0px;"></SPAN>

<font color="#000080" face="arial" size="2">      </font><div align="center"></div>
      </dd><dd><font face="tahoma" size="2">From: <a rel="nofollow" ymailto="mailto:[email-masked]" target="_blank" href="mailto:[email-masked]">[email-masked]</a> [<a rel="nofollow" ymailto="mailto:[email-masked]" target="_blank" href="mailto:[email-masked]">mailto:[email-masked]</a>] 
      On Behalf Of Thomas Nadeau<br>
      </font></dd><dd><font face="tahoma" size="2">Sent: marted$B!&(B4 dicembre 2007 11.30<br>
      </font></dd><dd><font face="tahoma" size="2">To: Attila Takacs<br>
      </font></dd><dd><font face="tahoma" size="2">Cc: <a rel="nofollow" ymailto="mailto:[email-masked]" target="_blank" href="mailto:[email-masked]">[email-masked]</a>; <a rel="nofollow" ymailto="mailto:[email-masked]" target="_blank" href="mailto:[email-masked]">[email-masked]</a><br>
      </font></dd><dd><font face="tahoma" size="2">Subject: Re: 
      draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt<br></font><br>
      </dd><dd><font face="times new roman">On Dec 4, 2007, at 1:51 PM, Attila Takacs 
      wrote:<br></font><br><font face="times new roman"><br><br><br></font>
      </dd><dd><font color="#0000ff" face="arial" size="2">Hi Thomas,<br></font><br>
      </dd><dd><font color="#0000ff" face="arial" size="2">Thank you for the 
      comments!<br></font><br>
      </dd><dd><font color="#0000ff" face="arial" size="2">Please see answers 
      inline.<br></font><br>
      </dd><dd><font color="#0000ff" face="arial" size="2">Best regards,<br>
      </font></dd><dd><font color="#0000ff" face="arial" size="2">Attila<br>
      </font><SPAN style="width:100%;height:2px;border-bottom:1px solid rgb(212,208,200); border-top:1px solid rgb(128,128,128);background-color:black;overflow:hidden; margin:8px 0px;"></SPAN>

<font color="#0000ff" face="arial" size="2">      </font><div align="center"></div>
      </dd><dd><font face="tahoma" size="2">From: Thomas Nadeau [<a rel="nofollow" ymailto="mailto:[email-masked]" target="_blank" href="mailto:[email-masked]">mailto:[email-masked]</a>] 
      <br>
      </font></dd><dd><font face="tahoma" size="2">Sent: Tuesday, December 04, 2007 2:58 PM<br>
      </font></dd><dd><font face="tahoma" size="2">To: <a rel="nofollow" ymailto="mailto:[email-masked]" target="_blank" href="mailto:[email-masked]">[email-masked]</a><br>
      </font></dd><dd><font face="tahoma" size="2">Cc: Attila Takacs; <a rel="nofollow" ymailto="mailto:[email-masked]" target="_blank" href="mailto:[email-masked]">[email-masked]</a><br>
      </font></dd><dd><font face="tahoma" size="2">Subject: 
      draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt<br></font><br>
      </dd><dd><font face="times new roman">After reading this draft, I have some 
      questions/comments.<br></font><br>
      </dd><dd><font face="times new roman">1) Overall, I am concerned that the 
      definition of a new TLV and these procedures represent <br></font><br>
      </dd><dd><font face="times new roman">what amounts to a laying violation and 
      ask that the ADs take a look at this<br></font><br>
      </dd><dd><font face="times new roman">approach closely. This is similar to the 
      now-rejected approach that was proposed<br></font><br>
      </dd><dd><font face="times new roman">in the l2vpn WG about munging CFM + 
      PWs.&nbsp; To my reading, this is essentially<br></font><br>
      </dd><dd><font face="times new roman">the same thing. If you want to run CFM, 
      run it natively over the ethernet interfaces and<br></font><br>
      </dd><dd><font face="times new roman">have no regard for the underlying 
      topology (GMPLS, PWs, etc...) otherwise you <br></font><br>
      </dd><dd><font face="times new roman">will be creating a mess for 
      implementations and interoperability. </font><font color="#0000ff" face="arial" size="2"><br></font><br></dd></dl><font color="#0000ff" face="arial" size="2">The application of the draft is exactly for what you are calling out: 
    when CFM is run natively over the Ethernet interfaces. The document focuses 
    on GELS and Ethernet LSPs. That is, to establish CFM entities for GMPLS 
    controlled Ethernet LSPs. Hence, I think there is no layer violation 
    issue.<br></font><br><font face="times new roman">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    </font>This solution specifically only works for GMPLS ethernet LSPs, 
    right?&nbsp; <br><br><font face="times new roman">What do I do if I want to 
    set up MPLS ethernet LSPs (i.e.: PWs) and do CFM over those? 
    Oh,<br></font><br><font face="times new roman">that is a different solution, 
    right?&nbsp; Then what do I do if I want to run CFM over some new type 
    of<br></font><br><font face="times new roman">ethernet LSP in the future? 
    More protocol hacks?&nbsp; The point is to use CFM over an ethernet 
    interface<br></font><br><font face="times new roman">without the underlying 
    layers knowing. This is good networking architecture design, that 
    simplifies<br></font><br><font face="times new roman">implementations and 
    makes them more robust, as well as makes using them operationally 
    much<br></font><br><font face="times new roman">easier. <br></font>
    <blockquote type="cite">
      <dl><br>
        <dd><font face="times new roman">2) The introductory sections in this 
        draft give a lot of discussion about fast fault detection. 
        I<br></font><br>
        </dd><dd><font face="times new roman">am puzzled by this given that GMPLS 
        networks tend to run over quickly self-healing<br></font><br>
        </dd><dd><font face="times new roman">optical infrastructures. Is it 
        therefore truly necessary to motivate this work by<br></font><br>
        </dd><dd><font face="times new roman">requiring fast 
      CFMs?<br></font><br></dd></dl><font color="#0000ff" face="arial" size="2">It is 
      right that frequent CCMs are not required if the layers below Ethernet 
      handle protection. However, the ID focuses on Ethernet LSPs where Ethernet 
      is not just a single hop above a transport LSP. In this case Ethernet 
      layer (for clarity GELS) may provide protection for Ethernet LSPs. In any 
      case,&nbsp; the whole point of the ID is to allow for the appropriate 
      configuration of CFM for Ethernet LSPs with GMPLS.<br></font>
      <dl><br>
        <dd><font face="times new roman">3) This document does not cover E-LMI. 
        Why not?<br></font><br></dd></dl><font color="#0000ff" face="arial" size="2">E-LMI is run over the MEF UNI. The ID focuses on Ethernet LSPs 
      within a network.<br></font>
      <dl><br>
        <dd><font face="times new roman" size="1">For the purposes of this 
        document, we only discuss Ethernet OAM<br></font><br>
        </dd><dd><font face="helvetica" size="1">&nbsp;&nbsp; [IEEE-CFM] aspects that are 
        relevant for the connectivity monitoring<br></font><br>
        </dd><dd><font face="helvetica" size="1">&nbsp;&nbsp; of bidirectional 
        point-to-point PBB-TE connections.&nbsp; <br></font><br>
        </dd><dd><font face="helvetica" size="1">4) Is this the right place to define 
        this document or should this be done in 
      GELS?<br></font><br></dd></dl><font color="#0000ff" face="arial" size="2">Well, 
      GELS is done in CCAMP...this seems to be the right place.<br></font>
      <dl><br>
        <dd><font face="helvetica" size="1">5)&nbsp;&nbsp; In section 2 you make the 
        following statement:<br></font><br>
        </dd><dd><font face="helvetica" size="1">2.&nbsp; GMPLS RSVP-TE 
        Extensions<br></font><br>
        </dd><dd><font face="helvetica" size="1">&nbsp;&nbsp;&nbsp; To simplify the 
        configuration of connectivity monitoring, when an<br></font><br>
        </dd><dd><font face="helvetica" size="1">&nbsp;&nbsp; Ethernet LSP is signalled 
        the associated MEPs should be automatically<br></font><br>
        </dd><dd><font face="helvetica" size="1">&nbsp;&nbsp;&nbsp; established.&nbsp; 
        Further more, GMPLS signalling should be able to<br></font><br>
        </dd><dd><font face="helvetica" size="1">&nbsp; enable/disable connectivity 
        monitoring of a particular Ethernet LSP.<br></font><br>
        </dd><dd><font face="helvetica" size="1">To my point in #1 above, you should use 
        the native CFM functionality over the ethernet interface and 
        signal<br></font><br>
        </dd><dd><font face="helvetica" size="1">those capabilities to the bridges at 
        both ends using the IEEE CFM signaling procedures (when and if 
        they<br></font><br>
        </dd><dd><font face="helvetica" size="1">are created).&nbsp; If you want to test 
        the underlying GMPLS LSP(s), then you should use some<br></font><br>
        </dd><dd><font face="helvetica" size="1">other mechanism defined for that layer 
        such as the work stated in </font><font face="helvetica" size="2">draft-ali-ccamp-gmpls-LSP-ping-traceroute-00.txt<br></font><br></dd></dl><font color="#0000ff" face="arial" size="2">See the note to your point #1. There is no 
      relation to the gmpls-LSP-ping draft. </font></blockquote><br><font face="times new roman">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    </font>The point I am making is that perhaps it should.<br><br><font face="times new roman">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    </font>--Tom<br><br><font face="times new roman">&nbsp;<br></font></blockquote> 
  <p> -------------------------------------<br>Wataru Imajuku, 
  Ph.D.@NTT Network Innovation Labs<br>TEL: +81-46-859-4315<br>FAX: 
  +81-46-859-5541<br></p></blockquote></div><br></div></div><br>
      <hr size=1>Looking for last minute shopping deals? <a href="http://us.rd.yahoo.com/evt=51734/*http://tools.search.yahoo.com/newsearch/category.php?category=shopping"> 
Find them fast with Yahoo! Search.</a></body></html>
--0-913381410-1196953083=:79554--

Delivery-date: Thu, 06 Dec 2007 10:35:46 +0000
Content-class: urn:content-classes:message
Subject: RE: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt
Date: Thu, 6 Dec 2007 11:33:56 +0100
From: "MEURIC Julien RD-CORE-LAN" <[email-masked]>
To: "Thomas Nadeau" <[email-masked]>
Cc: <[email-masked]>

Hi Tom.

Good question, but I guess this can already find some pieces of answers. =
Quoting the BFD base draft: "For example, an OSPF implementation may =
request a BFD session to be established to a neighbor discovered using =
the OSPF Hello protocol."

Personally, I believe it is useful to have a signaling mechanism to =
configure OAM in a distributed environment. Considering a GMPLS context, =
RSVP-TE is just there between end points. What is more, when =
establishing an LSP, I am concerned with recovery aspects (already there =
thanks to the Protection object) and obviously with the OAM allowing =
this recovery to happen (and OAM is not implicit in case of =
packet-switched connection).

Regards,

Julien

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On =
Behalf Of Thomas Nadeau

	What do we do for the other signaling protocols outside of CCAMP?
Do we now extend BGP, RSVP-TE (for MPLS), and LDP to control OAM there
as well?

	--Tom

=09
> All,
>
> I'm normally a bit careful with models "layer networks" that seems
> to be a rather cumbersome way of explaining the obvious; however
> in this case when it is used demonstrate that no layer violation
> is at hand I is inclined to accept that result.
>
> I also agree with Dan that it seems to be a good idea to use
> RSVP-TE to provision OAM functionality is a good idea.
>
> With that it we should just go ahead and accept this as a
> ccamp work item.
>
> /Loa
>
> Dan Li wrote:
>> MessageHi,
>>
>> I think there is a misunderstanding with respect to the objective =20
>> of this draft.
>>
>> As I read this draft, it describes how to extend the RSVP protocol
>
> to support the configuration/enable the OAM function of Ethernet LSP,
>
> which I think is a good thing to do, it is not saying to use signaling
>
> protocol to do the OAM work. But anyway, it may be necessary to =20
> clarify
>
> the objective at the beginning of this draft.
>>
>> Regards,
>>
>> Dan
>>
>>
>>  ----- Original Message -----
>>  From: Diego Caviglia
>>  To: [email-masked] ; Attila Takacs ; [email-masked]
>>  Cc: [email-masked]
>>  Sent: Thursday, December 06, 2007 12:27 AM
>>  Subject: RE: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt
>>
>>
>>  Hi Neil,
>>
>>             Yes I totally agree with your analysis.
>>
>>
>>
>>  The is not going to redefine or reinvent the OAM that, as Thomas =20
>> as pointed out, is done by IEEE, the ID just specify how to use a =20
>> control plane mechanism (GMPLS) set-up at the same time data plane =20
>> circuit and the related OAM.
>>
>>
>>
>>  Frankly specking I don't see any layer violation here.
>>
>>
>>
>>  BR
>>
>>
>>
>>  Diego
>>
>>
>>
>>
>> =
-------------------------------------------------------------------------=
-----
>>
>>  From: [email-masked] [mailto:[email-masked]]
>>  Sent: marted=EC 4 dicembre 2007 22.55
>>  To: Attila Takacs; [email-masked]; Diego Caviglia
>>  Cc: [email-masked]
>>  Subject: RE: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt
>>
>>
>>
>>  I'm puzzled.  I read the draft and thought it was excellent.  It =20
>> is addressing an important operational issue, ie a critical =20
>> operational OAM requirement is to ensure that whatever mechanism =20
>> (MP or CP) is used to set-up/tear-down a connection (so this only =20
>> applies to co-cs or co-ps modes....the cl-ps mode does not have =20
>> connections of course) is harmonised to the activation/deactivation =20
>> of the OAM.....specifically a CV/CC flow.   If we don't ensure this =20
>> then there will be obvious operational problems.  This is =20
>> essentially what the draft is about.
>>
>>
>>
>>  Further, GMPLS is a generic OOB CP technique.....it is not a =20
>> specific layer network technology per se (but it is specific in =20
>> it's choice of signalling and routing components).  So one can =20
>> apply a largely similar (GMPLS) CP technique to all co-cs mode =20
>> technologies (whether they are partitioning a space, freq or time =20
>> resource - see Note) and co-ps mode technologies (which only =20
>> applies to partitioning a time resource - see Note) on the =20
>> assumption that the technology is correctly architected in the DP =20
>> for the mode considered.  It's pretty hard not to correctly =20
>> architect the co-cs mode, but it's quite easy to incorrectly =20
>> architect the co-ps mode, eg one can't violate the rules of a =20
>> connection in the co-cs mode but one can in the co-ps mode.
>>
>>
>>
>>  Note - When we partition a time resource in regular time-slices we =20
>> create a co-cs mode layer network.  When we partition a time =20
>> resource in irregular time-slices we create a co-ps mode layer =20
>> network.  More information on labelling and resource partitioning =20
>> can be found in the work on unified modelling (of networks) in G.800.
>>
>>
>>
>>  regards, Neil
>>
>>    -----Original Message-----
>>    From: [email-masked] [mailto:[email-masked]] =20
>> On Behalf Of Attila Takacs
>>    Sent: 05 December 2007 02:03
>>    To: Thomas Nadeau; Diego Caviglia
>>    Cc: [email-masked]
>>    Subject: RE: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt
>>
>>    Hi Tom,
>>
>>    please see inline.
>>
>>    Best regards,
>>
>>    Attila
>>
>>
>>
>>
>> =
-------------------------------------------------------------------------=
-
>>
>>      From: Thomas Nadeau [mailto:[email-masked]]
>>      Sent: Wednesday, December 05, 2007 2:19 AM
>>      To: Diego Caviglia
>>      Cc: Attila Takacs; [email-masked]; [email-masked]
>>      Subject: Re: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt
>>
>>
>>
>>      On Dec 4, 2007, at 7:33 PM, Diego Caviglia wrote:
>>
>>
>>
>>
>>
>>      Hi Thomas,
>>
>>                       My understanding of the ID was that RSVP-TE =20
>> can be used to 'piggyback' CFM set-up, otherwise the scenario is: =20
>> usage of RSVP-TE to set-up the LSP and NMS (meaning everything that =20
>> is not control plane) to enable to CFM for the LSP.
>>
>>
>>
>>      As I understand it, the IEEE is working on set-up of CFM (and =20
>> MEPs), as are some vendors I know. *)
>>
>>      This to me seems like the right way to do this.
>>
>>
>>
>>    IEEE specified CFM and MIBs to setup CFM.
>>
>>    Diego's summary is correct: one can use an NMS or a control =20
>> plane to setup the data plane. In this case we propose to use GMPLS =20
>> to setup the data plane: both forwarding + OAM.
>>
>>        From your comment I see that you're not happy with the fact =20
>> the ID is so technology specific am I right?
>>
>>
>>
>>      Precisely; its gluing CFM to RSVP-TE/GMPLS as a transport.
>>
>>    I do not see your point with gluing. What do you mean by "as =20
>> transport"? GMPLS is just controlling OAM, CFM is run solely in the =20
>> data plane.
>>
>>
>>
>>
>>
>>        If yes do you agree with the fact that could be useful in =20
>> general to use the same signaling 'session' to set-up the LSP and =20
>> to enable the CFM?
>>
>>
>>
>>      No, I do not agree.  Again, if CFM is to be set-up e2e, let =20
>> the IEEE define this. Leave GMPLS to CCAMP.
>>
>>
>>
>>
>>
>>    Sorry, I cannot follow.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>      --Tom
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>       Best Regards
>>
>>
>>      Diego
>>
>>
>> =
-------------------------------------------------------------------------=
-
>>
>>      From: [email-masked] [mailto:owner-=20
>> [email-masked]] On Behalf Of Thomas Nadeau
>>      Sent: marted=EC 4 dicembre 2007 11.30
>>      To: Attila Takacs
>>      Cc: [email-masked]; [email-masked]
>>      Subject: Re: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt
>>
>>      On Dec 4, 2007, at 1:51 PM, Attila Takacs wrote:
>>
>>
>>
>>
>>
>>
>>      Hi Thomas,
>>
>>      Thank you for the comments!
>>
>>      Please see answers inline.
>>
>>      Best regards,
>>      Attila
>>
>>
>> =
------------------------------------------------------------------------
>>
>>        From: Thomas Nadeau [mailto:[email-masked]]
>>        Sent: Tuesday, December 04, 2007 2:58 PM
>>        To: [email-masked]
>>        Cc: Attila Takacs; [email-masked]
>>        Subject: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt
>>
>>        After reading this draft, I have some questions/comments.
>>
>>        1) Overall, I am concerned that the definition of a new TLV =20
>> and these procedures represent
>>
>>        what amounts to a laying violation and ask that the ADs take =20
>> a look at this
>>
>>        approach closely. This is similar to the now-rejected =20
>> approach that was proposed
>>
>>        in the l2vpn WG about munging CFM + PWs.  To my reading, =20
>> this is essentially
>>
>>        the same thing. If you want to run CFM, run it natively over =20
>> the ethernet interfaces and
>>
>>        have no regard for the underlying topology (GMPLS, PWs, =20
>> etc...) otherwise you
>>
>>        will be creating a mess for implementations and =20
>> interoperability.
>>
>>      The application of the draft is exactly for what you are =20
>> calling out: when CFM is run natively over the Ethernet interfaces. =20
>> The document focuses on GELS and Ethernet LSPs. That is, to =20
>> establish CFM entities for GMPLS controlled Ethernet LSPs. Hence, I =20
>> think there is no layer violation issue.
>>
>>                This solution specifically only works for GMPLS =20
>> ethernet LSPs, right?
>>
>>      What do I do if I want to set up MPLS ethernet LSPs (i.e.: =20
>> PWs) and do CFM over those? Oh,
>>
>>      that is a different solution, right?  Then what do I do if I =20
>> want to run CFM over some new type of
>>
>>      ethernet LSP in the future? More protocol hacks?  The point is =20
>> to use CFM over an ethernet interface
>>
>>      without the underlying layers knowing. This is good networking =20
>> architecture design, that simplifies
>>
>>      implementations and makes them more robust, as well as makes =20
>> using them operationally much
>>
>>      easier.
>>
>>          2) The introductory sections in this draft give a lot of =20
>> discussion about fast fault detection. I
>>
>>          am puzzled by this given that GMPLS networks tend to run =20
>> over quickly self-healing
>>
>>          optical infrastructures. Is it therefore truly necessary =20
>> to motivate this work by
>>
>>          requiring fast CFMs?
>>
>>        It is right that frequent CCMs are not required if the =20
>> layers below Ethernet handle protection. However, the ID focuses on =20
>> Ethernet LSPs where Ethernet is not just a single hop above a =20
>> transport LSP. In this case Ethernet layer (for clarity GELS) may =20
>> provide protection for Ethernet LSPs. In any case,  the whole point =20
>> of the ID is to allow for the appropriate configuration of CFM for =20
>> Ethernet LSPs with GMPLS.
>>
>>          3) This document does not cover E-LMI. Why not?
>>
>>        E-LMI is run over the MEF UNI. The ID focuses on Ethernet =20
>> LSPs within a network.
>>
>>          For the purposes of this document, we only discuss =20
>> Ethernet OAM
>>
>>             [IEEE-CFM] aspects that are relevant for the =20
>> connectivity monitoring
>>
>>             of bidirectional point-to-point PBB-TE connections.
>>
>>          4) Is this the right place to define this document or =20
>> should this be done in GELS?
>>
>>        Well, GELS is done in CCAMP...this seems to be the right =20
>> place.
>>
>>          5)   In section 2 you make the following statement:
>>
>>          2.  GMPLS RSVP-TE Extensions
>>
>>              To simplify the configuration of connectivity =20
>> monitoring, when an
>>
>>             Ethernet LSP is signalled the associated MEPs should be =20
>> automatically
>>
>>              established.  Further more, GMPLS signalling should be =20
>> able to
>>
>>            enable/disable connectivity monitoring of a particular =20
>> Ethernet LSP.
>>
>>          To my point in #1 above, you should use the native CFM =20
>> functionality over the ethernet interface and signal
>>
>>          those capabilities to the bridges at both ends using the =20
>> IEEE CFM signaling procedures (when and if they
>>
>>          are created).  If you want to test the underlying GMPLS =20
>> LSP(s), then you should use some
>>
>>          other mechanism defined for that layer such as the work =20
>> stated in draft-ali-ccamp-gmpls-LSP-ping-traceroute-00.txt
>>
>>        See the note to your point #1. There is no relation to the =20
>> gmpls-LSP-ping draft.
>>
>>                The point I am making is that perhaps it should.
>>
>>                --Tom
>>
>>
>>
>
>
> --=20
> 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]
>
> This email was Anti Virus checked by Astaro Security Gateway. =
http://www.astaro.com

Delivery-date: Thu, 06 Dec 2007 09:58:43 +0000
Content-class: urn:content-classes:message
Subject: RE: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt
Date: Thu, 6 Dec 2007 09:55:04 -0000
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>

Hi Tom,

You asked 05 December 2007 22:12
> 	What do we do for the other signaling protocols outside
> of CCAMP? Do we now extend BGP, RSVP-TE (for MPLS), and LDP=20
> to control OAM there as well?
>=20
> 	--Tom

The principle I gave stands....this behaviour is required irrespective =
of what mechanism (CP signalling or MP provisioning) is responsible for =
setting-up/tearing-down a *connection*.  This is not a new requirement. =
I've mentioned this requirement several times in posts to various WGs =
over the years and you will find this requirement mentioned in Y.1711.  =
We also stated this as a requirement in the now expired draft =
'draft-willis-pwe3-requirements-00.txt (which can still be found at =
http://www2.tools.ietf.org/html/draft-willis-pwe3-requirements-00) when =
attempting to provide guidance to PWE3 on OAM requirements back in 2004. =
In section 1.2 therein we gave some background wrt to the different OAM =
required for the 3 network modes of cl-ps, co-ps and co-cs (as the OAM =
required is not the same in all 3 cases)....here is the relevant extract =
wrt to the activation/deactivation topic of this thread:

".....the OAM activation/deactivation must be harmonized with the =
set-up/tear-down of the path.  Failure to harmonize OAM =
activation/deactivation with PW set-up/tear-down will lead to either:
- lack of OAM protection when the PW is set-up, or false alarms
  when the PW is torn-down;  or
- OAM being activated prior to PW set-up and significant problems due
  to operator error."

You'll note I highlighted the word *connection* above....this is rather =
important.  One can't activate/deactivate OAM in concert with connection =
set-up/tear-down if one does not have a connection, eg cl-ps mode.  =
There are also no problems when dealing with the co-cs mode as this is =
forced to respect the requirements of a connection (which, to summarise =
are: (i) single source (ii) no re-ordering of traffic units).  However, =
the LDP form of MPLS does not respect the requirements of a connection =
as it creates a mp2p merging construct.....PHP has a similar merging =
behaviour on the last hop on an LSP. So the activation/deactivation of =
OAM in concert with such constructs has no meaning.....indeed, one can't =
even say we have a proper layer network here, and this is not simply due =
to violating the rules of a connection but results from the fact that an =
MPLS traffic unit does not provide consistent characteristic =
information, eg the label field can take on at least 4 different =
semantics (and this list is still growing, eg fat PWs). If not obvious =
what the problem is here, if traffic gets misdirected then the receiving =
node could misinterpret the meaning of the label. =20

So, we can't apply the requirement MPLS LDP/PHP networks.....these can =
only use 'on-demand' OAM mechanisms.....just the nature of the beast.=20

However, when we have a co-cs or co-ps mode network that does respect =
the requirements of a connection then it makes a huge amount of =
operational sense to make sure one activates/deactivates the OAM in =
conjunction with the connection set-up/tear-down.

And this is not simply a matter of 'good housekeeping' for the service =
provider, including things like the ability to provide a =
protection-switching capability, there is a security issue =
here......which is especially germane in the case of a co-ps mode =
technology based on label-swapping.  That is, if one has a defect that =
causes misdirected traffic it is important to be able to proactively =
detect such a case and take appropriate action, eg squelch the traffic, =
in order to protect the integrity of the affected client traffic.

This issue is not a problem for networks that have network unique and =
non-swapped labelling, ie all cl-ps mode technologies and PBB-TE in the =
co-ps mode, ie these network are inherently robust to misconnectivity =
defects without any OAM at all (since each traffic unit essentially =
carries it own CV function due to presence of the SA).  However, in the =
case of PBB-TE we still require the OAM activation/deactivation in =
concert with the connection set-up/tear-down as we need to distinguish =
the cases of 'quiescent client traffic' from 'simple break'.  Moreover, =
as I already noted, we also need the OAM for protection-switching =
requirements.

regards, Neil=20
>=20
> =09
> > All,
> >
> > I'm normally a bit careful with models "layer networks"
> that seems to
> > be a rather cumbersome way of explaining the obvious;
> however in this
> > case when it is used demonstrate that no layer violation is
> at hand I
> > is inclined to accept that result.
> >
> > I also agree with Dan that it seems to be a good idea to
> use RSVP-TE
> > to provision OAM functionality is a good idea.
> >
> > With that it we should just go ahead and accept this as a
> ccamp work
> > item.
> >
> > /Loa
> >
> > Dan Li wrote:
> >> MessageHi,
> >>
> >> I think there is a misunderstanding with respect to the objective=20
> >> of this draft.
> >>
> >> As I read this draft, it describes how to extend the RSVP protocol
> >
> > to support the configuration/enable the OAM function of
> Ethernet LSP,
> >
> > which I think is a good thing to do, it is not saying to
> use signaling
> >
> > protocol to do the OAM work. But anyway, it may be necessary to=20
> > clarify
> >
> > the objective at the beginning of this draft.
> >>
> >> Regards,
> >>
> >> Dan
> >>
> >>
> >>  ----- Original Message -----
> >>  From: Diego Caviglia
> >>  To: [email-masked] ; Attila Takacs ;
> [email-masked]
> >>  Cc: [email-masked]
> >>  Sent: Thursday, December 06, 2007 12:27 AM
> >>  Subject: RE: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt
> >>
> >>
> >>  Hi Neil,
> >>
> >>             Yes I totally agree with your analysis.
> >>
> >>
> >>
> >>  The is not going to redefine or reinvent the OAM that, as Thomas=20
> >> as pointed out, is done by IEEE, the ID just specify how to use a
> >> control plane mechanism (GMPLS) set-up at the same time=20
> data plane
> >> circuit and the related OAM.
> >>
> >>
> >>
> >>  Frankly specking I don't see any layer violation here.
> >>
> >>
> >>
> >>  BR
> >>
> >>
> >>
> >>  Diego
> >>
> >>
> >>
> >>
> >>=20
> ---------------------------------------------------------------------
> >> ---------
> >>
> >>  From: [email-masked] [mailto:[email-masked]]
> >>  Sent: marted=EC 4 dicembre 2007 22.55
> >>  To: Attila Takacs; [email-masked]; Diego Caviglia
> >>  Cc: [email-masked]
> >>  Subject: RE: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt
> >>
> >>
> >>
> >>  I'm puzzled.  I read the draft and thought it was excellent.  It=20
> >> is addressing an important operational issue, ie a critical
> >> operational OAM requirement is to ensure that whatever mechanism =20
> >> (MP or CP) is used to set-up/tear-down a connection (so this only =20
> >> applies to co-cs or co-ps modes....the cl-ps mode does not have =20
> >> connections of course) is harmonised to the=20
> activation/deactivation
> >> of the OAM.....specifically a CV/CC flow.   If we don't=20
> ensure this
> >> then there will be obvious operational problems.  This is
> >> essentially what the draft is about.
> >>
> >>
> >>
> >>  Further, GMPLS is a generic OOB CP technique.....it is not a=20
> >> specific layer network technology per se (but it is specific in
> >> it's choice of signalling and routing components).  So one can =20
> >> apply a largely similar (GMPLS) CP technique to all co-cs mode =20
> >> technologies (whether they are partitioning a space, freq or time =20
> >> resource - see Note) and co-ps mode technologies (which only =20
> >> applies to partitioning a time resource - see Note) on the =20
> >> assumption that the technology is correctly architected in the DP =20
> >> for the mode considered.  It's pretty hard not to correctly =20
> >> architect the co-cs mode, but it's quite easy to incorrectly =20
> >> architect the co-ps mode, eg one can't violate the rules of a =20
> >> connection in the co-cs mode but one can in the co-ps mode.
> >>
> >>
> >>
> >>  Note - When we partition a time resource in regular time-slices we =

> >> create a co-cs mode layer network.  When we partition a time
> >> resource in irregular time-slices we create a co-ps mode layer =20
> >> network.  More information on labelling and resource partitioning =20
> >> can be found in the work on unified modelling (of=20
> networks) in G.800.
> >>
> >>
> >>
> >>  regards, Neil
> >>
> >>    -----Original Message-----
> >>    From: [email-masked] [mailto:[email-masked]] =

> >> On Behalf Of Attila Takacs
> >>    Sent: 05 December 2007 02:03
> >>    To: Thomas Nadeau; Diego Caviglia
> >>    Cc: [email-masked]
> >>    Subject: RE: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt
> >>
> >>    Hi Tom,
> >>
> >>    please see inline.
> >>
> >>    Best regards,
> >>
> >>    Attila
> >>
> >>
> >>
> >>
> >>=20
> ---------------------------------------------------------------------
> >> -----
> >>
> >>      From: Thomas Nadeau [mailto:[email-masked]]
> >>      Sent: Wednesday, December 05, 2007 2:19 AM
> >>      To: Diego Caviglia
> >>      Cc: Attila Takacs; [email-masked];
> [email-masked]
> >>      Subject: Re: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt
> >>
> >>
> >>
> >>      On Dec 4, 2007, at 7:33 PM, Diego Caviglia wrote:
> >>
> >>
> >>
> >>
> >>
> >>      Hi Thomas,
> >>
> >>                       My understanding of the ID was that RSVP-TE=20
> >> can be used to 'piggyback' CFM set-up, otherwise the scenario is:
> >> usage of RSVP-TE to set-up the LSP and NMS (meaning=20
> everything that
> >> is not control plane) to enable to CFM for the LSP.
> >>
> >>
> >>
> >>      As I understand it, the IEEE is working on set-up of CFM (and=20
> >> MEPs), as are some vendors I know. *)
> >>
> >>      This to me seems like the right way to do this.
> >>
> >>
> >>
> >>    IEEE specified CFM and MIBs to setup CFM.
> >>
> >>    Diego's summary is correct: one can use an NMS or a control=20
> >> plane to setup the data plane. In this case we propose to
> use GMPLS
> >> to setup the data plane: both forwarding + OAM.
> >>
> >>        From your comment I see that you're not happy with the fact=20
> >> the ID is so technology specific am I right?
> >>
> >>
> >>
> >>      Precisely; its gluing CFM to RSVP-TE/GMPLS as a transport.
> >>
> >>    I do not see your point with gluing. What do you mean by "as=20
> >> transport"? GMPLS is just controlling OAM, CFM is run
> solely in the
> >> data plane.
> >>
> >>
> >>
> >>
> >>
> >>        If yes do you agree with the fact that could be useful in=20
> >> general to use the same signaling 'session' to set-up the LSP and
> >> to enable the CFM?
> >>
> >>
> >>
> >>      No, I do not agree.  Again, if CFM is to be set-up e2e, let=20
> >> the IEEE define this. Leave GMPLS to CCAMP.
> >>
> >>
> >>
> >>
> >>
> >>    Sorry, I cannot follow.
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>      --Tom
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>       Best Regards
> >>
> >>
> >>      Diego
> >>
> >>
> >>=20
> ---------------------------------------------------------------------
> >> -----
> >>
> >>      From: [email-masked] [mailto:owner-=20
> >> [email-masked]] On Behalf Of Thomas Nadeau
> >>      Sent: marted=EC 4 dicembre 2007 11.30
> >>      To: Attila Takacs
> >>      Cc: [email-masked]; [email-masked]
> >>      Subject: Re: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt
> >>
> >>      On Dec 4, 2007, at 1:51 PM, Attila Takacs wrote:
> >>
> >>
> >>
> >>
> >>
> >>
> >>      Hi Thomas,
> >>
> >>      Thank you for the comments!
> >>
> >>      Please see answers inline.
> >>
> >>      Best regards,
> >>      Attila
> >>
> >>
> >>=20
> ---------------------------------------------------------------------
> >> ---
> >>
> >>        From: Thomas Nadeau [mailto:[email-masked]]
> >>        Sent: Tuesday, December 04, 2007 2:58 PM
> >>        To: [email-masked]
> >>        Cc: Attila Takacs; [email-masked]
> >>        Subject: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt
> >>
> >>        After reading this draft, I have some questions/comments.
> >>
> >>        1) Overall, I am concerned that the definition of a new TLV=20
> >> and these procedures represent
> >>
> >>        what amounts to a laying violation and ask that the ADs take =

> >> a look at this
> >>
> >>        approach closely. This is similar to the now-rejected=20
> >> approach that was proposed
> >>
> >>        in the l2vpn WG about munging CFM + PWs.  To my reading,=20
> >> this is essentially
> >>
> >>        the same thing. If you want to run CFM, run it natively over =

> >> the ethernet interfaces and
> >>
> >>        have no regard for the underlying topology (GMPLS, PWs,
> >> etc...) otherwise you
> >>
> >>        will be creating a mess for implementations and=20
> >> interoperability.
> >>
> >>      The application of the draft is exactly for what you are=20
> >> calling out: when CFM is run natively over the Ethernet
> interfaces.
> >> The document focuses on GELS and Ethernet LSPs. That is, to
> >> establish CFM entities for GMPLS controlled Ethernet LSPs.=20
> Hence, I
> >> think there is no layer violation issue.
> >>
> >>                This solution specifically only works for GMPLS=20
> >> ethernet LSPs, right?
> >>
> >>      What do I do if I want to set up MPLS ethernet LSPs (i.e.:
> >> PWs) and do CFM over those? Oh,
> >>
> >>      that is a different solution, right?  Then what do I do if I=20
> >> want to run CFM over some new type of
> >>
> >>      ethernet LSP in the future? More protocol hacks?  The point is =

> >> to use CFM over an ethernet interface
> >>
> >>      without the underlying layers knowing. This is good networking =

> >> architecture design, that simplifies
> >>
> >>      implementations and makes them more robust, as well as makes=20
> >> using them operationally much
> >>
> >>      easier.
> >>
> >>          2) The introductory sections in this draft give a lot of=20
> >> discussion about fast fault detection. I
> >>
> >>          am puzzled by this given that GMPLS networks tend to run=20
> >> over quickly self-healing
> >>
> >>          optical infrastructures. Is it therefore truly necessary=20
> >> to motivate this work by
> >>
> >>          requiring fast CFMs?
> >>
> >>        It is right that frequent CCMs are not required if the=20
> >> layers below Ethernet handle protection. However, the ID
> focuses on
> >> Ethernet LSPs where Ethernet is not just a single hop above a
> >> transport LSP. In this case Ethernet layer (for clarity GELS) may =20
> >> provide protection for Ethernet LSPs. In any case,  the=20
> whole point
> >> of the ID is to allow for the appropriate configuration of
> CFM for
> >> Ethernet LSPs with GMPLS.
> >>
> >>          3) This document does not cover E-LMI. Why not?
> >>
> >>        E-LMI is run over the MEF UNI. The ID focuses on Ethernet=20
> >> LSPs within a network.
> >>
> >>          For the purposes of this document, we only discuss=20
> >> Ethernet OAM
> >>
> >>             [IEEE-CFM] aspects that are relevant for the=20
> >> connectivity monitoring
> >>
> >>             of bidirectional point-to-point PBB-TE connections.
> >>
> >>          4) Is this the right place to define this document or=20
> >> should this be done in GELS?
> >>
> >>        Well, GELS is done in CCAMP...this seems to be the right=20
> >> place.
> >>
> >>          5)   In section 2 you make the following statement:
> >>
> >>          2.  GMPLS RSVP-TE Extensions
> >>
> >>              To simplify the configuration of connectivity=20
> >> monitoring, when an
> >>
> >>             Ethernet LSP is signalled the associated MEPs should be =

> >> automatically
> >>
> >>              established.  Further more, GMPLS signalling should be =

> >> able to
> >>
> >>            enable/disable connectivity monitoring of a particular=20
> >> Ethernet LSP.
> >>
> >>          To my point in #1 above, you should use the native CFM=20
> >> functionality over the ethernet interface and signal
> >>
> >>          those capabilities to the bridges at both ends using the=20
> >> IEEE CFM signaling procedures (when and if they
> >>
> >>          are created).  If you want to test the underlying GMPLS=20
> >> LSP(s), then you should use some
> >>
> >>          other mechanism defined for that layer such as the work=20
> >> stated in draft-ali-ccamp-gmpls-LSP-ping-traceroute-00.txt
> >>
> >>        See the note to your point #1. There is no relation to the=20
> >> gmpls-LSP-ping draft.
> >>
> >>                The point I am making is that perhaps it should.
> >>
> >>                --Tom
> >>
> >>
> >>
> >
> >
> > --
> > 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]
> >
> > This email was Anti Virus checked by Astaro Security Gateway.
> > http://www.astaro.com
> >
> >
>=20
>=20

Delivery-date: Thu, 06 Dec 2007 09:46:43 +0000
Date: Thu, 06 Dec 2007 09:43:28 +0000
From: Adrian Farrel <[email-masked]>
Subject: GELS: what happened alternatively what will happen
To: Loa Andersson <[email-masked]>, ccamp <[email-masked]>
Reply-to: Adrian Farrel <[email-masked]>

Hi Loa,

Deborah and I want to move the Ethernet I-Ds forward (into the WG) as 
quickly as possible, but we also need to organise our thoughts.

Can you give us a couple of days to work out what we want to do with the 
drafts, and in what order?

In the mean time, a reminder to the whole WG that they should review and 
comment on the list. Questions and issues are welcomed. Suggested text is 
best.

Thanks,
Adrian

----- Original Message ----- 
From: "Loa Andersson" <[email-masked]>
To: "ccamp" <[email-masked]>
Sent: Thursday, December 06, 2007 2:28 AM
Subject: what happened alternatively what will happen

> Adrian and Deborah,
>
> yesterday a set of IDs on GMPLS control of Ethernet were presented;
> given that I remember correctly the author of the requirement draft
> said they think that the draft will be ready to become a working
> group document after next IETF meeting.
>
> The authors of the architecture draft for GMPLS controlled Ethernet
> and the protocol extensions for control of PBT-TE networks requested
> that their draft should be accepted as working group documents.
>
> No sense of the room were taken or "take it to the list" statement.
>
> What's the plan?
>
> /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]
>
> This email was Anti Virus checked by Astaro Security Gateway. 
> http://www.astaro.com
>
>
> 

Delivery-date: Thu, 06 Dec 2007 03:08:33 +0000
Content-class: urn:content-classes:message
Subject: RE: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt
Date: Thu, 6 Dec 2007 04:07:37 +0100
From: "Attila Takacs" <[email-masked]>
To: "Wataru Imajuku" <[email-masked]>
Cc: <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C837B5.27F0AC40
Content-Type: text/plain;
	charset="ISO-2022-JP"
Content-Transfer-Encoding: 7bit

Hi Wataru,
 
Just adding to Adrian's points...
 
I think it is useful to separate A and M bits. When the LSP is put in administratively down, e.g.,  to avoid it is carrying traffic for any reason, it would be still useful to run data plane OAM so one knows the data plane is in tact when the LSP is put back operational. That is,  A=1, M=0. On the other hand, e.g., in the case of planed maintenance, one might want to turn data plane OAM off as well, having A=1, M=1.
 
Regarding the I bit, I think even if GMPLS alarm communication is disabled, the actual monitoring of data plane connectivity is needed, again to have the up to date status of the data plane.
 
In summary, I think having a separate M bit is useful, and accounts for flexibility.
 
Best regards,
Attila

________________________________

	From: Wataru Imajuku [mailto:[email-masked]] 
	Sent: Wednesday, December 05, 2007 9:53 PM
	To: Attila Takacs
	Cc: [email-masked]
	Subject: RE: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt

	Hi, Attila
	
	 I understand this proposal automates manual configuration to set CFM interval in data plane.
	 Control of CFM interval is new issue which GMPLS signaling mechanism has not covered.
	 Although you outline Ethernet OAM functionality in section 2, I think it is better to describe what is difference and what is common in OAM functionality compared to circuit switched technologies 
	which GMPLS has been covered.
	
	 On the other hand, I could not understand why do you need M bit in Admin Status Object.
	 Why do not use A=1 ?
	 Is the objective of M bit to stop sending CCM temporally ?
	
	Best Regards
	Wataru
	
	At 04:37 07/12/06, Attila Takacs wrote:

		"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"> 
		Hi all,
		 
		Neil's and Dan's summary are exact. Thanks for your comments!
		 
		Maybe the title of the ID caused the misunderstanding, it would say more if it would read: "GMPLS RSVP-TE Extensions to *Control* Ethernet OAM".
		Nevertheless, when updating the ID we will clarify our point even more.
		 
		Best regards,
		Attila

________________________________

			From: Dan Li [mailto:[email-masked]] 
			
			Sent: Wednesday, December 05, 2007 6:01 PM
			
			To: Diego Caviglia; [email-masked]; Attila Takacs; [email-masked]
			
			Cc: [email-masked]
			
			Subject: Re: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt

			Hi,

			I think there is a misunderstanding with respect to the objective of this draft. 

			As I read this draft, it describes how to extend the RSVP protocol to support the configuration/enable the OAM function of Ethernet LSP, which I think is a good thing to do, it is not saying to use signaling protocol to do the OAM work. But anyway, it may be necessary to clarify the objective at the beginning of this draft.

			Regards,

			Dan

			----- Original Message ----- 
			
			From: Diego Caviglia <mailto:[email-masked]>  
			
			To: [email-masked] ; Attila Takacs <mailto:[email-masked]>  ; [email-masked] 
			
			Cc: [email-masked] 
			
			Sent: Thursday, December 06, 2007 12:27 AM
			
			Subject: RE: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt

			Hi Neil,

			           Yes I totally agree with your analysis.

			The is not going to redefine or reinvent the OAM that, as Thomas as pointed out, is done by IEEE, the ID just specify how to use a control plane mechanism (GMPLS) set-up at the same time data plane circuit and the related OAM.

			Frankly specking I don$BCU(J see any layer violation here.

			BR

			Diego

			
________________________________

			From: [email-masked] [mailto:[email-masked]] 
			
			Sent: marted$B!&(J4 dicembre 2007 22.55
			
			To: Attila Takacs; [email-masked]; Diego Caviglia
			
			Cc: [email-masked]
			
			Subject: RE: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt

			I'm puzzled.  I read the draft and thought it was excellent.  It is addressing an important operational issue, ie a critical operational OAM requirement is to ensure that whatever mechanism (MP or CP) is used to set-up/tear-down a connection (so this only applies to co-cs or co-ps modes....the cl-ps mode does not have connections of course) is harmonised to the activation/deactivation of the OAM.....specifically a CV/CC flow.   If we don't ensure this then there will be obvious operational problems.  This is essentially what the draft is about.

			Further, GMPLS is a generic OOB CP technique.....it is not a specific layer network technology per se (but it is specific in it's choice of signalling and routing components).  So one can apply a largely similar (GMPLS) CP technique to all co-cs mode technologies (whether they are partitioning a space, freq or time resource - see Note) and co-ps mode technologies (which only applies to partitioning a time resource - see Note) on the assumption that the technology is correctly architected in the DP for the mode considered.  It's pretty hard not to correctly architect the co-cs mode, but it's quite easy to incorrectly architect the co-ps mode, eg one can't violate the rules of a connection in the co-cs mode but one can in the co-ps mode.

			Note - When we partition a time resource in regular time-slices we create a co-cs mode layer network.  When we partition a time resource in irregular time-slices we create a co-ps mode layer network.  More information on labelling and resource partitioning can be found in the work on unified modelling (of networks) in G.800.

			regards, Neil

			-----Original Message-----
			
			From: [email-masked] [mailto:[email-masked]] On Behalf Of Attila Takacs
			
			Sent: 05 December 2007 02:03
			
			To: Thomas Nadeau; Diego Caviglia
			
			Cc: [email-masked]
			
			Subject: RE: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt

			Hi Tom,

			please see inline.

			Best regards,

			Attila

			
________________________________

			From: Thomas Nadeau [mailto:[email-masked]] 
			
			Sent: Wednesday, December 05, 2007 2:19 AM
			
			To: Diego Caviglia
			
			Cc: Attila Takacs; [email-masked]; [email-masked]
			
			Subject: Re: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt

			On Dec 4, 2007, at 7:33 PM, Diego Caviglia wrote:

			
			Hi Thomas,

			                 My understanding of the ID was that RSVP-TE can be used to $BAQ(Jiggyback$B!)(JCFM set-up, otherwise the scenario is: usage of RSVP-TE to set-up the LSP and NMS (meaning everything that is not control plane) to enable to CFM for the LSP.

			As I understand it, the IEEE is working on set-up of CFM (and MEPs), as are some vendors I know. *)

			This to me seems like the right way to do this.

		IEEE specified CFM and MIBs to setup CFM. 
		
		Diego's summary is correct: one can use an NMS or a control plane to setup the data plane. In this case we propose to use GMPLS to setup the data plane: both forwarding + OAM.

				From your comment I see that you$BCS(Je not happy with the fact the ID is so technology specific am I right?  

			
			Precisely; its gluing CFM to RSVP-TE/GMPLS as a transport. 

		I do not see your point with gluing. What do you mean by "as transport"? GMPLS is just controlling OAM, CFM is run solely in the data plane.

				If yes do you agree with the fact that could be useful in general to use the same signaling $BAT(Jession$B!)(Jto set-up the LSP and to enable the CFM?

			
			No, I do not agree.  Again, if CFM is to be set-up e2e, let the IEEE define this. Leave GMPLS to CCAMP.

		
		Sorry, I cannot follow.

			

			

			--Tom

			

			  
			 Best Regards

			Diego
			
________________________________

			From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas Nadeau
			
			Sent: marted$B!&(J4 dicembre 2007 11.30
			
			To: Attila Takacs
			
			Cc: [email-masked]; [email-masked]
			
			Subject: Re: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt

			On Dec 4, 2007, at 1:51 PM, Attila Takacs wrote:

			Hi Thomas,

			Thank you for the comments!

			Please see answers inline.

			Best regards,
			
			Attila
			
________________________________

			From: Thomas Nadeau [mailto:[email-masked]] 
			
			Sent: Tuesday, December 04, 2007 2:58 PM
			
			To: [email-masked]
			
			Cc: Attila Takacs; [email-masked]
			
			Subject: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt

			After reading this draft, I have some questions/comments.

			1) Overall, I am concerned that the definition of a new TLV and these procedures represent 

			what amounts to a laying violation and ask that the ADs take a look at this

			approach closely. This is similar to the now-rejected approach that was proposed

			in the l2vpn WG about munging CFM + PWs.  To my reading, this is essentially

			the same thing. If you want to run CFM, run it natively over the ethernet interfaces and

			have no regard for the underlying topology (GMPLS, PWs, etc...) otherwise you 

			will be creating a mess for implementations and interoperability. 

		The application of the draft is exactly for what you are calling out: when CFM is run natively over the Ethernet interfaces. The document focuses on GELS and Ethernet LSPs. That is, to establish CFM entities for GMPLS controlled Ethernet LSPs. Hence, I think there is no layer violation issue.
		
		         This solution specifically only works for GMPLS ethernet LSPs, right?  
		
		What do I do if I want to set up MPLS ethernet LSPs (i.e.: PWs) and do CFM over those? Oh,
		
		that is a different solution, right?  Then what do I do if I want to run CFM over some new type of
		
		ethernet LSP in the future? More protocol hacks?  The point is to use CFM over an ethernet interface
		
		without the underlying layers knowing. This is good networking architecture design, that simplifies
		
		implementations and makes them more robust, as well as makes using them operationally much
		
		easier. 

				2) The introductory sections in this draft give a lot of discussion about fast fault detection. I

				am puzzled by this given that GMPLS networks tend to run over quickly self-healing

				optical infrastructures. Is it therefore truly necessary to motivate this work by

				requiring fast CFMs?

			It is right that frequent CCMs are not required if the layers below Ethernet handle protection. However, the ID focuses on Ethernet LSPs where Ethernet is not just a single hop above a transport LSP. In this case Ethernet layer (for clarity GELS) may provide protection for Ethernet LSPs. In any case,  the whole point of the ID is to allow for the appropriate configuration of CFM for Ethernet LSPs with GMPLS.

				3) This document does not cover E-LMI. Why not?

			E-LMI is run over the MEF UNI. The ID focuses on Ethernet LSPs within a network.

				For the purposes of this document, we only discuss Ethernet OAM

				   [IEEE-CFM] aspects that are relevant for the connectivity monitoring

				   of bidirectional point-to-point PBB-TE connections.  

				4) Is this the right place to define this document or should this be done in GELS?

			Well, GELS is done in CCAMP...this seems to be the right place.

				5)   In section 2 you make the following statement:

				2.  GMPLS RSVP-TE Extensions

				    To simplify the configuration of connectivity monitoring, when an

				   Ethernet LSP is signalled the associated MEPs should be automatically

				    established.  Further more, GMPLS signalling should be able to

				  enable/disable connectivity monitoring of a particular Ethernet LSP.

				To my point in #1 above, you should use the native CFM functionality over the ethernet interface and signal

				those capabilities to the bridges at both ends using the IEEE CFM signaling procedures (when and if they

				are created).  If you want to test the underlying GMPLS LSP(s), then you should use some

				other mechanism defined for that layer such as the work stated in draft-ali-ccamp-gmpls-LSP-ping-traceroute-00.txt

			See the note to your point #1. There is no relation to the gmpls-LSP-ping draft. 

		         The point I am making is that perhaps it should.
		
		         --Tom

	-------------------------------------
	Wataru Imajuku, Ph.D.@NTT Network Innovation Labs
	TEL: +81-46-859-4315
	FAX: +81-46-859-5541

------_=_NextPart_001_01C837B5.27F0AC40
Content-Type: text/html;
	charset="ISO-2022-JP"
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-2022-jp">
<META content="MSHTML 6.00.2800.1589" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=434585301-06122007><FONT face=Arial color=#0000ff size=2>Hi 
Wataru,</FONT></SPAN></DIV>
<DIV><SPAN class=434585301-06122007><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=434585301-06122007><FONT face=Arial color=#0000ff size=2>Just 
adding to Adrian's points...</FONT></SPAN></DIV>
<DIV><SPAN class=434585301-06122007><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=434585301-06122007><FONT face=Arial color=#0000ff size=2>I 
think it is useful to separate A and M bits. </FONT></SPAN><SPAN 
class=434585301-06122007><FONT face=Arial color=#0000ff size=2>When the LSP is 
put in administratively down, e.g., &nbsp;to avoid it is carrying traffic for 
any reason,&nbsp;it would be still useful to run data plane OAM 
so&nbsp;one&nbsp;knows the data plane is in tact&nbsp;when&nbsp;the LSP&nbsp;is 
put back operational.&nbsp;That is, &nbsp;A=1, M=0. </FONT></SPAN><SPAN 
class=434585301-06122007><FONT face=Arial color=#0000ff size=2>On the other 
hand, e.g., in the case of planed maintenance, one might want to turn data plane 
OAM off as well, having A=1, M=1.</FONT></SPAN></DIV>
<DIV><SPAN class=434585301-06122007><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=434585301-06122007><FONT face=Arial color=#0000ff 
size=2>Regarding the I bit, I think even if GMPLS alarm communication is 
disabled, the actual monitoring of data plane connectivity&nbsp;is needed, again 
to have&nbsp;the up to date status of the data plane.</FONT></SPAN></DIV>
<DIV><SPAN class=434585301-06122007><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=434585301-06122007><FONT face=Arial color=#0000ff size=2>In 
summary, I think having a separate M bit is useful, and&nbsp;accounts 
for&nbsp;flexibility.</FONT></SPAN></DIV>
<DIV><SPAN class=434585301-06122007><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=434585301-06122007><FONT face=Arial color=#0000ff size=2>Best 
regards,</FONT></SPAN></DIV>
<DIV><SPAN class=434585301-06122007><FONT face=Arial color=#0000ff 
size=2>Attila</FONT></SPAN></DIV>
<DIV><SPAN class=434585301-06122007><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=434585301-06122007><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV><FONT face=Arial color=#0000ff 
size=2></FONT><BR>
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
  <HR tabIndex=-1>
  <FONT face=Tahoma size=2><B>From:</B> Wataru Imajuku 
  [mailto:[email-masked]] <BR><B>Sent:</B> Wednesday, December 05, 
  2007 9:53 PM<BR><B>To:</B> Attila Takacs<BR><B>Cc:</B> 
  [email-masked]<BR><B>Subject:</B> RE: 
  draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt<BR></FONT><BR></DIV>
  <DIV></DIV>Hi, Attila<BR><BR>&nbsp;I understand this proposal automates manual 
  configuration to set CFM interval in data plane.<BR>&nbsp;Control of CFM 
  interval is new issue which GMPLS signaling mechanism has not 
  covered.<BR>&nbsp;Although you outline Ethernet OAM functionality in section 
  2, I think it is better to describe what is difference and what is common in 
  OAM functionality compared to circuit switched technologies <BR>which GMPLS 
  has been covered.<BR><BR>&nbsp;On the other hand, I could not understand why 
  do you need M bit in Admin Status Object.<BR>&nbsp;Why do not use A=1 
  ?<BR>&nbsp;Is the objective of M bit to stop sending CCM temporally 
  ?<BR><BR>Best Regards<BR>Wataru<BR><BR>At 04:37 07/12/06, Attila Takacs 
  wrote:<BR>
  <BLOCKQUOTE type="cite">"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"&gt; <BR><FONT face=arial 
    color=#0000ff size=2>Hi all,<BR></FONT>&nbsp;<BR><FONT face=arial 
    color=#0000ff size=2>Neil's and Dan's summary are exact. Thanks for your 
    comments!<BR></FONT>&nbsp;<BR><FONT face=arial color=#0000ff size=2>Maybe 
    the title of the ID caused the misunderstanding, it would say more if it 
    would read: "GMPLS RSVP-TE Extensions to *Control* Ethernet 
    OAM".<BR>Nevertheless, when updating the ID we will clarify our point even 
    more.<BR></FONT>&nbsp;<BR><FONT face=arial color=#0000ff size=2>Best 
    regards,<BR>Attila<BR></FONT><BR>
    <DL>
      <HR>

      <DD><FONT face=tahoma size=2>From:</B> Dan Li [<A 
      href="mailto:[email-masked]" 
      eudora="autourl">mailto:[email-masked]</A>] <BR>
      <DD>Sent:</B> Wednesday, December 05, 2007 6:01 PM<BR>
      <DD>To:</B> Diego Caviglia; [email-masked]; Attila Takacs; 
      [email-masked]<BR>
      <DD>Cc:</B> [email-masked]<BR>
      <DD>Subject:</B> Re: 
      draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt<BR></FONT><BR>
      <DD>Hi,<BR>
      <DD><BR>&nbsp;
      <DD>I think there is a misunderstanding with respect to the objective of 
      this draft. <BR>
      <DD><BR>&nbsp;
      <DD>As I read this draft, it describes how to extend the RSVP protocol to 
      support the configuration/enable the OAM function of Ethernet LSP, which I 
      think is a good thing to do, it is not saying to use signaling protocol to 
      do the OAM work. But anyway, it may be necessary to clarify the objective 
      at the beginning of this draft.<BR>
      <DD><BR>&nbsp;
      <DD>Regards,<BR>
      <DD><BR>&nbsp;
      <DD>Dan<BR>
      <DD><BR>&nbsp;
      <DD><BR>&nbsp;
      <DD>----- Original Message ----- <BR>
      <DD>From:</B> <A href="mailto:[email-masked]">Diego 
      Caviglia</A> <BR>
      <DD>To:</B> <A 
      href="mailto:[email-masked]">[email-masked]</A> ; <A 
      href="mailto:[email-masked]">Attila Takacs</A> ; <A 
      href="mailto:[email-masked]">[email-masked]</A> <BR>
      <DD>Cc:</B> <A href="mailto:[email-masked]">[email-masked]</A> 
<BR>
      <DD>Sent:</B> Thursday, December 06, 2007 12:27 AM<BR>
      <DD>Subject:</B> RE: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt<BR><BR>
      <DD><FONT face=arial color=#000080 size=2>Hi Neil,<BR></FONT><BR>
      <DD><FONT face=arial color=#000080 
      size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Yes I 
      totally agree with your analysis.<BR></FONT><BR>
      <DD><FONT face=arial color=#000080 size=2><BR></FONT><BR>&nbsp;
      <DD><FONT face=arial color=#000080 size=2>The is not going to redefine or 
      reinvent the OAM that, as Thomas as pointed out, is done by IEEE, the ID 
      just specify how to use a control plane mechanism (GMPLS) set-up at the 
      same time data plane circuit and the related OAM.<BR></FONT><BR>
      <DD><FONT face=arial color=#000080 size=2><BR></FONT><BR>&nbsp;
      <DD><FONT face=arial color=#000080 size=2>Frankly specking I don$BCU(B see any 
      layer violation here.<BR></FONT><BR>
      <DD><FONT face=arial color=#000080 size=2><BR></FONT><BR>&nbsp;
      <DD><FONT face=arial color=#000080 size=2>BR<BR></FONT><BR>
      <DD><FONT face=arial color=#000080 size=2><BR></FONT><BR>&nbsp;
      <DD><FONT face=arial color=#000080 size=2>Diego<BR></FONT><BR>
      <DD><FONT face=arial color=#000080 size=2><BR>
      <HR>

      <DIV align=center></FONT></DIV>
      <DD><FONT face=tahoma size=2>From:</B> <A 
      href="mailto:[email-masked]">[email-masked]</A> [<A 
      href="mailto:[email-masked]" 
      eudora="autourl">mailto:[email-masked]</A>] <BR>
      <DD>Sent:</B> marted$B!&(B4 dicembre 2007 22.55<BR>
      <DD>To:</B> Attila Takacs; <A 
      href="mailto:[email-masked]">[email-masked]</A>; Diego 
      Caviglia<BR>
      <DD>Cc:</B> <A href="mailto:[email-masked]">[email-masked]</A><BR>
      <DD>Subject:</B> RE: 
      draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt<BR></FONT><BR>
      <DD><FONT face="times new roman"><BR></FONT><BR>&nbsp;
      <DD><FONT face="comic sans ms" color=#800000 size=2>I'm puzzled.&nbsp; I 
      read the draft and thought it was excellent.&nbsp; It is addressing an 
      important operational issue, ie a critical operational OAM requirement is 
      to ensure that whatever mechanism (MP or CP) is used to set-up/tear-down a 
      connection (so this only applies to co-cs or co-ps modes....the cl-ps mode 
      does not have connections of course) is harmonised to the 
      activation/deactivation of the OAM.....specifically a CV/CC 
      flow.&nbsp;&nbsp; If we don't ensure this then there will be obvious 
      operational problems.&nbsp; This is essentially what the draft is 
      about.<BR></FONT><BR>
      <DD><FONT face="times new roman"><BR></FONT><BR>&nbsp;
      <DD><FONT face="comic sans ms" color=#800000 size=2>Further, GMPLS is a 
      generic OOB CP technique.....it is not a specific layer network technology 
      per se (but it is specific in it's choice of signalling and routing 
      components).&nbsp; So one can apply a largely similar (GMPLS) CP technique 
      to all co-cs mode technologies (whether they are partitioning a space, 
      freq or time resource - see Note) and co-ps mode technologies (which only 
      applies to partitioning a time resource - see Note) on the assumption that 
      the technology is correctly architected in the DP for the mode 
      considered.&nbsp; It's pretty hard not to correctly architect the co-cs 
      mode, but it's quite easy to incorrectly architect the co-ps mode, eg one 
      can't violate the rules of a connection in the co-cs mode but one can in 
      the co-ps mode.<BR></FONT><BR>
      <DD><FONT face="times new roman"><BR></FONT><BR>&nbsp;
      <DD><FONT face="comic sans ms" color=#800000 size=2>Note - When we 
      partition a time resource in regular time-slices we create a co-cs mode 
      layer network.&nbsp; When we partition a time resource in irregular 
      time-slices we create a co-ps mode layer network.&nbsp; More information 
      on labelling and resource partitioning can be found in the work on unified 
      modelling (of networks) in G.800.<BR></FONT><BR>
      <DD><FONT face="times new roman"><BR></FONT><BR>&nbsp;
      <DD><FONT face="comic sans ms" color=#800000 size=2>regards, 
      Neil<BR></FONT><BR>
      <DD><FONT face=tahoma size=2>-----Original Message-----<BR>
      <DD>From:</B> [email-masked] [<A 
      href="mailto:[email-masked]" 
      eudora="autourl">mailto:[email-masked]</A>] On Behalf Of 
      </B>Attila Takacs<BR>
      <DD>Sent:</B> 05 December 2007 02:03<BR>
      <DD>To:</B> Thomas Nadeau; Diego Caviglia<BR>
      <DD>Cc:</B> [email-masked]<BR>
      <DD>Subject:</B> RE: 
      draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt<BR></FONT><BR>
      <DD><FONT face=arial color=#0000ff size=2>Hi Tom,<BR></FONT><BR>
      <DD><FONT face=arial color=#0000ff size=2>please see 
inline.<BR></FONT><BR>
      <DD><FONT face=arial color=#0000ff size=2>Best regards,<BR></FONT><BR>
      <DD><FONT face=arial color=#0000ff size=2>Attila<BR></FONT><BR>
      <DD><FONT face="times new roman"><BR>
      <HR>

      <DIV align=center></FONT></DIV>
      <DD><FONT face=tahoma size=2>From:</B> Thomas Nadeau [<A 
      href="mailto:[email-masked]" 
      eudora="autourl">mailto:[email-masked]</A>] <BR>
      <DD>Sent:</B> Wednesday, December 05, 2007 2:19 AM<BR>
      <DD>To:</B> Diego Caviglia<BR>
      <DD>Cc:</B> Attila Takacs; [email-masked]; 
[email-masked]<BR>
      <DD>Subject:</B> Re: 
      draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt<BR></FONT><BR>
      <DD><FONT face="times new roman"><BR></FONT><BR>&nbsp;
      <DD><FONT face="times new roman">On Dec 4, 2007, at 7:33 PM, Diego 
      Caviglia wrote:<BR></FONT><BR><FONT face="times new roman"><BR><BR></FONT>
      <DD><FONT face=arial color=#000080 size=2>Hi Thomas,<BR></FONT><BR>
      <DD><FONT face=arial color=#000080 
      size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      My understanding of the ID was that RSVP-TE can be used to $BAQ(Biggyback$B!)(BCFM 
      set-up, otherwise the scenario is: usage of RSVP-TE to set-up the LSP and 
      NMS (meaning everything that is not control plane) to enable to CFM for 
      the LSP.<BR></FONT><BR>
      <DD><FONT face="times new roman"><BR></FONT><BR>&nbsp;
      <DD><FONT face="times new roman">As I understand it, the IEEE is working 
      on set-up of CFM (and MEPs), as are some vendors I know. *)<BR></FONT><BR>
      <DD><FONT face="times new roman">This to me seems like the right way to do 
      this.<BR></FONT><BR>
      <DD><FONT face="times new roman"><BR></FONT><BR>&nbsp;</DD></DL><FONT 
    face=arial color=#0000ff size=2>IEEE specified CFM and MIBs to setup CFM. 
    <BR></FONT><BR><FONT face=arial color=#0000ff size=2>Diego's summary is 
    correct: one can use an NMS or a control plane to setup the data plane. In 
    this case we propose to use GMPLS to setup the data plane: both forwarding + 
    OAM.<BR></FONT>
    <BLOCKQUOTE type="cite">
      <DL><BR>
        <DD><FONT face="times new roman" color=#144fae size=2>From your comment 
        I see that you$BCS(Be not happy with the fact the ID is so technology 
        specific am I right?&nbsp; <BR></FONT><BR></DD></DL><FONT 
      face="times new roman">&nbsp;<BR></FONT><BR><FONT 
      face="times new roman">Precisely; its gluing CFM to RSVP-TE/GMPLS as a 
      transport. </FONT></BLOCKQUOTE><BR><FONT face=arial color=#0000ff size=2>I 
    do not see your point with gluing. What do you mean by "as transport"? GMPLS 
    is just controlling OAM, CFM is run solely in the data 
    plane.<BR></FONT><BR><FONT face="times new roman">&nbsp;<BR></FONT><BR><FONT 
    face="times new roman">&nbsp;<BR></FONT>
    <BLOCKQUOTE type="cite">
      <DL><BR>
        <DD><FONT face="times new roman" color=#144fae size=2>If yes do you 
        agree with the fact that could be useful in general to use the same 
        signaling $BAT(Bession$B!)(Bto set-up the LSP and to enable the 
        CFM?<BR></FONT><BR></DD></DL><FONT 
      face="times new roman">&nbsp;<BR></FONT><BR><FONT 
      face="times new roman">No, I do not agree.&nbsp; Again, if CFM is to be 
      set-up e2e, let the IEEE define this. Leave GMPLS to 
    CCAMP.</FONT></BLOCKQUOTE><BR><FONT 
    face="times new roman">&nbsp;<BR></FONT><BR><FONT 
    face="times new roman">&nbsp;<BR></FONT><BR><FONT face=arial color=#0000ff 
    size=2>Sorry, I cannot follow.<BR></FONT><BR><FONT 
    face="times new roman">&nbsp;<BR></FONT><BR><FONT 
    face="times new roman">&nbsp;<BR></FONT>
    <DL><BR>
      <DD><FONT face="times new roman"><BR></FONT><BR>&nbsp;
      <DD><FONT face="times new roman"><BR></FONT><BR>&nbsp;
      <DD><FONT face="times new roman"><BR></FONT><BR>&nbsp;
      <DD><FONT face="times new roman">--Tom<BR></FONT><BR>
      <DD><FONT face="times new roman"><BR></FONT><BR>&nbsp;
      <DD><FONT face="times new roman"><BR></FONT><BR><FONT 
      face="times new roman"><BR><BR></FONT>&nbsp;
      <DD><FONT face=arial color=#000080 size=2>&nbsp;</FONT><FONT face=arial 
      color=#144fae size=2>Best Regards<BR></FONT><BR><FONT face=arial 
      color=#000080 size=2><BR>
      <DD>Diego<BR>
      <HR>

      <DIV align=center></FONT></DIV>
      <DD><FONT face=tahoma size=2>From:</B> <A 
      href="mailto:[email-masked]">[email-masked]</A> [<A 
      href="mailto:[email-masked]">mailto:[email-masked]</A>] 
      On Behalf Of </B>Thomas Nadeau<BR>
      <DD>Sent:</B> marted$B!&(B4 dicembre 2007 11.30<BR>
      <DD>To:</B> Attila Takacs<BR>
      <DD>Cc:</B> <A href="mailto:[email-masked]">[email-masked]</A>; <A 
      href="mailto:[email-masked]">[email-masked]</A><BR>
      <DD>Subject:</B> Re: 
      draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt<BR></FONT><BR>
      <DD><FONT face="times new roman">On Dec 4, 2007, at 1:51 PM, Attila Takacs 
      wrote:<BR></FONT><BR><FONT face="times new roman"><BR><BR><BR></FONT>
      <DD><FONT face=arial color=#0000ff size=2>Hi Thomas,<BR></FONT><BR>
      <DD><FONT face=arial color=#0000ff size=2>Thank you for the 
      comments!<BR></FONT><BR>
      <DD><FONT face=arial color=#0000ff size=2>Please see answers 
      inline.<BR></FONT><BR>
      <DD><FONT face=arial color=#0000ff size=2>Best regards,<BR>
      <DD>Attila<BR>
      <HR>

      <DIV align=center></FONT></DIV>
      <DD><FONT face=tahoma size=2>From:</B> Thomas Nadeau [<A 
      href="mailto:[email-masked]">mailto:[email-masked]</A>] 
      <BR>
      <DD>Sent:</B> Tuesday, December 04, 2007 2:58 PM<BR>
      <DD>To:</B> <A href="mailto:[email-masked]">[email-masked]</A><BR>
      <DD>Cc:</B> Attila Takacs; <A 
      href="mailto:[email-masked]">[email-masked]</A><BR>
      <DD>Subject:</B> 
      draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt<BR></FONT><BR>
      <DD><FONT face="times new roman">After reading this draft, I have some 
      questions/comments.<BR></FONT><BR>
      <DD><FONT face="times new roman">1) Overall, I am concerned that the 
      definition of a new TLV and these procedures represent <BR></FONT><BR>
      <DD><FONT face="times new roman">what amounts to a laying violation and 
      ask that the ADs take a look at this<BR></FONT><BR>
      <DD><FONT face="times new roman">approach closely. This is similar to the 
      now-rejected approach that was proposed<BR></FONT><BR>
      <DD><FONT face="times new roman">in the l2vpn WG about munging CFM + 
      PWs.&nbsp; To my reading, this is essentially<BR></FONT><BR>
      <DD><FONT face="times new roman">the same thing. If you want to run CFM, 
      run it natively over the ethernet interfaces and<BR></FONT><BR>
      <DD><FONT face="times new roman">have no regard for the underlying 
      topology (GMPLS, PWs, etc...) otherwise you <BR></FONT><BR>
      <DD><FONT face="times new roman">will be creating a mess for 
      implementations and interoperability. </FONT><FONT face=arial 
      color=#0000ff size=2><BR></FONT><BR></DD></DL><FONT face=arial color=#0000ff 
    size=2>The application of the draft is exactly for what you are calling out: 
    when CFM is run natively over the Ethernet interfaces. The document focuses 
    on GELS and Ethernet LSPs. That is, to establish CFM entities for GMPLS 
    controlled Ethernet LSPs. Hence, I think there is no layer violation 
    issue.<BR></FONT><BR><FONT 
    face="times new roman">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    </FONT>This solution specifically only works for GMPLS ethernet LSPs, 
    right?&nbsp; <BR><BR><FONT face="times new roman">What do I do if I want to 
    set up MPLS ethernet LSPs (i.e.: PWs) and do CFM over those? 
    Oh,<BR></FONT><BR><FONT face="times new roman">that is a different solution, 
    right?&nbsp; Then what do I do if I want to run CFM over some new type 
    of<BR></FONT><BR><FONT face="times new roman">ethernet LSP in the future? 
    More protocol hacks?&nbsp; The point is to use CFM over an ethernet 
    interface<BR></FONT><BR><FONT face="times new roman">without the underlying 
    layers knowing. This is good networking architecture design, that 
    simplifies<BR></FONT><BR><FONT face="times new roman">implementations and 
    makes them more robust, as well as makes using them operationally 
    much<BR></FONT><BR><FONT face="times new roman">easier. <BR></FONT>
    <BLOCKQUOTE type="cite">
      <DL><BR>
        <DD><FONT face="times new roman">2) The introductory sections in this 
        draft give a lot of discussion about fast fault detection. 
        I<BR></FONT><BR>
        <DD><FONT face="times new roman">am puzzled by this given that GMPLS 
        networks tend to run over quickly self-healing<BR></FONT><BR>
        <DD><FONT face="times new roman">optical infrastructures. Is it 
        therefore truly necessary to motivate this work by<BR></FONT><BR>
        <DD><FONT face="times new roman">requiring fast 
      CFMs?<BR></FONT><BR></DD></DL><FONT face=arial color=#0000ff size=2>It is 
      right that frequent CCMs are not required if the layers below Ethernet 
      handle protection. However, the ID focuses on Ethernet LSPs where Ethernet 
      is not just a single hop above a transport LSP. In this case Ethernet 
      layer (for clarity GELS) may provide protection for Ethernet LSPs. In any 
      case,&nbsp; the whole point of the ID is to allow for the appropriate 
      configuration of CFM for Ethernet LSPs with GMPLS.<BR></FONT>
      <DL><BR>
        <DD><FONT face="times new roman">3) This document does not cover E-LMI. 
        Why not?<BR></FONT><BR></DD></DL><FONT face=arial color=#0000ff 
      size=2>E-LMI is run over the MEF UNI. The ID focuses on Ethernet LSPs 
      within a network.<BR></FONT>
      <DL><BR>
        <DD><FONT face="times new roman" size=1>For the purposes of this 
        document, we only discuss Ethernet OAM<BR></FONT><BR>
        <DD><FONT face=helvetica size=1>&nbsp;&nbsp; [IEEE-CFM] aspects that are 
        relevant for the connectivity monitoring<BR></FONT><BR>
        <DD><FONT face=helvetica size=1>&nbsp;&nbsp; of bidirectional 
        point-to-point PBB-TE connections.&nbsp; <BR></FONT><BR>
        <DD><FONT face=helvetica size=1>4) Is this the right place to define 
        this document or should this be done in 
      GELS?<BR></FONT><BR></DD></DL><FONT face=arial color=#0000ff size=2>Well, 
      GELS is done in CCAMP...this seems to be the right place.<BR></FONT>
      <DL><BR>
        <DD><FONT face=helvetica size=1>5)&nbsp;&nbsp; In section 2 you make the 
        following statement:<BR></FONT><BR>
        <DD><FONT face=helvetica size=1>2.&nbsp; GMPLS RSVP-TE 
        Extensions<BR></FONT><BR>
        <DD><FONT face=helvetica size=1>&nbsp;&nbsp;&nbsp; To simplify the 
        configuration of connectivity monitoring, when an<BR></FONT><BR>
        <DD><FONT face=helvetica size=1>&nbsp;&nbsp; Ethernet LSP is signalled 
        the associated MEPs should be automatically<BR></FONT><BR>
        <DD><FONT face=helvetica size=1>&nbsp;&nbsp;&nbsp; established.&nbsp; 
        Further more, GMPLS signalling should be able to<BR></FONT><BR>
        <DD><FONT face=helvetica size=1>&nbsp; enable/disable connectivity 
        monitoring of a particular Ethernet LSP.<BR></FONT><BR>
        <DD><FONT face=helvetica size=1>To my point in #1 above, you should use 
        the native CFM functionality over the ethernet interface and 
        signal<BR></FONT><BR>
        <DD><FONT face=helvetica size=1>those capabilities to the bridges at 
        both ends using the IEEE CFM signaling procedures (when and if 
        they<BR></FONT><BR>
        <DD><FONT face=helvetica size=1>are created).&nbsp; If you want to test 
        the underlying GMPLS LSP(s), then you should use some<BR></FONT><BR>
        <DD><FONT face=helvetica size=1>other mechanism defined for that layer 
        such as the work stated in </FONT><FONT face=helvetica 
        size=2>draft-ali-ccamp-gmpls-LSP-ping-traceroute-00.txt<BR></B></FONT><BR></DD></DL><FONT 
      face=arial color=#0000ff size=2>See the note to your point #1. There is no 
      relation to the gmpls-LSP-ping draft. </FONT></BLOCKQUOTE><BR><FONT 
    face="times new roman">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    </FONT>The point I am making is that perhaps it should.<BR><BR><FONT 
    face="times new roman">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    </FONT>--Tom<BR><BR><FONT 
  face="times new roman">&nbsp;<BR></FONT></BLOCKQUOTE><X-SIGSEP>
  <P></X-SIGSEP>-------------------------------------<BR>Wataru Imajuku, 
  Ph.D.@NTT Network Innovation Labs<BR>TEL: +81-46-859-4315<BR>FAX: 
  +81-46-859-5541<BR></P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C837B5.27F0AC40--

Delivery-date: Thu, 06 Dec 2007 02:31:09 +0000
Date: Thu, 06 Dec 2007 03:28:26 +0100
From: Loa Andersson <[email-masked]>
Organization: Acreo AB
To: ccamp <[email-masked]>
Subject: what happened alternatively what will happen

Adrian and Deborah,

yesterday a set of IDs on GMPLS control of Ethernet were presented;
given that I remember correctly the author of the requirement draft
said they think that the draft will be ready to become a working
group document after next IETF meeting.

The authors of the architecture draft for GMPLS controlled Ethernet
and the protocol extensions for control of PBT-TE networks requested
that their draft should be accepted as working group documents.

No sense of the room were taken or "take it to the list" statement.

What's the plan?

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

This email was Anti Virus checked by Astaro Security Gateway. http://www.astaro.com

Delivery-date: Wed, 05 Dec 2007 22:14:07 +0000
Cc: Dan Li <[email-masked]>, Diego Caviglia <[email-masked]>, [email-masked], Attila Takacs <[email-masked]>, [email-masked]
From: Thomas Nadeau <[email-masked]>
To: Loa Andersson <[email-masked]>
Subject: Re: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt
Date: Wed, 5 Dec 2007 17:12:20 -0500

	What do we do for the other signaling protocols outside of =
CCAMP?
Do we now extend BGP, RSVP-TE (for MPLS), and LDP to control OAM there
as well?

	--Tom

=09
> All,
>
> I'm normally a bit careful with models "layer networks" that seems
> to be a rather cumbersome way of explaining the obvious; however
> in this case when it is used demonstrate that no layer violation
> is at hand I is inclined to accept that result.
>
> I also agree with Dan that it seems to be a good idea to use
> RSVP-TE to provision OAM functionality is a good idea.
>
> With that it we should just go ahead and accept this as a
> ccamp work item.
>
> /Loa
>
> Dan Li wrote:
>> MessageHi,
>>
>> I think there is a misunderstanding with respect to the objective =20
>> of this draft.
>>
>> As I read this draft, it describes how to extend the RSVP protocol
>
> to support the configuration/enable the OAM function of Ethernet LSP,
>
> which I think is a good thing to do, it is not saying to use signaling
>
> protocol to do the OAM work. But anyway, it may be necessary to =20
> clarify
>
> the objective at the beginning of this draft.
>>
>> Regards,
>>
>> Dan
>>
>>
>>  ----- Original Message -----
>>  From: Diego Caviglia
>>  To: [email-masked] ; Attila Takacs ; [email-masked]
>>  Cc: [email-masked]
>>  Sent: Thursday, December 06, 2007 12:27 AM
>>  Subject: RE: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt
>>
>>
>>  Hi Neil,
>>
>>             Yes I totally agree with your analysis.
>>
>>
>>
>>  The is not going to redefine or reinvent the OAM that, as Thomas =20
>> as pointed out, is done by IEEE, the ID just specify how to use a =20
>> control plane mechanism (GMPLS) set-up at the same time data plane =20=

>> circuit and the related OAM.
>>
>>
>>
>>  Frankly specking I don't see any layer violation here.
>>
>>
>>
>>  BR
>>
>>
>>
>>  Diego
>>
>>
>>
>>
>> =
--------------------------------------------------------------------------=
----
>>
>>  From: [email-masked] [mailto:[email-masked]]
>>  Sent: marted=EC 4 dicembre 2007 22.55
>>  To: Attila Takacs; [email-masked]; Diego Caviglia
>>  Cc: [email-masked]
>>  Subject: RE: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt
>>
>>
>>
>>  I'm puzzled.  I read the draft and thought it was excellent.  It =20
>> is addressing an important operational issue, ie a critical =20
>> operational OAM requirement is to ensure that whatever mechanism =20
>> (MP or CP) is used to set-up/tear-down a connection (so this only =20
>> applies to co-cs or co-ps modes....the cl-ps mode does not have =20
>> connections of course) is harmonised to the activation/deactivation =20=

>> of the OAM.....specifically a CV/CC flow.   If we don't ensure this =20=

>> then there will be obvious operational problems.  This is =20
>> essentially what the draft is about.
>>
>>
>>
>>  Further, GMPLS is a generic OOB CP technique.....it is not a =20
>> specific layer network technology per se (but it is specific in =20
>> it's choice of signalling and routing components).  So one can =20
>> apply a largely similar (GMPLS) CP technique to all co-cs mode =20
>> technologies (whether they are partitioning a space, freq or time =20
>> resource - see Note) and co-ps mode technologies (which only =20
>> applies to partitioning a time resource - see Note) on the =20
>> assumption that the technology is correctly architected in the DP =20
>> for the mode considered.  It's pretty hard not to correctly =20
>> architect the co-cs mode, but it's quite easy to incorrectly =20
>> architect the co-ps mode, eg one can't violate the rules of a =20
>> connection in the co-cs mode but one can in the co-ps mode.
>>
>>
>>
>>  Note - When we partition a time resource in regular time-slices we =20=

>> create a co-cs mode layer network.  When we partition a time =20
>> resource in irregular time-slices we create a co-ps mode layer =20
>> network.  More information on labelling and resource partitioning =20
>> can be found in the work on unified modelling (of networks) in G.800.
>>
>>
>>
>>  regards, Neil
>>
>>    -----Original Message-----
>>    From: [email-masked] [mailto:[email-masked]] =20=

>> On Behalf Of Attila Takacs
>>    Sent: 05 December 2007 02:03
>>    To: Thomas Nadeau; Diego Caviglia
>>    Cc: [email-masked]
>>    Subject: RE: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt
>>
>>    Hi Tom,
>>
>>    please see inline.
>>
>>    Best regards,
>>
>>    Attila
>>
>>
>>
>>
>> =
--------------------------------------------------------------------------=

>>
>>      From: Thomas Nadeau [mailto:[email-masked]]
>>      Sent: Wednesday, December 05, 2007 2:19 AM
>>      To: Diego Caviglia
>>      Cc: Attila Takacs; [email-masked]; [email-masked]
>>      Subject: Re: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt
>>
>>
>>
>>      On Dec 4, 2007, at 7:33 PM, Diego Caviglia wrote:
>>
>>
>>
>>
>>
>>      Hi Thomas,
>>
>>                       My understanding of the ID was that RSVP-TE =20
>> can be used to 'piggyback' CFM set-up, otherwise the scenario is: =20
>> usage of RSVP-TE to set-up the LSP and NMS (meaning everything that =20=

>> is not control plane) to enable to CFM for the LSP.
>>
>>
>>
>>      As I understand it, the IEEE is working on set-up of CFM (and =20=

>> MEPs), as are some vendors I know. *)
>>
>>      This to me seems like the right way to do this.
>>
>>
>>
>>    IEEE specified CFM and MIBs to setup CFM.
>>
>>    Diego's summary is correct: one can use an NMS or a control =20
>> plane to setup the data plane. In this case we propose to use GMPLS =20=

>> to setup the data plane: both forwarding + OAM.
>>
>>        =46rom your comment I see that you're not happy with the fact =20=

>> the ID is so technology specific am I right?
>>
>>
>>
>>      Precisely; its gluing CFM to RSVP-TE/GMPLS as a transport.
>>
>>    I do not see your point with gluing. What do you mean by "as =20
>> transport"? GMPLS is just controlling OAM, CFM is run solely in the =20=

>> data plane.
>>
>>
>>
>>
>>
>>        If yes do you agree with the fact that could be useful in =20
>> general to use the same signaling 'session' to set-up the LSP and =20
>> to enable the CFM?
>>
>>
>>
>>      No, I do not agree.  Again, if CFM is to be set-up e2e, let =20
>> the IEEE define this. Leave GMPLS to CCAMP.
>>
>>
>>
>>
>>
>>    Sorry, I cannot follow.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>      --Tom
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>       Best Regards
>>
>>
>>      Diego
>>
>>
>> =
--------------------------------------------------------------------------=

>>
>>      From: [email-masked] [mailto:owner-=20
>> [email-masked]] On Behalf Of Thomas Nadeau
>>      Sent: marted=EC 4 dicembre 2007 11.30
>>      To: Attila Takacs
>>      Cc: [email-masked]; [email-masked]
>>      Subject: Re: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt
>>
>>      On Dec 4, 2007, at 1:51 PM, Attila Takacs wrote:
>>
>>
>>
>>
>>
>>
>>      Hi Thomas,
>>
>>      Thank you for the comments!
>>
>>      Please see answers inline.
>>
>>      Best regards,
>>      Attila
>>
>>
>> =
------------------------------------------------------------------------
>>
>>        From: Thomas Nadeau [mailto:[email-masked]]
>>        Sent: Tuesday, December 04, 2007 2:58 PM
>>        To: [email-masked]
>>        Cc: Attila Takacs; [email-masked]
>>        Subject: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt
>>
>>        After reading this draft, I have some questions/comments.
>>
>>        1) Overall, I am concerned that the definition of a new TLV =20=

>> and these procedures represent
>>
>>        what amounts to a laying violation and ask that the ADs take =20=

>> a look at this
>>
>>        approach closely. This is similar to the now-rejected =20
>> approach that was proposed
>>
>>        in the l2vpn WG about munging CFM + PWs.  To my reading, =20
>> this is essentially
>>
>>        the same thing. If you want to run CFM, run it natively over =20=

>> the ethernet interfaces and
>>
>>        have no regard for the underlying topology (GMPLS, PWs, =20
>> etc...) otherwise you
>>
>>        will be creating a mess for implementations and =20
>> interoperability.
>>
>>      The application of the draft is exactly for what you are =20
>> calling out: when CFM is run natively over the Ethernet interfaces. =20=

>> The document focuses on GELS and Ethernet LSPs. That is, to =20
>> establish CFM entities for GMPLS controlled Ethernet LSPs. Hence, I =20=

>> think there is no layer violation issue.
>>
>>                This solution specifically only works for GMPLS =20
>> ethernet LSPs, right?
>>
>>      What do I do if I want to set up MPLS ethernet LSPs (i.e.: =20
>> PWs) and do CFM over those? Oh,
>>
>>      that is a different solution, right?  Then what do I do if I =20
>> want to run CFM over some new type of
>>
>>      ethernet LSP in the future? More protocol hacks?  The point is =20=

>> to use CFM over an ethernet interface
>>
>>      without the underlying layers knowing. This is good networking =20=

>> architecture design, that simplifies
>>
>>      implementations and makes them more robust, as well as makes =20
>> using them operationally much
>>
>>      easier.
>>
>>          2) The introductory sections in this draft give a lot of =20
>> discussion about fast fault detection. I
>>
>>          am puzzled by this given that GMPLS networks tend to run =20
>> over quickly self-healing
>>
>>          optical infrastructures. Is it therefore truly necessary =20
>> to motivate this work by
>>
>>          requiring fast CFMs?
>>
>>        It is right that frequent CCMs are not required if the =20
>> layers below Ethernet handle protection. However, the ID focuses on =20=

>> Ethernet LSPs where Ethernet is not just a single hop above a =20
>> transport LSP. In this case Ethernet layer (for clarity GELS) may =20
>> provide protection for Ethernet LSPs. In any case,  the whole point =20=

>> of the ID is to allow for the appropriate configuration of CFM for =20=

>> Ethernet LSPs with GMPLS.
>>
>>          3) This document does not cover E-LMI. Why not?
>>
>>        E-LMI is run over the MEF UNI. The ID focuses on Ethernet =20
>> LSPs within a network.
>>
>>          For the purposes of this document, we only discuss =20
>> Ethernet OAM
>>
>>             [IEEE-CFM] aspects that are relevant for the =20
>> connectivity monitoring
>>
>>             of bidirectional point-to-point PBB-TE connections.
>>
>>          4) Is this the right place to define this document or =20
>> should this be done in GELS?
>>
>>        Well, GELS is done in CCAMP...this seems to be the right =20
>> place.
>>
>>          5)   In section 2 you make the following statement:
>>
>>          2.  GMPLS RSVP-TE Extensions
>>
>>              To simplify the configuration of connectivity =20
>> monitoring, when an
>>
>>             Ethernet LSP is signalled the associated MEPs should be =20=

>> automatically
>>
>>              established.  Further more, GMPLS signalling should be =20=

>> able to
>>
>>            enable/disable connectivity monitoring of a particular =20
>> Ethernet LSP.
>>
>>          To my point in #1 above, you should use the native CFM =20
>> functionality over the ethernet interface and signal
>>
>>          those capabilities to the bridges at both ends using the =20
>> IEEE CFM signaling procedures (when and if they
>>
>>          are created).  If you want to test the underlying GMPLS =20
>> LSP(s), then you should use some
>>
>>          other mechanism defined for that layer such as the work =20
>> stated in draft-ali-ccamp-gmpls-LSP-ping-traceroute-00.txt
>>
>>        See the note to your point #1. There is no relation to the =20
>> gmpls-LSP-ping draft.
>>
>>                The point I am making is that perhaps it should.
>>
>>                --Tom
>>
>>
>>
>
>
> --=20
> 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]
>
> This email was Anti Virus checked by Astaro Security Gateway. =
http://www.astaro.com

Delivery-date: Wed, 05 Dec 2007 21:29:24 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Attila Takacs" <[email-masked]>, "Wataru Imajuku" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt
Date: Wed, 5 Dec 2007 21:28:09 -0000

Hi Wataru,

> On the other hand, I could not understand why do you need M bit in Admin 
> Status Object.
> Why do not use A=1 ?
> Is the objective of M bit to stop sending CCM temporally ?

The A bit is already defined as:
         When set, indicates that the local actions related to the
         "administratively down" state should be taken.

The I bit is additionally defined as:
         When set, indicates that alarm communication is disabled for
         the LSP and that nodes SHOULD NOT add local alarm information.

Neither of these is the same as the proposed M bit
        When this bit is set the connectivity monitoring of the LSP is 
disabled.

So, yes, the proposal is that the M bit adds new function to turn off OAM 
processing on an LSP reqgardless of the administrative status of the LSP. 
Whether that is a useful function is up for discussion.

Adrian 

Delivery-date: Wed, 05 Dec 2007 20:49:31 +0000
Date: Thu, 06 Dec 2007 05:52:45 +0900
To: "Attila Takacs" <[email-masked]>
From: Wataru Imajuku <[email-masked]>
Subject: RE: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt
Cc: <[email-masked]>

<html>
<body>
Hi, Attila<br><br>
&nbsp;I understand this proposal automates manual configuration to set
CFM interval in data plane.<br>
&nbsp;Control of CFM interval is new issue which GMPLS signaling
mechanism has not covered.<br>
&nbsp;Although you outline Ethernet OAM functionality in section 2, I
think it is better to describe what is difference and what is common in
OAM functionality compared to circuit switched technologies <br>
which GMPLS has been covered.<br><br>
&nbsp;On the other hand, I could not understand why do you need M bit in
Admin Status Object.<br>
&nbsp;Why do not use A=1 ?<br>
&nbsp;Is the objective of M bit to stop sending CCM temporally 
?<br><br>
Best Regards<br>
Wataru<br><br>
At 04:37 07/12/06, Attila Takacs wrote:<br>
<blockquote type=cite>&quot;urn:schemas-microsoft-com:vml&quot; xmlns:o =
&quot;urn:schemas-microsoft-com:office:office&quot; xmlns:w =
&quot;urn:schemas-microsoft-com:office:word&quot; xmlns:st1 =
&quot;urn:schemas-microsoft-com:office:smarttags&quot;&gt; <br>
<font face="arial" size=2 color="#0000FF">Hi all,<br>
</font>&nbsp;<br>
<font face="arial" size=2 color="#0000FF">Neil's and Dan's summary are
exact. Thanks for your comments!<br>
</font>&nbsp;<br>
<font face="arial" size=2 color="#0000FF">Maybe the title of the ID
caused the misunderstanding, it would say more if it would read:
&quot;GMPLS RSVP-TE Extensions to *Control* Ethernet OAM&quot;.<br>
Nevertheless, when updating the ID we will clarify our point even
more.<br>
</font>&nbsp;<br>
<font face="arial" size=2 color="#0000FF">Best regards,<br>
Attila<br>
</font><br>

<dl><hr>

<dd><font face="tahoma" size=2>From:</b> Dan Li
[<a href="mailto:[email-masked]" eudora="autourl">mailto:[email-masked]</a>]
<br>

<dd>Sent:</b> Wednesday, December 05, 2007 6:01 PM<br>

<dd>To:</b> Diego Caviglia; [email-masked]; Attila Takacs;
[email-masked]<br>

<dd>Cc:</b> [email-masked]<br>

<dd>Subject:</b> Re: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt<br>
</font><br>

<dd>Hi,<br>

<dd>&nbsp;<br>

<dd>I think there is a misunderstanding with respect to the objective of
this draft. <br>

<dd>&nbsp;<br>

<dd>As I read this draft, it describes how to extend the RSVP protocol to
support the configuration/enable the OAM function of Ethernet LSP, which
I think is a good thing to do, it is not saying to use signaling protocol
to do the OAM work. But anyway, it may be necessary to clarify the
objective at the beginning of this draft.<br>

<dd>&nbsp;<br>

<dd>Regards,<br>

<dd>&nbsp;<br>

<dd>Dan<br>

<dd>&nbsp;<br>

<dd>&nbsp;<br>

<dd>----- Original Message ----- <br>

<dd>From:</b> <a href="mailto:[email-masked]">Diego
Caviglia</a> <br>

<dd>To:</b>
<a href="mailto:[email-masked]">[email-masked]</a> ; <a href="mailto:[email-masked]">Attila Takacs</a> ; <a href="mailto:[email-masked]">[email-masked]</a> <br>

<dd>Cc:</b> <a href="mailto:[email-masked]">[email-masked]</a> <br>

<dd>Sent:</b> Thursday, December 06, 2007 12:27 AM<br>

<dd>Subject:</b> RE: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt<br><br>

<dd><font face="arial" size=2 color="#000080">Hi Neil,<br>
</font><br>

<dd><font face="arial" size=2 color="#000080">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Yes I totally agree with your analysis.<br>
</font><br>

<dd><font face="arial" size=2 color="#000080">&nbsp;<br>
</font><br>

<dd><font face="arial" size=2 color="#000080">The is not going to redefine or reinvent the OAM that, as Thomas as pointed out, is done by IEEE, the ID just specify how to use a control plane mechanism (GMPLS) set-up at the same time data plane circuit and the related OAM.<br>
</font><br>

<dd><font face="arial" size=2 color="#000080">&nbsp;<br>
</font><br>

<dd><font face="arial" size=2 color="#000080">Frankly specking I don$BCU(B see any layer violation here.<br>
</font><br>

<dd><font face="arial" size=2 color="#000080">&nbsp;<br>
</font><br>

<dd><font face="arial" size=2 color="#000080">BR<br>
</font><br>

<dd><font face="arial" size=2 color="#000080">&nbsp;<br>
</font><br>

<dd><font face="arial" size=2 color="#000080">Diego<br>
</font><br>

<dd><font face="arial" size=2 color="#000080">&nbsp;<br>
<hr>
<div align="center"></font></div>

<dd><font face="tahoma" size=2>From:</b> <a href="mailto:[email-masked]">[email-masked]</a> [<a href="mailto:[email-masked]" eudora="autourl">mailto:[email-masked]</a>] <br>

<dd>Sent:</b> marted$Bw(B4 dicembre 2007 22.55<br>

<dd>To:</b> Attila Takacs; <a href="mailto:[email-masked]">[email-masked]</a>; Diego Caviglia<br>

<dd>Cc:</b> <a href="mailto:[email-masked]">[email-masked]</a><br>

<dd>Subject:</b> RE: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt<br>
</font><br>

<dd><font face="times new roman">&nbsp;<br>
</font><br>

<dd><font face="comic sans ms" size=2 color="#800000">I'm puzzled.&nbsp; I read the draft and thought it was excellent.&nbsp; It is addressing an important operational issue, ie a critical operational OAM requirement is to ensure that whatever mechanism (MP or CP) is used to set-up/tear-down a connection (so this only applies to co-cs or co-ps modes....the cl-ps mode does not have connections of course) is harmonised to the activation/deactivation of the OAM.....specifically a CV/CC flow.&nbsp;&nbsp; If we don't ensure this then there will be obvious operational problems.&nbsp; This is essentially what the draft is about.<br>
</font><br>

<dd><font face="times new roman">&nbsp;<br>
</font><br>

<dd><font face="comic sans ms" size=2 color="#800000">Further, GMPLS is a generic OOB CP technique.....it is not a specific layer network technology per se (but it is specific in it's choice of signalling and routing components).&nbsp; So one can apply a largely similar (GMPLS) CP technique to all co-cs mode technologies (whether they are partitioning a space, freq or time resource - see Note) and co-ps mode technologies (which only applies to partitioning a time resource - see Note) on the assumption that the technology is correctly architected in the DP for the mode considered.&nbsp; It's pretty hard not to correctly architect the co-cs mode, but it's quite easy to incorrectly architect the co-ps mode, eg one can't violate the rules of a connection in the co-cs mode but one can in the co-ps mode.<br>
</font><br>

<dd><font face="times new roman">&nbsp;<br>
</font><br>

<dd><font face="comic sans ms" size=2 color="#800000">Note - When we partition a time resource in regular time-slices we create a co-cs mode layer network.&nbsp; When we partition a time resource in irregular time-slices we create a co-ps mode layer network.&nbsp; More information on labelling and resource partitioning can be found in the work on unified modelling (of networks) in G.800.<br>
</font><br>

<dd><font face="times new roman">&nbsp;<br>
</font><br>

<dd><font face="comic sans ms" size=2 color="#800000">regards, Neil<br>
</font><br>

<dd><font face="tahoma" size=2>-----Original Message-----<br>

<dd>From:</b> [email-masked] [<a href="mailto:[email-masked]" eudora="autourl">mailto:[email-masked]</a>] On Behalf Of </b>Attila Takacs<br>

<dd>Sent:</b> 05 December 2007 02:03<br>

<dd>To:</b> Thomas Nadeau; Diego Caviglia<br>

<dd>Cc:</b> [email-masked]<br>

<dd>Subject:</b> RE: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt<br>
</font><br>

<dd><font face="arial" size=2 color="#0000FF">Hi Tom,<br>
</font><br>

<dd><font face="arial" size=2 color="#0000FF">please see inline.<br>
</font><br>

<dd><font face="arial" size=2 color="#0000FF">Best regards,<br>
</font><br>

<dd><font face="arial" size=2 color="#0000FF">Attila<br>
</font><br>

<dd><font face="times new roman">&nbsp;<br>
<hr>
<div align="center"></font></div>

<dd><font face="tahoma" size=2>From:</b> Thomas Nadeau [<a href="mailto:[email-masked]" eudora="autourl">mailto:[email-masked]</a>] <br>

<dd>Sent:</b> Wednesday, December 05, 2007 2:19 AM<br>

<dd>To:</b> Diego Caviglia<br>

<dd>Cc:</b> Attila Takacs; [email-masked]; [email-masked]<br>

<dd>Subject:</b> Re: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt<br>
</font><br>

<dd><font face="times new roman">&nbsp;<br>
</font><br>

<dd><font face="times new roman">On Dec 4, 2007, at 7:33 PM, Diego Caviglia wrote:<br>
</font><br>
<font face="times new roman"><br><br>
</font>
<dd><font face="arial" size=2 color="#000080">Hi Thomas,<br>
</font><br>

<dd><font face="arial" size=2 color="#000080">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; My understanding of the ID was that RSVP-TE can be used to $BAQ(Biggyback$BC(BCFM set-up, otherwise the scenario is: usage of RSVP-TE to set-up the LSP and NMS (meaning everything that is not control plane) to enable to CFM for the LSP.<br>
</font><br>

<dd><font face="times new roman">&nbsp;<br>
</font><br>

<dd><font face="times new roman">As I understand it, the IEEE is working on set-up of CFM (and MEPs), as are some vendors I know. *)<br>
</font><br>

<dd><font face="times new roman">This to me seems like the right way to do this.<br>
</font><br>

<dd><font face="times new roman">&nbsp;<br>
</font><br>

</dl><font face="arial" size=2 color="#0000FF">IEEE specified CFM and MIBs to setup CFM. <br>
</font><br>
<font face="arial" size=2 color="#0000FF">Diego's summary is correct: one can use an NMS or a control plane to setup the data plane. In this case we propose to use GMPLS to setup the data plane: both forwarding + OAM.<br>
</font><blockquote type=cite>
<dl><br>

<dd><font face="times new roman" size=2 color="#144FAE">From your comment I see that you$BCS(Be not happy with the fact the ID is so technology specific am I right?&nbsp; <br>
</font><br>

</dl><font face="times new roman">&nbsp;<br>
</font><br>
<font face="times new roman">Precisely; its gluing CFM to RSVP-TE/GMPLS as a transport. </font></blockquote><br>
<font face="arial" size=2 color="#0000FF">I do not see your point with gluing. What do you mean by &quot;as transport&quot;? GMPLS is just controlling OAM, CFM is run solely in the data plane.<br>
</font><br>
<font face="times new roman">&nbsp;<br>
</font><br>
<font face="times new roman">&nbsp;<br>
</font><blockquote type=cite>
<dl><br>

<dd><font face="times new roman" size=2 color="#144FAE">If yes do you agree with the fact that could be useful in general to use the same signaling $BAT(Bession$BC(Bto set-up the LSP and to enable the CFM?<br>
</font><br>

</dl><font face="times new roman">&nbsp;<br>
</font><br>
<font face="times new roman">No, I do not agree.&nbsp; Again, if CFM is to be set-up e2e, let the IEEE define this. Leave GMPLS to CCAMP.</font></blockquote><br>
<font face="times new roman">&nbsp;<br>
</font><br>
<font face="times new roman">&nbsp;<br>
</font><br>
<font face="arial" size=2 color="#0000FF">Sorry, I cannot follow.<br>
</font><br>
<font face="times new roman">&nbsp;<br>
</font><br>
<font face="times new roman">&nbsp;<br>
</font>
<dl><br>

<dd><font face="times new roman">&nbsp;<br>
</font><br>

<dd><font face="times new roman">&nbsp;<br>
</font><br>

<dd><font face="times new roman">&nbsp;<br>
</font><br>

<dd><font face="times new roman">--Tom<br>
</font><br>

<dd><font face="times new roman">&nbsp;<br>
</font><br>

<dd><font face="times new roman">&nbsp;<br>
</font><br>
<font face="times new roman"><br><br>
</font>
<dd><font face="arial" size=2 color="#000080">&nbsp;</font><font face="arial" size=2 color="#144FAE">Best Regards<br>
</font><br>
<font face="arial" size=2 color="#000080"><br>

<dd>Diego<br>
<hr>
<div align="center"></font></div>

<dd><font face="tahoma" size=2>From:</b> <a href="mailto:[email-masked]">[email-masked]</a> [<a href="mailto:[email-masked]">mailto:[email-masked]</a>] On Behalf Of </b>Thomas Nadeau<br>

<dd>Sent:</b> marted$Bw(B4 dicembre 2007 11.30<br>

<dd>To:</b> Attila Takacs<br>

<dd>Cc:</b> <a href="mailto:[email-masked]">[email-masked]</a>; <a href="mailto:[email-masked]">[email-masked]</a><br>

<dd>Subject:</b> Re: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt<br>
</font><br>

<dd><font face="times new roman">On Dec 4, 2007, at 1:51 PM, Attila Takacs wrote:<br>
</font><br>
<font face="times new roman"><br><br>
<br>
</font>
<dd><font face="arial" size=2 color="#0000FF">Hi Thomas,<br>
</font><br>

<dd><font face="arial" size=2 color="#0000FF">Thank you for the comments!<br>
</font><br>

<dd><font face="arial" size=2 color="#0000FF">Please see answers inline.<br>
</font><br>

<dd><font face="arial" size=2 color="#0000FF">Best regards,<br>

<dd>Attila<br>
<hr>
<div align="center"></font></div>

<dd><font face="tahoma" size=2>From:</b> Thomas Nadeau [<a href="mailto:[email-masked]">mailto:[email-masked]</a>] <br>

<dd>Sent:</b> Tuesday, December 04, 2007 2:58 PM<br>

<dd>To:</b> <a href="mailto:[email-masked]">[email-masked]</a><br>

<dd>Cc:</b> Attila Takacs; <a href="mailto:[email-masked]">[email-masked]</a><br>

<dd>Subject:</b> draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt<br>
</font><br>

<dd><font face="times new roman">After reading this draft, I have some questions/comments.<br>
</font><br>

<dd><font face="times new roman">1) Overall, I am concerned that the definition of a new TLV and these procedures represent <br>
</font><br>

<dd><font face="times new roman">what amounts to a laying violation and ask that the ADs take a look at this<br>
</font><br>

<dd><font face="times new roman">approach closely. This is similar to the now-rejected approach that was proposed<br>
</font><br>

<dd><font face="times new roman">in the l2vpn WG about munging CFM + PWs.&nbsp; To my reading, this is essentially<br>
</font><br>

<dd><font face="times new roman">the same thing. If you want to run CFM, run it natively over the ethernet interfaces and<br>
</font><br>

<dd><font face="times new roman">have no regard for the underlying topology (GMPLS, PWs, etc...) otherwise you <br>
</font><br>

<dd><font face="times new roman">will be creating a mess for implementations and interoperability. </font><font face="arial" size=2 color="#0000FF"> <br>
</font><br>

</dl><font face="arial" size=2 color="#0000FF">The application of the draft is exactly for what you are calling out: when CFM is run natively over the Ethernet interfaces. The document focuses on GELS and Ethernet LSPs. That is, to establish CFM entities for GMPLS controlled Ethernet LSPs. Hence, I think there is no layer violation issue.<br>
</font><br>
<font face="times new roman">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </font> This solution specifically only works for GMPLS ethernet LSPs, right?&nbsp; <br><br>
<font face="times new roman">What do I do if I want to set up MPLS ethernet LSPs (i.e.: PWs) and do CFM over those? Oh,<br>
</font><br>
<font face="times new roman">that is a different solution, right?&nbsp; Then what do I do if I want to run CFM over some new type of<br>
</font><br>
<font face="times new roman">ethernet LSP in the future? More protocol hacks?&nbsp; The point is to use CFM over an ethernet interface<br>
</font><br>
<font face="times new roman">without the underlying layers knowing. This is good networking architecture design, that simplifies<br>
</font><br>
<font face="times new roman">implementations and makes them more robust, as well as makes using them operationally much<br>
</font><br>
<font face="times new roman">easier. <br>
</font><blockquote type=cite>
<dl><br>

<dd><font face="times new roman">2) The introductory sections in this draft give a lot of discussion about fast fault detection. I<br>
</font><br>

<dd><font face="times new roman">am puzzled by this given that GMPLS networks tend to run over quickly self-healing<br>
</font><br>

<dd><font face="times new roman">optical infrastructures. Is it therefore truly necessary to motivate this work by<br>
</font><br>

<dd><font face="times new roman">requiring fast CFMs?<br>
</font><br>

</dl><font face="arial" size=2 color="#0000FF">It is right that frequent CCMs are not required if the layers below Ethernet handle protection. However, the ID focuses on Ethernet LSPs where Ethernet is not just a single hop above a transport LSP. In this case Ethernet layer (for clarity GELS) may provide protection for Ethernet LSPs. In any case,&nbsp; the whole point of the ID is to allow for the appropriate configuration of CFM for Ethernet LSPs with GMPLS.<br>
</font>
<dl><br>

<dd><font face="times new roman">3) This document does not cover E-LMI. Why not?<br>
</font><br>

</dl><font face="arial" size=2 color="#0000FF">E-LMI is run over the MEF UNI. The ID focuses on Ethernet LSPs within a network.<br>
</font>
<dl><br>

<dd><font face="times new roman" size=1>For the purposes of this document, we only discuss Ethernet OAM<br>
</font><br>

<dd><font face="helvetica" size=1>&nbsp;&nbsp; [IEEE-CFM] aspects that are relevant for the connectivity monitoring<br>
</font><br>

<dd><font face="helvetica" size=1>&nbsp;&nbsp; of bidirectional point-to-point PBB-TE connections.&nbsp; <br>
</font><br>

<dd><font face="helvetica" size=1>4) Is this the right place to define this document or should this be done in GELS?<br>
</font><br>

</dl><font face="arial" size=2 color="#0000FF">Well, GELS is done in CCAMP...this seems to be the right place.<br>
</font>
<dl><br>

<dd><font face="helvetica" size=1>5)&nbsp;&nbsp; In section 2 you make the following statement:<br>
</font><br>

<dd><font face="helvetica" size=1>2.&nbsp; GMPLS RSVP-TE Extensions<br>
</font><br>

<dd><font face="helvetica" size=1>&nbsp;&nbsp;&nbsp; To simplify the configuration of connectivity monitoring, when an<br>
</font><br>

<dd><font face="helvetica" size=1>&nbsp;&nbsp; Ethernet LSP is signalled the associated MEPs should be automatically<br>
</font><br>

<dd><font face="helvetica" size=1>&nbsp;&nbsp;&nbsp; established.&nbsp; Further more, GMPLS signalling should be able to<br>
</font><br>

<dd><font face="helvetica" size=1>&nbsp; enable/disable connectivity monitoring of a particular Ethernet LSP.<br>
</font><br>

<dd><font face="helvetica" size=1>To my point in #1 above, you should use the native CFM functionality over the ethernet interface and signal<br>
</font><br>

<dd><font face="helvetica" size=1>those capabilities to the bridges at both ends using the IEEE CFM signaling procedures (when and if they<br>
</font><br>

<dd><font face="helvetica" size=1>are created).&nbsp; If you want to test the underlying GMPLS LSP(s), then you should use some<br>
</font><br>

<dd><font face="helvetica" size=1>other mechanism defined for that layer such as the work stated in </font><font face="helvetica" size=2>draft-ali-ccamp-gmpls-LSP-ping-traceroute-00.txt<br>
</b></font><br>

</dl><font face="arial" size=2 color="#0000FF">See the note to your point #1. There is no relation to the gmpls-LSP-ping draft. </font></blockquote><br>
<font face="times new roman">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </font> The point I am making is that perhaps it should.<br><br>
<font face="times new roman">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </font> --Tom<br><br>
<font face="times new roman">&nbsp;<br>
</font></blockquote>
<x-sigsep><p></x-sigsep>
-------------------------------------<br>
Wataru Imajuku, Ph.D.@NTT Network Innovation Labs<br>
TEL: +81-46-859-4315<br>
FAX: +81-46-859-5541<br>
</body>
</html>

Delivery-date: Wed, 05 Dec 2007 20:39:03 +0000
Date: Wed, 05 Dec 2007 21:36:54 +0100
From: Loa Andersson <[email-masked]>
Organization: Acreo AB
To: Dan Li <[email-masked]>
CC: Diego Caviglia <[email-masked]>, [email-masked],  Attila Takacs <[email-masked]>, [email-masked], [email-masked]
Subject: Re: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt

All,

I'm normally a bit careful with models "layer networks" that seems
to be a rather cumbersome way of explaining the obvious; however
in this case when it is used demonstrate that no layer violation
is at hand I is inclined to accept that result.

I also agree with Dan that it seems to be a good idea to use
RSVP-TE to provision OAM functionality is a good idea.

With that it we should just go ahead and accept this as a
ccamp work item.

/Loa

Dan Li wrote:
> MessageHi,
> 
> I think there is a misunderstanding with respect to the objective of this draft. 
> 
> As I read this draft, it describes how to extend the RSVP protocol 

to support the configuration/enable the OAM function of Ethernet LSP,

which I think is a good thing to do, it is not saying to use signaling

protocol to do the OAM work. But anyway, it may be necessary to clarify

the objective at the beginning of this draft.
> 
> Regards,
> 
> Dan
> 
> 
>   ----- Original Message ----- 
>   From: Diego Caviglia 
>   To: [email-masked] ; Attila Takacs ; [email-masked] 
>   Cc: [email-masked] 
>   Sent: Thursday, December 06, 2007 12:27 AM
>   Subject: RE: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt
> 
> 
>   Hi Neil,
> 
>              Yes I totally agree with your analysis.
> 
>    
> 
>   The is not going to redefine or reinvent the OAM that, as Thomas as pointed out, is done by IEEE, the ID just specify how to use a control plane mechanism (GMPLS) set-up at the same time data plane circuit and the related OAM.
> 
>    
> 
>   Frankly specking I don't see any layer violation here.
> 
>    
> 
>   BR
> 
>    
> 
>   Diego
> 
>    
> 
> 
> ------------------------------------------------------------------------------
> 
>   From: [email-masked] [mailto:[email-masked]] 
>   Sent: martedì 4 dicembre 2007 22.55
>   To: Attila Takacs; [email-masked]; Diego Caviglia
>   Cc: [email-masked]
>   Subject: RE: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt
> 
>    
> 
>   I'm puzzled.  I read the draft and thought it was excellent.  It is addressing an important operational issue, ie a critical operational OAM requirement is to ensure that whatever mechanism (MP or CP) is used to set-up/tear-down a connection (so this only applies to co-cs or co-ps modes....the cl-ps mode does not have connections of course) is harmonised to the activation/deactivation of the OAM.....specifically a CV/CC flow.   If we don't ensure this then there will be obvious operational problems.  This is essentially what the draft is about.
> 
>    
> 
>   Further, GMPLS is a generic OOB CP technique.....it is not a specific layer network technology per se (but it is specific in it's choice of signalling and routing components).  So one can apply a largely similar (GMPLS) CP technique to all co-cs mode technologies (whether they are partitioning a space, freq or time resource - see Note) and co-ps mode technologies (which only applies to partitioning a time resource - see Note) on the assumption that the technology is correctly architected in the DP for the mode considered.  It's pretty hard not to correctly architect the co-cs mode, but it's quite easy to incorrectly architect the co-ps mode, eg one can't violate the rules of a connection in the co-cs mode but one can in the co-ps mode.
> 
>    
> 
>   Note - When we partition a time resource in regular time-slices we create a co-cs mode layer network.  When we partition a time resource in irregular time-slices we create a co-ps mode layer network.  More information on labelling and resource partitioning can be found in the work on unified modelling (of networks) in G.800.
> 
>    
> 
>   regards, Neil
> 
>     -----Original Message-----
>     From: [email-masked] [mailto:[email-masked]] On Behalf Of Attila Takacs
>     Sent: 05 December 2007 02:03
>     To: Thomas Nadeau; Diego Caviglia
>     Cc: [email-masked]
>     Subject: RE: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt
> 
>     Hi Tom,
> 
>     please see inline.
> 
>     Best regards,
> 
>     Attila
> 
>        
> 
> 
> --------------------------------------------------------------------------
> 
>       From: Thomas Nadeau [mailto:[email-masked]] 
>       Sent: Wednesday, December 05, 2007 2:19 AM
>       To: Diego Caviglia
>       Cc: Attila Takacs; [email-masked]; [email-masked]
>       Subject: Re: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt
> 
>        
> 
>       On Dec 4, 2007, at 7:33 PM, Diego Caviglia wrote:
> 
> 
> 
> 
> 
>       Hi Thomas,
> 
>                        My understanding of the ID was that RSVP-TE can be used to 'piggyback' CFM set-up, otherwise the scenario is: usage of RSVP-TE to set-up the LSP and NMS (meaning everything that is not control plane) to enable to CFM for the LSP.
> 
>        
> 
>       As I understand it, the IEEE is working on set-up of CFM (and MEPs), as are some vendors I know. *)
> 
>       This to me seems like the right way to do this.
> 
>        
> 
>     IEEE specified CFM and MIBs to setup CFM. 
> 
>     Diego's summary is correct: one can use an NMS or a control plane to setup the data plane. In this case we propose to use GMPLS to setup the data plane: both forwarding + OAM.
> 
>         From your comment I see that you're not happy with the fact the ID is so technology specific am I right?  
> 
>        
> 
>       Precisely; its gluing CFM to RSVP-TE/GMPLS as a transport. 
> 
>     I do not see your point with gluing. What do you mean by "as transport"? GMPLS is just controlling OAM, CFM is run solely in the data plane.
> 
>      
> 
>      
> 
>         If yes do you agree with the fact that could be useful in general to use the same signaling 'session' to set-up the LSP and to enable the CFM?
> 
>        
> 
>       No, I do not agree.  Again, if CFM is to be set-up e2e, let the IEEE define this. Leave GMPLS to CCAMP.
> 
>      
> 
>      
> 
>     Sorry, I cannot follow.
> 
>      
> 
>      
> 
>        
> 
>        
> 
>        
> 
>       --Tom
> 
>        
> 
>        
> 
> 
> 
> 
> 
>        Best Regards
> 
> 
>       Diego
> 
> 
> --------------------------------------------------------------------------
> 
>       From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas Nadeau
>       Sent: martedì 4 dicembre 2007 11.30
>       To: Attila Takacs
>       Cc: [email-masked]; [email-masked]
>       Subject: Re: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt
> 
>       On Dec 4, 2007, at 1:51 PM, Attila Takacs wrote:
> 
> 
> 
> 
> 
> 
>       Hi Thomas,
> 
>       Thank you for the comments!
> 
>       Please see answers inline.
> 
>       Best regards,
>       Attila
> 
> 
> ------------------------------------------------------------------------
> 
>         From: Thomas Nadeau [mailto:[email-masked]] 
>         Sent: Tuesday, December 04, 2007 2:58 PM
>         To: [email-masked]
>         Cc: Attila Takacs; [email-masked]
>         Subject: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt
> 
>         After reading this draft, I have some questions/comments.
> 
>         1) Overall, I am concerned that the definition of a new TLV and these procedures represent 
> 
>         what amounts to a laying violation and ask that the ADs take a look at this
> 
>         approach closely. This is similar to the now-rejected approach that was proposed
> 
>         in the l2vpn WG about munging CFM + PWs.  To my reading, this is essentially
> 
>         the same thing. If you want to run CFM, run it natively over the ethernet interfaces and
> 
>         have no regard for the underlying topology (GMPLS, PWs, etc...) otherwise you 
> 
>         will be creating a mess for implementations and interoperability.  
> 
>       The application of the draft is exactly for what you are calling out: when CFM is run natively over the Ethernet interfaces. The document focuses on GELS and Ethernet LSPs. That is, to establish CFM entities for GMPLS controlled Ethernet LSPs. Hence, I think there is no layer violation issue.
> 
>                 This solution specifically only works for GMPLS ethernet LSPs, right?  
> 
>       What do I do if I want to set up MPLS ethernet LSPs (i.e.: PWs) and do CFM over those? Oh,
> 
>       that is a different solution, right?  Then what do I do if I want to run CFM over some new type of
> 
>       ethernet LSP in the future? More protocol hacks?  The point is to use CFM over an ethernet interface
> 
>       without the underlying layers knowing. This is good networking architecture design, that simplifies
> 
>       implementations and makes them more robust, as well as makes using them operationally much
> 
>       easier. 
> 
>           2) The introductory sections in this draft give a lot of discussion about fast fault detection. I
> 
>           am puzzled by this given that GMPLS networks tend to run over quickly self-healing
> 
>           optical infrastructures. Is it therefore truly necessary to motivate this work by
> 
>           requiring fast CFMs?
> 
>         It is right that frequent CCMs are not required if the layers below Ethernet handle protection. However, the ID focuses on Ethernet LSPs where Ethernet is not just a single hop above a transport LSP. In this case Ethernet layer (for clarity GELS) may provide protection for Ethernet LSPs. In any case,  the whole point of the ID is to allow for the appropriate configuration of CFM for Ethernet LSPs with GMPLS.
> 
>           3) This document does not cover E-LMI. Why not?
> 
>         E-LMI is run over the MEF UNI. The ID focuses on Ethernet LSPs within a network.
> 
>           For the purposes of this document, we only discuss Ethernet OAM
> 
>              [IEEE-CFM] aspects that are relevant for the connectivity monitoring
> 
>              of bidirectional point-to-point PBB-TE connections.  
> 
>           4) Is this the right place to define this document or should this be done in GELS?
> 
>         Well, GELS is done in CCAMP...this seems to be the right place.
> 
>           5)   In section 2 you make the following statement:
> 
>           2.  GMPLS RSVP-TE Extensions
> 
>               To simplify the configuration of connectivity monitoring, when an
> 
>              Ethernet LSP is signalled the associated MEPs should be automatically
> 
>               established.  Further more, GMPLS signalling should be able to
> 
>             enable/disable connectivity monitoring of a particular Ethernet LSP.
> 
>           To my point in #1 above, you should use the native CFM functionality over the ethernet interface and signal
> 
>           those capabilities to the bridges at both ends using the IEEE CFM signaling procedures (when and if they
> 
>           are created).  If you want to test the underlying GMPLS LSP(s), then you should use some
> 
>           other mechanism defined for that layer such as the work stated in draft-ali-ccamp-gmpls-LSP-ping-traceroute-00.txt
> 
>         See the note to your point #1. There is no relation to the gmpls-LSP-ping draft. 
> 
>                 The point I am making is that perhaps it should.
> 
>                 --Tom
> 
>        
> 

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

This email was Anti Virus checked by Astaro Security Gateway. http://www.astaro.com

Delivery-date: Wed, 05 Dec 2007 19:39:48 +0000
Content-class: urn:content-classes:message
Subject: RE: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt
Date: Wed, 5 Dec 2007 20:37:16 +0100
From: "Attila Takacs" <[email-masked]>
To: "Dan Li" <[email-masked]>, "Diego Caviglia" <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C83776.3E1B4EEC
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi all,
=20
Neil's and Dan's summary are exact. Thanks for your comments!
=20
Maybe the title of the ID caused the misunderstanding, it would say more =
if it would read: "GMPLS RSVP-TE Extensions to *Control* Ethernet OAM".
Nevertheless, when updating the ID we will clarify our point even more.
=20
Best regards,
Attila

________________________________

	From: Dan Li [mailto:[email-masked]]=20
	Sent: Wednesday, December 05, 2007 6:01 PM
	To: Diego Caviglia; [email-masked]; Attila Takacs; =
[email-masked]
	Cc: [email-masked]
	Subject: Re: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt
=09
=09
	Hi,
	=20
	I think there is a misunderstanding with respect to the objective of =
this draft.=20
	=20
	As I read this draft, it describes how to extend the RSVP protocol to =
support the configuration/enable the OAM function of Ethernet LSP, which =
I think is a good thing to do, it is not saying to use signaling =
protocol to do the OAM work. But anyway, it may be necessary to clarify =
the objective at the beginning of this draft.
	=20
	Regards,
	=20
	Dan
	=20
	=20

		----- Original Message -----=20
		From: Diego Caviglia <mailto:[email-masked]> =20
		To: [email-masked] ; Attila Takacs =
<mailto:[email-masked]>  ; [email-masked]=20
		Cc: [email-masked]=20
		Sent: Thursday, December 06, 2007 12:27 AM
		Subject: RE: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt

		Hi Neil,

		           Yes I totally agree with your analysis.

		=20

		The is not going to redefine or reinvent the OAM that, as Thomas as =
pointed out, is done by IEEE, the ID just specify how to use a control =
plane mechanism (GMPLS) set-up at the same time data plane circuit and =
the related OAM.

		=20

		Frankly specking I don't see any layer violation here.

		=20

		BR

		=20

		Diego

		=20

	=09
________________________________

		From: [email-masked] [mailto:[email-masked]]=20
		Sent: marted=EC 4 dicembre 2007 22.55
		To: Attila Takacs; [email-masked]; Diego Caviglia
		Cc: [email-masked]
		Subject: RE: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt

		=20

		I'm puzzled.  I read the draft and thought it was excellent.  It is =
addressing an important operational issue, ie a critical operational OAM =
requirement is to ensure that whatever mechanism (MP or CP) is used to =
set-up/tear-down a connection (so this only applies to co-cs or co-ps =
modes....the cl-ps mode does not have connections of course) is =
harmonised to the activation/deactivation of the OAM.....specifically a =
CV/CC flow.   If we don't ensure this then there will be obvious =
operational problems.  This is essentially what the draft is about.

		=20

		Further, GMPLS is a generic OOB CP technique.....it is not a specific =
layer network technology per se (but it is specific in it's choice of =
signalling and routing components).  So one can apply a largely similar =
(GMPLS) CP technique to all co-cs mode technologies (whether they are =
partitioning a space, freq or time resource - see Note) and co-ps mode =
technologies (which only applies to partitioning a time resource - see =
Note) on the assumption that the technology is correctly architected in =
the DP for the mode considered.  It's pretty hard not to correctly =
architect the co-cs mode, but it's quite easy to incorrectly architect =
the co-ps mode, eg one can't violate the rules of a connection in the =
co-cs mode but one can in the co-ps mode.

		=20

		Note - When we partition a time resource in regular time-slices we =
create a co-cs mode layer network.  When we partition a time resource in =
irregular time-slices we create a co-ps mode layer network.  More =
information on labelling and resource partitioning can be found in the =
work on unified modelling (of networks) in G.800.

		=20

		regards, Neil

			-----Original Message-----
			From: [email-masked] [mailto:[email-masked]] On =
Behalf Of Attila Takacs
			Sent: 05 December 2007 02:03
			To: Thomas Nadeau; Diego Caviglia
			Cc: [email-masked]
			Subject: RE: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt

			Hi Tom,

			please see inline.

			Best regards,

			Attila

				=20

			=09
________________________________

				From: Thomas Nadeau [mailto:[email-masked]]=20
				Sent: Wednesday, December 05, 2007 2:19 AM
				To: Diego Caviglia
				Cc: Attila Takacs; [email-masked]; [email-masked]
				Subject: Re: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt

				=20

				On Dec 4, 2007, at 7:33 PM, Diego Caviglia wrote:

			=09
			=09
			=09

			=09

				Hi Thomas,

				                 My understanding of the ID was that RSVP-TE can be =
used to 'piggyback' CFM set-up, otherwise the scenario is: usage of =
RSVP-TE to set-up the LSP and NMS (meaning everything that is not =
control plane) to enable to CFM for the LSP.

				=20

				As I understand it, the IEEE is working on set-up of CFM (and MEPs), =
as are some vendors I know. *)

				This to me seems like the right way to do this.

				=20

			IEEE specified CFM and MIBs to setup CFM.=20

			Diego's summary is correct: one can use an NMS or a control plane to =
setup the data plane. In this case we propose to use GMPLS to setup the =
data plane: both forwarding + OAM.

			=09

				=09

					From your comment I see that you're not happy with the fact the ID =
is so technology specific am I right? =20

				=20

				Precisely; its gluing CFM to RSVP-TE/GMPLS as a transport.=20

			I do not see your point with gluing. What do you mean by "as =
transport"? GMPLS is just controlling OAM, CFM is run solely in the data =
plane.

			=20

			=20

			=09

				=09

					If yes do you agree with the fact that could be useful in general =
to use the same signaling 'session' to set-up the LSP and to enable the =
CFM?

				=20

				No, I do not agree.  Again, if CFM is to be set-up e2e, let the IEEE =
define this. Leave GMPLS to CCAMP.

			=20

			=20

			Sorry, I cannot follow.

			=20

			=20

				=20

				=20

				=20

				--Tom

				=20

				=20

			=09
			=09
			=09

			=09

				 Best Regards

			=09
				Diego

			=09
			=09
________________________________

				From: [email-masked] [mailto:[email-masked]] On =
Behalf Of Thomas Nadeau
				Sent: marted=EC 4 dicembre 2007 11.30
				To: Attila Takacs
				Cc: [email-masked]; [email-masked]
				Subject: Re: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt

				On Dec 4, 2007, at 1:51 PM, Attila Takacs wrote:

			=09
			=09
			=09
			=09

				Hi Thomas,

				Thank you for the comments!

				Please see answers inline.

				Best regards,
				Attila

			=09

				=09
________________________________

					From: Thomas Nadeau [mailto:[email-masked]]=20
					Sent: Tuesday, December 04, 2007 2:58 PM
					To: [email-masked]
					Cc: Attila Takacs; [email-masked]
					Subject: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt

					After reading this draft, I have some questions/comments.

					1) Overall, I am concerned that the definition of a new TLV and =
these procedures represent=20

					what amounts to a laying violation and ask that the ADs take a look =
at this

					approach closely. This is similar to the now-rejected approach that =
was proposed

					in the l2vpn WG about munging CFM + PWs.  To my reading, this is =
essentially

					the same thing. If you want to run CFM, run it natively over the =
ethernet interfaces and

					have no regard for the underlying topology (GMPLS, PWs, etc...) =
otherwise you=20

					will be creating a mess for implementations and interoperability. =20

				The application of the draft is exactly for what you are calling =
out: when CFM is run natively over the Ethernet interfaces. The document =
focuses on GELS and Ethernet LSPs. That is, to establish CFM entities =
for GMPLS controlled Ethernet LSPs. Hence, I think there is no layer =
violation issue.

				          This solution specifically only works for GMPLS ethernet =
LSPs, right? =20

				What do I do if I want to set up MPLS ethernet LSPs (i.e.: PWs) and =
do CFM over those? Oh,

				that is a different solution, right?  Then what do I do if I want to =
run CFM over some new type of

				ethernet LSP in the future? More protocol hacks?  The point is to =
use CFM over an ethernet interface

				without the underlying layers knowing. This is good networking =
architecture design, that simplifies

				implementations and makes them more robust, as well as makes using =
them operationally much

				easier.=20

					2) The introductory sections in this draft give a lot of discussion =
about fast fault detection. I

					am puzzled by this given that GMPLS networks tend to run over =
quickly self-healing

					optical infrastructures. Is it therefore truly necessary to =
motivate this work by

					requiring fast CFMs?

					It is right that frequent CCMs are not required if the layers below =
Ethernet handle protection. However, the ID focuses on Ethernet LSPs =
where Ethernet is not just a single hop above a transport LSP. In this =
case Ethernet layer (for clarity GELS) may provide protection for =
Ethernet LSPs. In any case,  the whole point of the ID is to allow for =
the appropriate configuration of CFM for Ethernet LSPs with GMPLS.

					3) This document does not cover E-LMI. Why not?

					E-LMI is run over the MEF UNI. The ID focuses on Ethernet LSPs =
within a network.

					For the purposes of this document, we only discuss Ethernet OAM

					   [IEEE-CFM] aspects that are relevant for the connectivity =
monitoring

					   of bidirectional point-to-point PBB-TE connections. =20

					4) Is this the right place to define this document or should this =
be done in GELS?

					Well, GELS is done in CCAMP...this seems to be the right place.

					5)   In section 2 you make the following statement:

					2.  GMPLS RSVP-TE Extensions

					    To simplify the configuration of connectivity monitoring, when =
an

					   Ethernet LSP is signalled the associated MEPs should be =
automatically

					    established.  Further more, GMPLS signalling should be able to

					  enable/disable connectivity monitoring of a particular Ethernet =
LSP.

					To my point in #1 above, you should use the native CFM =
functionality over the ethernet interface and signal

					those capabilities to the bridges at both ends using the IEEE CFM =
signaling procedures (when and if they

					are created).  If you want to test the underlying GMPLS LSP(s), =
then you should use some

					other mechanism defined for that layer such as the work stated in =
draft-ali-ccamp-gmpls-LSP-ping-traceroute-00.txt

					See the note to your point #1. There is no relation to the =
gmpls-LSP-ping draft.=20

				          The point I am making is that perhaps it should.

				          --Tom

				=20

------_=_NextPart_001_01C83776.3E1B4EEC
Content-Type: text/html;
	charset="iso-8859-1"
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:st1 =3D=20
"urn:schemas-microsoft-com:office:smarttags"><HEAD><TITLE>Message</TITLE>=

<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1589" 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"=20
name=3D"PersonName"></o:SmartTagType><!--[if !mso]>
<STYLE>st1\:* {
	BEHAVIOR: url(#default#ieooui)
}
</STYLE>
<![endif]-->
<STYLE>@font-face {
	font-family: Helvetica;
}
@font-face {
	font-family: Tahoma;
}
@font-face {
	font-family: Comic Sans MS;
}
@page Section1 {size: 612.0pt 792.0pt; margin: 72.0pt 90.0pt 72.0pt =
90.0pt; }
P.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"
}
LI.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"
}
DIV.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 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.EmailStyle20 {
	COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal-reply
}
DIV.Section1 {
	page: Section1
}
</STYLE>
</HEAD>
<BODY lang=3DEN-US=20
style=3D"WORD-WRAP: break-word; webkit-nbsp-mode: space; =
webkit-line-break: after-white-space"=20
vLink=3Dblue link=3Dblue bgColor=3D#ffffff>
<DIV><SPAN class=3D546514718-05122007><FONT face=3DArial color=3D#0000ff =
size=3D2>Hi=20
all,</FONT></SPAN></DIV>
<DIV><SPAN class=3D546514718-05122007><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><FONT face=3DArial><FONT color=3D#0000ff><FONT size=3D2><SPAN=20
class=3D546514718-05122007>Neil's and Dan's summary are exact. Thanks =
for your=20
comments!</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT face=3DArial><FONT color=3D#0000ff><FONT size=3D2><SPAN=20
class=3D546514718-05122007></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial><FONT color=3D#0000ff><FONT size=3D2><SPAN=20
class=3D546514718-05122007>Maybe the title of the ID&nbsp;caused the=20
misunderstanding, it would say more if it would read: "</SPAN>GMPLS =
RSVP-TE=20
Extensions to&nbsp;<SPAN class=3D546514718-05122007>*</SPAN>Control<SPAN =

class=3D546514718-05122007>*</SPAN> Ethernet OAM<SPAN=20
class=3D546514718-05122007>".</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT face=3DArial><FONT color=3D#0000ff><FONT size=3D2><SPAN=20
class=3D546514718-05122007>Nevertheless, when updating the ID we=20
will&nbsp;clarify&nbsp;our point even =
more.</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT face=3DArial><FONT color=3D#0000ff><FONT size=3D2><SPAN=20
class=3D546514718-05122007></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial><FONT color=3D#0000ff><FONT size=3D2><SPAN=20
class=3D546514718-05122007>Best =
regards,</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT face=3DArial><FONT color=3D#0000ff><FONT size=3D2><SPAN=20
class=3D546514718-05122007>Attila</SPAN></FONT></FONT></FONT></DIV>
<DIV class=3DO style=3D"mso-char-wrap: 1; mso-kinsoku-overflow: 1"=20
v:shape=3D"_x0000_s1026"><FONT face=3DArial><SPAN=20
style=3D"FONT-SIZE: 24pt; COLOR: #003258; mso-bidi-font-family: =
Arial"></SPAN></FONT></DIV><FONT=20
face=3DArial color=3D#0000ff size=3D2></FONT><BR>
<BLOCKQUOTE dir=3Dltr=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> Dan Li =
[mailto:[email-masked]]=20
  <BR><B>Sent:</B> Wednesday, December 05, 2007 6:01 PM<BR><B>To:</B> =
Diego=20
  Caviglia; [email-masked]; Attila Takacs;=20
  [email-masked]<BR><B>Cc:</B> =
[email-masked]<BR><B>Subject:</B>=20
  Re: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt<BR></FONT><BR></DIV>
  <DIV></DIV>
  <DIV>Hi,</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>I think there is a misunderstanding with respect to&nbsp;the =
objective of=20
  this draft. </DIV>
  <DIV>&nbsp;</DIV>
  <DIV>As I read this draft, it describes how to&nbsp;extend =
the&nbsp;RSVP=20
  protocol to support the&nbsp;configuration/enable the OAM function of =
Ethernet=20
  LSP, which I think is a good thing to do, it is&nbsp;not saying to use =

  signaling protocol to do the OAM work. But anyway, it may be necessary =
to=20
  clarify the objective at the beginning of this draft.</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>Regards,</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>Dan</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>&nbsp;</DIV>
  <BLOCKQUOTE dir=3Dltr=20
  style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
    <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
    <DIV=20
    style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
    <A title=[email-masked]=20
    href=3D"mailto:[email-masked]">Diego Caviglia</A> =
</DIV>
    <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=[email-masked]=20
    href=3D"mailto:[email-masked]">[email-masked]</A> ; =
<A=20
    title=[email-masked]=20
    href=3D"mailto:[email-masked]">Attila Takacs</A> ; <A=20
    title=[email-masked]=20
    href=3D"mailto:[email-masked]">[email-masked]</A> =
</DIV>
    <DIV style=3D"FONT: 10pt arial"><B>Cc:</B> <A =
title=[email-masked]=20
    href=3D"mailto:[email-masked]">[email-masked]</A> </DIV>
    <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Thursday, December 06, =
2007 12:27=20
    AM</DIV>
    <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> RE:=20
    draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt</DIV>
    <DIV><BR></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
    Neil,<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;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    Yes I totally agree with your analysis.<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">The is =
not going to=20
    redefine or reinvent the OAM that, as Thomas as pointed out, is done =
by=20
    IEEE, the ID just specify how to use a control plane mechanism =
(GMPLS)=20
    set-up at the same time data plane circuit and the related=20
    OAM.<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">Frankly =
specking I=20
    don=92t see any layer violation here.<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">BR<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">Diego<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=20
    style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0cm; BORDER-TOP: =
medium none; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0cm; BORDER-LEFT: blue =
1.5pt solid; PADDING-TOP: 0cm; BORDER-BOTTOM: medium none">
    <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"> <A=20
    href=3D"mailto:[email-masked]">[email-masked]</A>=20
    [mailto:[email-masked]] <BR><B><SPAN=20
    style=3D"FONT-WEIGHT: bold">Sent:</SPAN></B> marted=EC 4 dicembre =
2007=20
    22.55<BR><B><SPAN style=3D"FONT-WEIGHT: bold">To:</SPAN></B> =
<st1:PersonName=20
    style=3D"BACKGROUND-POSITION: left bottom; BACKGROUND-IMAGE: =
url(res://ietag.dll/#34/#1001); BACKGROUND-REPEAT: repeat-x"=20
    tabIndex=3D0 w:st=3D"on">Attila Takacs</st1:PersonName>; <A=20
    href=3D"mailto:[email-masked]">[email-masked]</A>; =
Diego=20
    Caviglia<BR><B><SPAN style=3D"FONT-WEIGHT: bold">Cc:</SPAN></B> <A=20
    =
href=3D"mailto:[email-masked]">[email-masked]</A><BR><B><SPAN=20
    style=3D"FONT-WEIGHT: bold">Subject:</SPAN></B> RE:=20
    =
draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt</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>
    <P class=3DMsoNormal><FONT face=3D"Comic Sans MS" color=3Dmaroon =
size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: maroon; FONT-FAMILY: 'Comic Sans =
MS'">I'm=20
    puzzled.&nbsp; I read the draft and thought it was excellent.&nbsp; =
It is=20
    addressing an important operational issue, ie a critical operational =
OAM=20
    requirement is to ensure that whatever mechanism (MP or CP) is used =
to=20
    set-up/tear-down a connection (so this only applies to co-cs or =
co-ps=20
    modes....the cl-ps mode does not have connections of course) is =
harmonised=20
    to the activation/deactivation of the OAM.....specifically a CV/CC=20
    flow.&nbsp;&nbsp; If we don't ensure this then there will be obvious =

    operational problems.&nbsp; This is essentially what the draft is=20
    about.</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=3D"Comic Sans MS" color=3Dmaroon =
size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: maroon; FONT-FAMILY: 'Comic Sans =
MS'">Further,=20
    GMPLS is a generic&nbsp;OOB&nbsp;CP technique.....it is not a =
specific layer=20
    network technology per se (but it is specific in it's choice of =
signalling=20
    and routing components).&nbsp; So one can apply a largely similar =
(GMPLS) CP=20
    technique to all co-cs mode technologies (whether they are =
partitioning a=20
    space, freq or&nbsp;time resource - see Note) and co-ps mode =
technologies=20
    (which only applies to partitioning a time resource - see Note) on =
the=20
    assumption that the technology is correctly architected in the DP =
for the=20
    mode considered.&nbsp;&nbsp;It's pretty hard not to correctly =
architect the=20
    co-cs mode, but it's quite easy to incorrectly architect the co-ps =
mode, eg=20
    one can't violate the rules of a connection in the co-cs mode but =
one can in=20
    the co-ps mode.</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=3D"Comic Sans MS" color=3Dmaroon =
size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: maroon; FONT-FAMILY: 'Comic Sans =
MS'">Note -=20
    When we partition a time resource in regular time-slices we create a =
co-cs=20
    mode layer network.&nbsp; When we partition a time resource in =
irregular=20
    time-slices we create a co-ps mode layer network.&nbsp; More =
information on=20
    labelling and resource partitioning can be found in the work on =
unified=20
    modelling (of networks) in G.800.</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=3D"Comic Sans MS" color=3Dmaroon =
size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: maroon; FONT-FAMILY: 'Comic Sans =
MS'">regards,=20
    Neil</SPAN></FONT><o:p></o:p></P></DIV>
    <BLOCKQUOTE=20
    style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0cm; BORDER-TOP: =
medium none; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0cm; MARGIN: 5pt 0cm 5pt =
3.75pt; BORDER-LEFT: maroon 1.5pt solid; PADDING-TOP: 0cm; =
BORDER-BOTTOM: medium none">
      <P class=3DMsoNormal style=3D"MARGIN-BOTTOM: 12pt"><FONT =
face=3DTahoma=20
      size=3D2><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma">-----Original=20
      Message-----<BR><B><SPAN style=3D"FONT-WEIGHT: =
bold">From:</SPAN></B>=20
      [email-masked] [mailto:[email-masked]] =
<B><SPAN=20
      style=3D"FONT-WEIGHT: bold">On Behalf Of =
</SPAN></B><st1:PersonName=20
      style=3D"BACKGROUND-POSITION: left bottom; BACKGROUND-IMAGE: =
url(res://ietag.dll/#34/#1001); BACKGROUND-REPEAT: repeat-x"=20
      tabIndex=3D0 w:st=3D"on">Attila =
Takacs</st1:PersonName><BR><B><SPAN=20
      style=3D"FONT-WEIGHT: bold">Sent:</SPAN></B> 05 December 2007=20
      02:03<BR><B><SPAN style=3D"FONT-WEIGHT: bold">To:</SPAN></B> =
Thomas Nadeau;=20
      Diego Caviglia<BR><B><SPAN style=3D"FONT-WEIGHT: =
bold">Cc:</SPAN></B>=20
      [email-masked]<BR><B><SPAN=20
      style=3D"FONT-WEIGHT: bold">Subject:</SPAN></B> RE:=20
      =
draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt</SPAN></FONT><o:p></o:p></P=
      <DIV>
      <P class=3DMsoNormal><FONT face=3DArial color=3Dblue =
size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Hi=20
      Tom,</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">please =
see=20
      inline.</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">Best=20
      regards,</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">Attila</SPAN></FONT><o:p></o:p></P></DIV>
      <BLOCKQUOTE=20
      style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0cm; =
BORDER-TOP: medium none; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0cm; MARGIN: =
5pt 0cm 5pt 3.75pt; BORDER-LEFT: blue 1.5pt solid; PADDING-TOP: 0cm; =
BORDER-BOTTOM: medium none">
        <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
        Thomas Nadeau [mailto:[email-masked]] <BR><B><SPAN=20
        style=3D"FONT-WEIGHT: bold">Sent:</SPAN></B> Wednesday, December =
05, 2007=20
        2:19 AM<BR><B><SPAN style=3D"FONT-WEIGHT: bold">To:</SPAN></B> =
Diego=20
        Caviglia<BR><B><SPAN style=3D"FONT-WEIGHT: bold">Cc:</SPAN></B>=20
        <st1:PersonName=20
        style=3D"BACKGROUND-POSITION: left bottom; BACKGROUND-IMAGE: =
url(res://ietag.dll/#34/#1001); BACKGROUND-REPEAT: repeat-x"=20
        tabIndex=3D0 w:st=3D"on">Attila Takacs</st1:PersonName>; =
[email-masked];=20
        [email-masked]<BR><B><SPAN=20
        style=3D"FONT-WEIGHT: bold">Subject:</SPAN></B> Re:=20
        =
draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt</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>
        <DIV>
        <P class=3DMsoNormal><FONT face=3D"Times New Roman" =
size=3D3><SPAN=20
        style=3D"FONT-SIZE: 12pt">On Dec 4, 2007, at 7:33 PM, Diego =
Caviglia=20
        wrote:<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"><BR><BR><o:p></o:p></SPAN></FONT></P><SPAN=20
        style=3D"WORD-SPACING: 0px; orphans: 2; widows: 2; =
webkit-border-horizontal-spacing: 0px; webkit-border-vertical-spacing: =
0px; webkit-text-decorations-in-effect: none; webkit-text-size-adjust: =
auto; webkit-text-stroke-width: 0">
        <DIV=20
        style=3D"WORD-WRAP: break-word; webkit-nbsp-mode: space; =
webkit-line-break: after-white-space"=20
        link=3D"blue" vlink=3D"blue">
        <DIV>
        <DIV>
        <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy =
size=3D2><SPAN=20
        style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Hi=20
        Thomas,<O:P></O:P></SPAN></FONT><FONT color=3Dblack><SPAN=20
        style=3D"COLOR: black"><o:p></o:p></SPAN></FONT></P></DIV>
        <DIV>
        <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy =
size=3D2><SPAN=20
        style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
        My understanding of the ID was that RSVP-TE can be used to =
=91piggyback=92=20
        CFM set-up, otherwise the scenario is: usage of RSVP-TE to =
set-up the=20
        LSP and NMS (meaning everything that is not control plane) to =
enable to=20
        CFM for the LSP.</SPAN></FONT><FONT color=3Dblack><SPAN=20
        style=3D"COLOR: =
black"><o:p></o:p></SPAN></FONT></P></DIV></DIV></DIV></SPAN>
        <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>
        <P class=3DMsoNormal><FONT face=3D"Times New Roman" =
size=3D3><SPAN=20
        style=3D"FONT-SIZE: 12pt">As I understand it, the IEEE is =
working on=20
        set-up of CFM (and MEPs), as are some vendors I know.=20
        *)<o:p></o:p></SPAN></FONT></P></DIV>
        <DIV>
        <P class=3DMsoNormal><FONT face=3D"Times New Roman" =
size=3D3><SPAN=20
        style=3D"FONT-SIZE: 12pt">This to me seems like the right way to =
do=20
        this.<o:p></o:p></SPAN></FONT></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></BLOCKQUOTE>
      <DIV>
      <P class=3DMsoNormal><FONT face=3DArial color=3Dblue =
size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">IEEE =
specified=20
      CFM and MIBs to setup =
CFM.&nbsp;</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">Diego's =
summary=20
      is correct: one can use an NMS or&nbsp;a control plane to setup =
the data=20
      plane. In this case we propose to use&nbsp;GMPLS to setup the data =
plane:=20
      both forwarding + OAM.</SPAN></FONT><o:p></o:p></P></DIV>
      <BLOCKQUOTE=20
      style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0cm; =
BORDER-TOP: medium none; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0cm; MARGIN: =
5pt 0cm 5pt 3.75pt; BORDER-LEFT: blue 1.5pt solid; PADDING-TOP: 0cm; =
BORDER-BOTTOM: medium none"=20
      type=3D"cite"><SPAN=20
        style=3D"WORD-SPACING: 0px; orphans: 2; widows: 2; =
webkit-border-horizontal-spacing: 0px; webkit-border-vertical-spacing: =
0px; webkit-text-decorations-in-effect: none; webkit-text-size-adjust: =
auto; webkit-text-stroke-width: 0"><O:P></O:P>
        <BLOCKQUOTE style=3D"MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt"><SPAN=20
          style=3D"webkit-text-stroke-width: -1">
          <DIV=20
          style=3D"WORD-WRAP: break-word; webkit-nbsp-mode: space; =
webkit-line-break: after-white-space"=20
          link=3D"blue" vlink=3D"blue">
          <DIV>
          <P class=3DMsoNormal><SPAN class=3Dapple-style-span><FONT=20
          face=3D"Times New Roman" color=3D#144fae size=3D2><SPAN=20
          style=3D"FONT-SIZE: 10pt; COLOR: #144fae">From your comment I =
see that=20
          you=92re not happy with the fact the ID is so technology =
specific am I=20
          right? &nbsp;</SPAN></SPAN></FONT></SPAN><FONT =
color=3Dblack><SPAN=20
          style=3D"COLOR: =
black"><o:p></o:p></SPAN></FONT></P></DIV></DIV></BLOCKQUOTE></SPAN>
        <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>
        <DIV>
        <P class=3DMsoNormal><FONT face=3D"Times New Roman" =
size=3D3><SPAN=20
        style=3D"FONT-SIZE: 12pt">Precisely; its gluing CFM to =
RSVP-TE/GMPLS as a=20
        transport.&nbsp;<o:p></o:p></SPAN></FONT></P></DIV></BLOCKQUOTE>
      <DIV>
      <P class=3DMsoNormal><FONT face=3DArial color=3Dblue =
size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">I do =
not see your=20
      point with gluing. What do you mean by "as transport"? GMPLS is =
just=20
      controlling OAM, CFM is run solely in the data=20
      plane.</SPAN></FONT><o:p></o:p></P></DIV>
      <DIV>
      <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN =

      style=3D"FONT-SIZE: =
12pt">&nbsp;<o:p></o:p></SPAN></FONT></P></DIV>
      <DIV>
      <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN =

      style=3D"FONT-SIZE: =
12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P></DIV>
      <BLOCKQUOTE=20
      style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0cm; =
BORDER-TOP: medium none; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0cm; MARGIN: =
5pt 0cm 5pt 3.75pt; BORDER-LEFT: blue 1.5pt solid; PADDING-TOP: 0cm; =
BORDER-BOTTOM: medium none"=20
      type=3D"cite"><SPAN=20
        style=3D"WORD-SPACING: 0px; orphans: 2; widows: 2; =
webkit-border-horizontal-spacing: 0px; webkit-border-vertical-spacing: =
0px; webkit-text-decorations-in-effect: none; webkit-text-size-adjust: =
auto; webkit-text-stroke-width: 0">
        <BLOCKQUOTE style=3D"MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt"><SPAN=20
          style=3D"webkit-text-stroke-width: -1">
          <DIV=20
          style=3D"WORD-WRAP: break-word; webkit-nbsp-mode: space; =
webkit-line-break: after-white-space"=20
          link=3D"blue" vlink=3D"blue">
          <DIV>
          <P class=3DMsoNormal><SPAN class=3Dapple-style-span><FONT=20
          face=3D"Times New Roman" color=3D#144fae size=3D2><SPAN=20
          style=3D"FONT-SIZE: 10pt; COLOR: #144fae">If yes do you agree =
with the=20
          fact that could be useful in general to use the same signaling =

          =91session=92 to set-up the LSP and to enable the=20
          CFM?</SPAN></SPAN></FONT></SPAN><FONT color=3Dblack><SPAN=20
          style=3D"COLOR: =
black"><o:p></o:p></SPAN></FONT></P></DIV></DIV></BLOCKQUOTE></SPAN>
        <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>
        <DIV>
        <P class=3DMsoNormal><FONT face=3D"Times New Roman" =
size=3D3><SPAN=20
        style=3D"FONT-SIZE: 12pt">No, I do not agree. &nbsp;Again, if =
CFM is to be=20
        set-up e2e, let the IEEE define this. Leave GMPLS to=20
        CCAMP.<o:p></o:p></SPAN></FONT></P></DIV></BLOCKQUOTE>
      <DIV>
      <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN =

      style=3D"FONT-SIZE: =
12pt">&nbsp;<o:p></o:p></SPAN></FONT></P></DIV>
      <DIV>
      <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN =

      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">Sorry, =
I cannot=20
      follow.</SPAN></FONT><o:p></o:p></P></DIV>
      <DIV>
      <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN =

      style=3D"FONT-SIZE: =
12pt">&nbsp;<o:p></o:p></SPAN></FONT></P></DIV>
      <DIV>
      <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN =

      style=3D"FONT-SIZE: =
12pt">&nbsp;<o:p></o:p></SPAN></FONT></P></DIV>
      <BLOCKQUOTE=20
      style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0cm; =
BORDER-TOP: medium none; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0cm; MARGIN: =
5pt 0cm 5pt 3.75pt; BORDER-LEFT: blue 1.5pt solid; PADDING-TOP: 0cm; =
BORDER-BOTTOM: medium none">
        <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=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=3D"Times New Roman" =
size=3D3><SPAN=20
        style=3D"FONT-SIZE: =
12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P></DIV>
        <DIV>
        <P class=3DMsoNormal><FONT face=3D"Times New Roman" =
size=3D3><SPAN=20
        style=3D"FONT-SIZE: =
12pt">--Tom<o:p></o:p></SPAN></FONT></P></DIV>
        <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>
        <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>
        <DIV>
        <P class=3DMsoNormal><FONT face=3D"Times New Roman" =
size=3D3><SPAN=20
        style=3D"FONT-SIZE: =
12pt"><BR><BR><o:p></o:p></SPAN></FONT></P><SPAN=20
        style=3D"WORD-SPACING: 0px; orphans: 2; widows: 2; =
webkit-border-horizontal-spacing: 0px; webkit-border-vertical-spacing: =
0px; webkit-text-decorations-in-effect: none; webkit-text-size-adjust: =
auto; webkit-text-stroke-width: 0"><O:P>
        <DIV=20
        style=3D"WORD-WRAP: break-word; webkit-nbsp-mode: space; =
webkit-line-break: after-white-space"=20
        link=3D"blue" vlink=3D"blue">
        <DIV>
        <DIV>
        <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy =
size=3D2><SPAN=20
        style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">&nbsp;<SPAN=20
        style=3D"webkit-text-stroke-width: -1"></SPAN></FONT><SPAN=20
        class=3Dapple-style-span><FONT face=3DArial color=3D#144fae =
size=3D2><SPAN=20
        style=3D"FONT-SIZE: 10pt; COLOR: #144fae; FONT-FAMILY: =
Arial">Best=20
        Regards</SPAN></SPAN></FONT></O:P></SPAN><FONT =
color=3Dblack><SPAN=20
        style=3D"COLOR: black"><o:p></o:p></SPAN></FONT></P></DIV>
        <DIV>
        <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy =
size=3D2><SPAN=20
        style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><BR>Diego<O:P></O:P></SPAN></FONT><FONT=20
        color=3Dblack><SPAN=20
        style=3D"COLOR: black"><o:p></o:p></SPAN></FONT></P></DIV><FONT=20
        face=3D"Times New Roman" color=3Dblack size=3D3><SPAN=20
        style=3D"FONT-SIZE: 12pt; COLOR: black; FONT-FAMILY: 'Times New =
Roman'"><O:P></O:P></SPAN></FONT>
        <DIV=20
        style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0cm; =
BORDER-TOP: medium none; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0cm; =
BORDER-LEFT: blue 1.5pt solid; PADDING-TOP: 0cm; BORDER-BOTTOM: medium =
none">
        <DIV>
        <DIV class=3DMsoNormal style=3D"TEXT-ALIGN: center" =
align=3Dcenter><FONT=20
        face=3D"Times New Roman" color=3Dblack size=3D3><SPAN=20
        style=3D"FONT-SIZE: 12pt; COLOR: black">
        <HR tabIndex=3D-1 align=3Dcenter width=3D"100%" SIZE=3D2>
        </SPAN></FONT></DIV>
        <DIV>
        <P class=3DMsoNormal><B><FONT face=3DTahoma color=3Dblack =
size=3D2><SPAN=20
        style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; COLOR: black; =
FONT-FAMILY: Tahoma">From:</SPAN></FONT></B><SPAN=20
        class=3Dapple-converted-space><FONT face=3DTahoma color=3Dblack =
size=3D2><SPAN=20
        style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: =
Tahoma">&nbsp;</SPAN></FONT></SPAN><FONT=20
        face=3DTahoma color=3Dblack size=3D2><SPAN=20
        style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: Tahoma"><A=20
        =
href=3D"mailto:[email-masked]">[email-masked]</A> =
[<A=20
        =
href=3D"mailto:[email-masked]">mailto:[email-masked]<=
/A>]<SPAN=20
        class=3Dapple-converted-space>&nbsp;</SPAN><B><SPAN=20
        style=3D"FONT-WEIGHT: bold">On Behalf Of<SPAN=20
        class=3Dapple-converted-space>&nbsp;</SPAN></SPAN></B>Thomas=20
        Nadeau<BR><B><SPAN style=3D"FONT-WEIGHT: =
bold">Sent:</SPAN></B><SPAN=20
        class=3Dapple-converted-space>&nbsp;</SPAN>marted=EC 4 dicembre =
2007=20
        11.30<BR><B><SPAN style=3D"FONT-WEIGHT: =
bold">To:</SPAN></B><SPAN=20
        class=3Dapple-converted-space>&nbsp;</SPAN><st1:PersonName=20
        style=3D"BACKGROUND-POSITION: left bottom; BACKGROUND-IMAGE: =
url(res://ietag.dll/#34/#1001); BACKGROUND-REPEAT: repeat-x"=20
        tabIndex=3D0 w:st=3D"on">Attila =
Takacs</st1:PersonName><BR><B><SPAN=20
        style=3D"FONT-WEIGHT: bold">Cc:</SPAN></B><SPAN=20
        class=3Dapple-converted-space>&nbsp;</SPAN><A=20
        href=3D"mailto:[email-masked]">[email-masked]</A>;<SPAN=20
        class=3Dapple-converted-space>&nbsp;</SPAN><A=20
        =
href=3D"mailto:[email-masked]">[email-masked]</A><BR>=
<B><SPAN=20
        style=3D"FONT-WEIGHT: bold">Subject:</SPAN></B><SPAN=20
        class=3Dapple-converted-space>&nbsp;</SPAN>Re:=20
        draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt</SPAN></FONT><FONT =

        color=3Dblack><SPAN=20
        style=3D"COLOR: =
black"><o:p></o:p></SPAN></FONT></P><O:P></O:P></DIV></DIV>
        <DIV>
        <DIV>
        <DIV>
        <P class=3DMsoNormal><FONT face=3D"Times New Roman" =
color=3Dblack size=3D3><SPAN=20
        style=3D"FONT-SIZE: 12pt; COLOR: black"><O:P></O:P><O:P></O:P>On =
Dec 4,=20
        2007, at 1:51 PM, <st1:PersonName=20
        style=3D"BACKGROUND-POSITION: left bottom; BACKGROUND-IMAGE: =
url(res://ietag.dll/#34/#1001); BACKGROUND-REPEAT: repeat-x"=20
        tabIndex=3D0 w:st=3D"on">Attila Takacs</st1:PersonName>=20
        wrote:<O:P></O:P><o:p></o:p></SPAN></FONT></P></DIV></DIV>
        <DIV>
        <P class=3DMsoNormal><FONT face=3D"Times New Roman" =
color=3Dblack size=3D3><SPAN=20
        style=3D"FONT-SIZE: 12pt; COLOR: =
black"><BR><BR><BR><o:p></o:p></SPAN></FONT></P></DIV><O:P></O:P>
        <DIV style=3D"WORD-WRAP: break-word">
        <DIV>
        <DIV>
        <P class=3DMsoNormal><FONT face=3DArial color=3Dblue =
size=3D2><SPAN=20
        style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Hi=20
        Thomas,</SPAN></FONT><FONT color=3Dblack><SPAN=20
        style=3D"COLOR: =
black"><o:p></o:p></SPAN></FONT></P><O:P></O:P></DIV></DIV>
        <DIV>
        <DIV>
        <P class=3DMsoNormal><FONT face=3DArial color=3Dblue =
size=3D2><SPAN=20
        style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
Arial"><O:P></O:P>Thank=20
        you&nbsp;for the comments!</SPAN></FONT><FONT =
color=3Dblack><SPAN=20
        style=3D"COLOR: =
black"><o:p></o:p></SPAN></FONT></P><O:P></O:P></DIV></DIV>
        <DIV>
        <DIV>
        <P class=3DMsoNormal><FONT face=3DArial color=3Dblue =
size=3D2><SPAN=20
        style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
Arial">Please see=20
        answers inline.</SPAN></FONT><FONT color=3Dblack><SPAN=20
        style=3D"COLOR: =
black"><o:p></o:p></SPAN></FONT></P><O:P></O:P></DIV></DIV>
        <DIV>
        <DIV>
        <P class=3DMsoNormal><FONT face=3DArial color=3Dblue =
size=3D2><SPAN=20
        style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
Arial"><O:P></O:P>Best=20
        regards,<BR>Attila</SPAN></FONT><FONT color=3Dblack><SPAN=20
        style=3D"COLOR: =
black"><o:p></o:p></SPAN></FONT></P><O:P></O:P></DIV></DIV><FONT=20
        face=3D"Times New Roman" color=3Dblack size=3D3><SPAN=20
        style=3D"FONT-SIZE: 12pt; COLOR: black; FONT-FAMILY: 'Times New =
Roman'"><O:P></O:P></SPAN></FONT>
        <BLOCKQUOTE=20
        style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0cm; =
BORDER-TOP: medium none; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0cm; MARGIN: =
5pt 0cm 5pt 3.75pt; BORDER-LEFT: blue 1.5pt solid; PADDING-TOP: 0cm; =
BORDER-BOTTOM: medium none">
          <DIV class=3DMsoNormal style=3D"TEXT-ALIGN: center" =
align=3Dcenter><FONT=20
          face=3D"Times New Roman" color=3Dblack size=3D3><SPAN=20
          style=3D"FONT-SIZE: 12pt; COLOR: black">
          <HR tabIndex=3D-1 align=3Dcenter width=3D"100%" SIZE=3D2>
          </SPAN></FONT></DIV>
          <DIV>
          <P class=3DMsoNormal><B><FONT face=3DTahoma color=3Dblack =
size=3D2><SPAN=20
          style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; COLOR: black; =
FONT-FAMILY: Tahoma">From:</SPAN></FONT></B><SPAN=20
          class=3Dapple-converted-space><FONT face=3DTahoma =
color=3Dblack size=3D2><SPAN=20
          style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: =
Tahoma">&nbsp;</SPAN></FONT></SPAN><FONT=20
          face=3DTahoma color=3Dblack size=3D2><SPAN=20
          style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: =
Tahoma">Thomas=20
          Nadeau [<A=20
          =
href=3D"mailto:[email-masked]">mailto:[email-masked]</A=
>]<SPAN=20
          class=3Dapple-converted-space>&nbsp;</SPAN><BR><B><SPAN=20
          style=3D"FONT-WEIGHT: bold">Sent:</SPAN></B><SPAN=20
          class=3Dapple-converted-space>&nbsp;</SPAN>Tuesday, December =
04, 2007=20
          2:58 PM<BR><B><SPAN style=3D"FONT-WEIGHT: =
bold">To:</SPAN></B><SPAN=20
          class=3Dapple-converted-space>&nbsp;</SPAN><A=20
          =
href=3D"mailto:[email-masked]">[email-masked]</A><BR><B><SPAN=20
          style=3D"FONT-WEIGHT: bold">Cc:</SPAN></B><SPAN=20
          class=3Dapple-converted-space>&nbsp;</SPAN><st1:PersonName=20
          style=3D"BACKGROUND-POSITION: left bottom; BACKGROUND-IMAGE: =
url(res://ietag.dll/#34/#1001); BACKGROUND-REPEAT: repeat-x"=20
          tabIndex=3D0 w:st=3D"on">Attila Takacs</st1:PersonName>;<SPAN=20
          class=3Dapple-converted-space>&nbsp;</SPAN><A=20
          =
href=3D"mailto:[email-masked]">[email-masked]</A><BR>=
<B><SPAN=20
          style=3D"FONT-WEIGHT: bold">Subject:</SPAN></B><SPAN=20
          =
class=3Dapple-converted-space>&nbsp;</SPAN>draft-takacs-ccamp-rsvp-te-eth=
-oam-ext-00.txt</SPAN></FONT><FONT=20
          color=3Dblack><SPAN=20
          style=3D"COLOR: =
black"><o:p></o:p></SPAN></FONT></P><O:P></O:P></DIV>
          <DIV>
          <DIV>
          <P class=3DMsoNormal><FONT face=3D"Times New Roman" =
color=3Dblack=20
          size=3D3><SPAN=20
          style=3D"FONT-SIZE: 12pt; COLOR: =
black"><O:P></O:P><O:P></O:P>After=20
          reading this draft, I have some=20
          =
questions/comments.<O:P></O:P><o:p></o:p></SPAN></FONT></P></DIV></DIV>
          <DIV>
          <DIV>
          <P class=3DMsoNormal><FONT face=3D"Times New Roman" =
color=3Dblack=20
          size=3D3><SPAN style=3D"FONT-SIZE: 12pt; COLOR: =
black"><O:P></O:P>1)=20
          Overall,&nbsp;I am concerned that the definition of a new TLV =
and=20
          these procedures=20
          =
represent&nbsp;<O:P></O:P><o:p></o:p></SPAN></FONT></P></DIV></DIV>
          <DIV>
          <DIV>
          <P class=3DMsoNormal><FONT face=3D"Times New Roman" =
color=3Dblack=20
          size=3D3><SPAN style=3D"FONT-SIZE: 12pt; COLOR: black">what =
amounts to a=20
          laying violation and ask that the ADs take a look at=20
          this<O:P></O:P><o:p></o:p></SPAN></FONT></P></DIV></DIV>
          <DIV>
          <DIV>
          <P class=3DMsoNormal><FONT face=3D"Times New Roman" =
color=3Dblack=20
          size=3D3><SPAN style=3D"FONT-SIZE: 12pt; COLOR: =
black">approach closely.=20
          This is similar to the now-rejected approach that was=20
          proposed<O:P></O:P><o:p></o:p></SPAN></FONT></P></DIV></DIV>
          <DIV>
          <DIV>
          <P class=3DMsoNormal><FONT face=3D"Times New Roman" =
color=3Dblack=20
          size=3D3><SPAN style=3D"FONT-SIZE: 12pt; COLOR: black">in the =
l2vpn WG=20
          about munging CFM + PWs. &nbsp;To my reading, this is=20
          =
essentially<O:P></O:P><o:p></o:p></SPAN></FONT></P></DIV></DIV>
          <DIV>
          <DIV>
          <P class=3DMsoNormal><FONT face=3D"Times New Roman" =
color=3Dblack=20
          size=3D3><SPAN style=3D"FONT-SIZE: 12pt; COLOR: black">the =
same thing. If=20
          you want to run CFM, run it natively over the ethernet =
interfaces=20
          and<O:P></O:P><o:p></o:p></SPAN></FONT></P></DIV></DIV>
          <DIV>
          <DIV>
          <P class=3DMsoNormal><FONT face=3D"Times New Roman" =
color=3Dblack=20
          size=3D3><SPAN style=3D"FONT-SIZE: 12pt; COLOR: black">have no =
regard for=20
          the underlying topology (GMPLS, PWs, etc...) otherwise=20
          you&nbsp;<O:P></O:P><o:p></o:p></SPAN></FONT></P></DIV></DIV>
          <DIV>
          <DIV>
          <P class=3DMsoNormal><FONT face=3D"Times New Roman" =
color=3Dblack=20
          size=3D3><SPAN style=3D"FONT-SIZE: 12pt; COLOR: black">will be =
creating a=20
          mess for implementations and=20
          interoperability.&nbsp;</SPAN></FONT><FONT face=3DArial =
color=3Dblue=20
          size=3D2><SPAN=20
          style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
Arial">&nbsp;</SPAN></FONT><FONT=20
          color=3Dblack><SPAN=20
          style=3D"COLOR: =
black"><o:p></o:p></SPAN></FONT></P><O:P></O:P></DIV></DIV></BLOCKQUOTE>
        <DIV>
        <DIV>
        <P class=3DMsoNormal><FONT face=3DArial color=3Dblue =
size=3D2><SPAN=20
        style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">The=20
        application&nbsp;of the draft is exactly for what you are =
calling out:=20
        when CFM is run natively over the Ethernet interfaces. The =
document=20
        focuses on GELS and Ethernet LSPs.&nbsp;That is,&nbsp;to =
establish CFM=20
        entities for GMPLS controlled Ethernet LSPs.&nbsp;Hence, I think =
there=20
        is no layer violation issue.</SPAN></FONT><FONT =
color=3Dblack><SPAN=20
        style=3D"COLOR: =
black"><o:p></o:p></SPAN></FONT></P><O:P></O:P></DIV></DIV></DIV>
        <DIV>
        <P class=3DMsoNormal><SPAN =
class=3Dapple-tab-span><O:P></O:P><FONT=20
        face=3D"Times New Roman" color=3Dblack size=3D3><SPAN=20
        style=3D"FONT-SIZE: 12pt; COLOR: =
black">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</SPAN></FON=
T></SPAN><SPAN=20
        class=3Dapple-converted-space><FONT color=3Dblack><SPAN=20
        style=3D"COLOR: black">&nbsp;</SPAN></FONT></SPAN><FONT =
color=3Dblack><SPAN=20
        style=3D"COLOR: black">This solution specifically only works for =
GMPLS=20
        ethernet LSPs, right?=20
        &nbsp;<o:p></o:p></SPAN></FONT></P><O:P></O:P></DIV></DIV>
        <DIV>
        <DIV>
        <P class=3DMsoNormal><FONT face=3D"Times New Roman" =
color=3Dblack size=3D3><SPAN=20
        style=3D"FONT-SIZE: 12pt; COLOR: black">What do I do if I want =
to set up=20
        MPLS ethernet LSPs (i.e.: PWs)&nbsp;and do CFM over those?=20
        Oh,<O:P></O:P><o:p></o:p></SPAN></FONT></P></DIV></DIV>
        <DIV>
        <DIV>
        <P class=3DMsoNormal><FONT face=3D"Times New Roman" =
color=3Dblack size=3D3><SPAN=20
        style=3D"FONT-SIZE: 12pt; COLOR: black">that is a different =
solution,=20
        right? &nbsp;Then what do I do if I want to run CFM over some =
new type=20
        of<O:P></O:P><o:p></o:p></SPAN></FONT></P></DIV></DIV>
        <DIV>
        <DIV>
        <P class=3DMsoNormal><FONT face=3D"Times New Roman" =
color=3Dblack size=3D3><SPAN=20
        style=3D"FONT-SIZE: 12pt; COLOR: black">ethernet LSP in the =
future? More=20
        protocol hacks? &nbsp;The point is to use CFM over an ethernet=20
        interface<O:P></O:P><o:p></o:p></SPAN></FONT></P></DIV></DIV>
        <DIV>
        <DIV>
        <P class=3DMsoNormal><FONT face=3D"Times New Roman" =
color=3Dblack size=3D3><SPAN=20
        style=3D"FONT-SIZE: 12pt; COLOR: black">without the underlying =
layers=20
        knowing. This is good networking architecture design, that=20
        simplifies<O:P></O:P><o:p></o:p></SPAN></FONT></P></DIV></DIV>
        <DIV>
        <DIV>
        <P class=3DMsoNormal><FONT face=3D"Times New Roman" =
color=3Dblack size=3D3><SPAN=20
        style=3D"FONT-SIZE: 12pt; COLOR: black">implementations and =
makes them=20
        more robust, as well as makes using them operationally=20
        much<O:P></O:P><o:p></o:p></SPAN></FONT></P></DIV></DIV>
        <DIV>
        <DIV>
        <P class=3DMsoNormal><FONT face=3D"Times New Roman" =
color=3Dblack size=3D3><SPAN=20
        style=3D"FONT-SIZE: 12pt; COLOR: =
black">easier.&nbsp;<O:P></O:P><o:p></o:p></SPAN></FONT></P></DIV></DIV>
        <DIV>
        <BLOCKQUOTE style=3D"MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt" =
type=3D"cite">
          <DIV style=3D"WORD-WRAP: break-word">
          <BLOCKQUOTE=20
          style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0cm; =
BORDER-TOP: medium none; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0cm; MARGIN: =
5pt 0cm 5pt 3.75pt; BORDER-LEFT: blue 1.5pt solid; PADDING-TOP: 0cm; =
BORDER-BOTTOM: medium none">
            <DIV>
            <DIV>
            <P class=3DMsoNormal><FONT face=3D"Times New Roman" =
color=3Dblack=20
            size=3D3><SPAN style=3D"FONT-SIZE: 12pt; COLOR: =
black">2)&nbsp;The=20
            introductory sections in this draft give a lot of discussion =
about=20
            fast fault detection.=20
            I<O:P></O:P><o:p></o:p></SPAN></FONT></P></DIV></DIV>
            <DIV>
            <DIV>
            <P class=3DMsoNormal><FONT face=3D"Times New Roman" =
color=3Dblack=20
            size=3D3><SPAN style=3D"FONT-SIZE: 12pt; COLOR: black">am =
puzzled by=20
            this given that GMPLS networks tend to run over quickly=20
            =
self-healing<O:P></O:P><o:p></o:p></SPAN></FONT></P></DIV></DIV>
            <DIV>
            <DIV>
            <P class=3DMsoNormal><FONT face=3D"Times New Roman" =
color=3Dblack=20
            size=3D3><SPAN style=3D"FONT-SIZE: 12pt; COLOR: =
black">optical=20
            infrastructures. Is it therefore&nbsp;truly&nbsp;necessary =
to=20
            motivate this work=20
            by<O:P></O:P><o:p></o:p></SPAN></FONT></P></DIV></DIV>
            <DIV>
            <DIV>
            <P class=3DMsoNormal><FONT face=3D"Times New Roman" =
color=3Dblack=20
            size=3D3><SPAN style=3D"FONT-SIZE: 12pt; COLOR: =
black">requiring fast=20
            =
CFMs?<O:P></O:P><o:p></o:p></SPAN></FONT></P></DIV></DIV></BLOCKQUOTE>
          <DIV>
          <DIV>
          <P class=3DMsoNormal><FONT face=3DArial color=3Dblue =
size=3D2><SPAN=20
          style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">It =
is right=20
          that frequent CCMs are not required if the layers below =
Ethernet=20
          handle protection. However, the ID focuses on Ethernet LSPs =
where=20
          Ethernet is&nbsp;not just a single hop&nbsp;above a transport=20
          LSP.&nbsp;In this case&nbsp;Ethernet layer (for clarity GELS) =
may=20
          provide protection for Ethernet LSPs.&nbsp;In any case,&nbsp; =
the=20
          whole point of the ID is to allow for the appropriate =
configuration of=20
          CFM for Ethernet LSPs with GMPLS.</SPAN></FONT><FONT =
color=3Dblack><SPAN=20
          style=3D"COLOR: =
black"><o:p></o:p></SPAN></FONT></P><O:P></O:P></DIV></DIV>
          <BLOCKQUOTE=20
          style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0cm; =
BORDER-TOP: medium none; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0cm; MARGIN: =
5pt 0cm 5pt 3.75pt; BORDER-LEFT: blue 1.5pt solid; PADDING-TOP: 0cm; =
BORDER-BOTTOM: medium none">
            <DIV>
            <DIV>
            <P class=3DMsoNormal><FONT face=3D"Times New Roman" =
color=3Dblack=20
            size=3D3><SPAN style=3D"FONT-SIZE: 12pt; COLOR: =
black"><O:P></O:P>3)=20
            This document does not cover E-LMI. Why=20
            =
not?<O:P></O:P><o:p></o:p></SPAN></FONT></P></DIV></DIV></BLOCKQUOTE>
          <DIV>
          <DIV>
          <P class=3DMsoNormal><FONT face=3DArial color=3Dblue =
size=3D2><SPAN=20
          style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
Arial">E-LMI is run=20
          over the MEF UNI. The&nbsp;ID focuses on Ethernet LSPs within =
a=20
          network.</SPAN></FONT><FONT color=3Dblack><SPAN=20
          style=3D"COLOR: =
black"><o:p></o:p></SPAN></FONT></P><O:P></O:P></DIV></DIV>
          <BLOCKQUOTE=20
          style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0cm; =
BORDER-TOP: medium none; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0cm; MARGIN: =
5pt 0cm 5pt 3.75pt; BORDER-LEFT: blue 1.5pt solid; PADDING-TOP: 0cm; =
BORDER-BOTTOM: medium none">
            <DIV>
            <DIV>
            <P class=3DMsoNormal><SPAN =
class=3Dapple-style-span><O:P></O:P><FONT=20
            face=3D"Times New Roman" color=3Dblack size=3D1><SPAN=20
            style=3D"FONT-SIZE: 9pt; COLOR: black"><O:P></O:P>For the =
purposes of=20
            this document, we only discuss Ethernet=20
            OAM</SPAN></FONT></SPAN><FONT color=3Dblack><SPAN=20
            style=3D"COLOR: =
black"><o:p></o:p></SPAN></FONT></P><O:P></O:P></DIV></DIV>
            <DIV>
            <DIV>
            <P class=3DMsoNormal><FONT face=3DHelvetica color=3Dblack =
size=3D1><SPAN=20
            style=3D"FONT-SIZE: 9pt; COLOR: black; FONT-FAMILY: =
Helvetica">&nbsp;&nbsp;=20
            [IEEE-CFM] aspects that are relevant for the connectivity=20
            monitoring<O:P></O:P></SPAN></FONT><FONT color=3Dblack><SPAN =

            style=3D"COLOR: =
black"><o:p></o:p></SPAN></FONT></P></DIV></DIV>
            <DIV>
            <DIV>
            <P class=3DMsoNormal><FONT face=3DHelvetica color=3Dblack =
size=3D1><SPAN=20
            style=3D"FONT-SIZE: 9pt; COLOR: black; FONT-FAMILY: =
Helvetica">&nbsp;&nbsp;=20
            of bidirectional point-to-point PBB-TE connections.=20
            &nbsp;<O:P></O:P></SPAN></FONT><FONT color=3Dblack><SPAN=20
            style=3D"COLOR: =
black"><o:p></o:p></SPAN></FONT></P></DIV></DIV>
            <DIV>
            <DIV>
            <P class=3DMsoNormal><FONT face=3DHelvetica color=3Dblack =
size=3D1><SPAN=20
            style=3D"FONT-SIZE: 9pt; COLOR: black; FONT-FAMILY: =
Helvetica"><O:P></O:P>4)=20
            Is this the right place to define this document or should =
this be=20
            done in GELS?<O:P></O:P></SPAN></FONT><FONT =
color=3Dblack><SPAN=20
            style=3D"COLOR: =
black"><o:p></o:p></SPAN></FONT></P></DIV></DIV></BLOCKQUOTE>
          <DIV>
          <DIV>
          <P class=3DMsoNormal><FONT face=3DArial color=3Dblue =
size=3D2><SPAN=20
          style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
Arial">Well, GELS is=20
          done in CCAMP...this seems to be the right =
place.</SPAN></FONT><FONT=20
          color=3Dblack><SPAN=20
          style=3D"COLOR: =
black"><o:p></o:p></SPAN></FONT></P><O:P></O:P></DIV></DIV>
          <BLOCKQUOTE=20
          style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0cm; =
BORDER-TOP: medium none; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0cm; MARGIN: =
5pt 0cm 5pt 3.75pt; BORDER-LEFT: blue 1.5pt solid; PADDING-TOP: 0cm; =
BORDER-BOTTOM: medium none">
            <DIV>
            <DIV>
            <P class=3DMsoNormal><FONT face=3DHelvetica color=3Dblack =
size=3D1><SPAN=20
            style=3D"FONT-SIZE: 9pt; COLOR: black; FONT-FAMILY: =
Helvetica"><O:P></O:P><O:P></O:P>5)=20
            &nbsp; In section 2 you make the following=20
            statement:<O:P></O:P></SPAN></FONT><FONT color=3Dblack><SPAN =

            style=3D"COLOR: =
black"><o:p></o:p></SPAN></FONT></P></DIV></DIV>
            <DIV>
            <DIV>
            <P class=3DMsoNormal><FONT face=3DHelvetica color=3Dblack =
size=3D1><SPAN=20
            style=3D"FONT-SIZE: 9pt; COLOR: black; FONT-FAMILY: =
Helvetica"><O:P></O:P>2.&nbsp;=20
            GMPLS RSVP-TE Extensions<O:P></O:P></SPAN></FONT><FONT=20
            color=3Dblack><SPAN=20
            style=3D"COLOR: =
black"><o:p></o:p></SPAN></FONT></P></DIV></DIV>
            <DIV>
            <DIV>
            <P class=3DMsoNormal><FONT face=3DHelvetica color=3Dblack =
size=3D1><SPAN=20
            style=3D"FONT-SIZE: 9pt; COLOR: black; FONT-FAMILY: =
Helvetica"><O:P></O:P>&nbsp;<SPAN=20
            class=3Dapple-converted-space>&nbsp;</SPAN>&nbsp; To =
simplify the=20
            configuration of connectivity monitoring, when=20
            an<O:P></O:P></SPAN></FONT><FONT color=3Dblack><SPAN=20
            style=3D"COLOR: =
black"><o:p></o:p></SPAN></FONT></P></DIV></DIV>
            <DIV>
            <DIV>
            <P class=3DMsoNormal><FONT face=3DHelvetica color=3Dblack =
size=3D1><SPAN=20
            style=3D"FONT-SIZE: 9pt; COLOR: black; FONT-FAMILY: =
Helvetica">&nbsp;&nbsp;=20
            Ethernet LSP is signalled the associated MEPs should be=20
            automatically<O:P></O:P></SPAN></FONT><FONT =
color=3Dblack><SPAN=20
            style=3D"COLOR: =
black"><o:p></o:p></SPAN></FONT></P></DIV></DIV>
            <DIV>
            <DIV>
            <P class=3DMsoNormal><FONT face=3DHelvetica color=3Dblack =
size=3D1><SPAN=20
            style=3D"FONT-SIZE: 9pt; COLOR: black; FONT-FAMILY: =
Helvetica">&nbsp;<SPAN=20
            class=3Dapple-converted-space>&nbsp;</SPAN>&nbsp; =
established.&nbsp;=20
            Further more, GMPLS signalling should be able=20
            to<O:P></O:P></SPAN></FONT><FONT color=3Dblack><SPAN=20
            style=3D"COLOR: =
black"><o:p></o:p></SPAN></FONT></P></DIV></DIV>
            <DIV>
            <DIV>
            <P class=3DMsoNormal><FONT face=3DHelvetica color=3Dblack =
size=3D1><SPAN=20
            style=3D"FONT-SIZE: 9pt; COLOR: black; FONT-FAMILY: =
Helvetica">&nbsp;&nbsp;enable/disable=20
            connectivity monitoring of a particular Ethernet=20
            LSP.<O:P></O:P></SPAN></FONT><FONT color=3Dblack><SPAN=20
            style=3D"COLOR: =
black"><o:p></o:p></SPAN></FONT></P></DIV></DIV>
            <DIV>
            <DIV>
            <P class=3DMsoNormal><FONT face=3DHelvetica color=3Dblack =
size=3D1><SPAN=20
            style=3D"FONT-SIZE: 9pt; COLOR: black; FONT-FAMILY: =
Helvetica"><O:P></O:P><O:P></O:P>To=20
            my point in #1 above, you should use the native CFM =
functionality=20
            over the ethernet interface and =
signal<O:P></O:P></SPAN></FONT><FONT=20
            color=3Dblack><SPAN=20
            style=3D"COLOR: =
black"><o:p></o:p></SPAN></FONT></P></DIV></DIV>
            <DIV>
            <DIV>
            <P class=3DMsoNormal><FONT face=3DHelvetica color=3Dblack =
size=3D1><SPAN=20
            style=3D"FONT-SIZE: 9pt; COLOR: black; FONT-FAMILY: =
Helvetica">those=20
            capabilities to the bridges at both ends using the IEEE CFM=20
            signaling procedures (when and if =
they<O:P></O:P></SPAN></FONT><FONT=20
            color=3Dblack><SPAN=20
            style=3D"COLOR: =
black"><o:p></o:p></SPAN></FONT></P></DIV></DIV>
            <DIV>
            <DIV>
            <P class=3DMsoNormal><FONT face=3DHelvetica color=3Dblack =
size=3D1><SPAN=20
            style=3D"FONT-SIZE: 9pt; COLOR: black; FONT-FAMILY: =
Helvetica">are=20
            created). &nbsp;If you want to test the underlying GMPLS =
LSP(s),=20
            then you should use some<O:P></O:P></SPAN></FONT><FONT=20
            color=3Dblack><SPAN=20
            style=3D"COLOR: =
black"><o:p></o:p></SPAN></FONT></P></DIV></DIV>
            <DIV>
            <DIV>
            <P class=3DMsoNormal><FONT face=3DHelvetica color=3Dblack =
size=3D1><SPAN=20
            style=3D"FONT-SIZE: 9pt; COLOR: black; FONT-FAMILY: =
Helvetica">other=20
            mechanism defined for that layer such as the work stated=20
            in&nbsp;</SPAN></FONT><SPAN =
class=3Dapple-style-span><B><FONT=20
            face=3DHelvetica color=3Dblack size=3D2><SPAN=20
            style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; COLOR: black; =
FONT-FAMILY: =
Helvetica">draft-ali-ccamp-gmpls-LSP-ping-traceroute-00.txt</SPAN></FONT>=
</B></SPAN><FONT=20
            color=3Dblack><SPAN=20
            style=3D"COLOR: =
black"><O:P></O:P><o:p></o:p></SPAN></FONT></P></DIV></DIV></BLOCKQUOTE>
          <DIV>
          <DIV>
          <P class=3DMsoNormal><FONT face=3DArial color=3Dblue =
size=3D2><SPAN=20
          style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">See =
the=20
          note&nbsp;to your point #1. There is no relation&nbsp;to the=20
          gmpls-LSP-ping draft.&nbsp;</SPAN></FONT><FONT =
color=3Dblack><SPAN=20
          style=3D"COLOR: =
black"><O:P></O:P><o:p></o:p></SPAN></FONT></P></DIV></DIV></DIV></BLOCKQ=
UOTE>
        <DIV>
        <P class=3DMsoNormal><SPAN =
class=3Dapple-tab-span><O:P></O:P><FONT=20
        face=3D"Times New Roman" color=3Dblack size=3D3><SPAN=20
        style=3D"FONT-SIZE: 12pt; COLOR: =
black">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</SPAN></FON=
T></SPAN><SPAN=20
        class=3Dapple-converted-space><FONT color=3Dblack><SPAN=20
        style=3D"COLOR: black">&nbsp;</SPAN></FONT></SPAN><FONT =
color=3Dblack><SPAN=20
        style=3D"COLOR: black">The point I am making is that perhaps it=20
        should.<o:p></o:p></SPAN></FONT></P><O:P></O:P></DIV></DIV>
        <DIV>
        <DIV>
        <P class=3DMsoNormal><SPAN =
class=3Dapple-tab-span><O:P></O:P><FONT=20
        face=3D"Times New Roman" color=3Dblack size=3D3><SPAN=20
        style=3D"FONT-SIZE: 12pt; COLOR: =
black">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</SPAN></FON=
T></SPAN><SPAN=20
        class=3Dapple-converted-space><FONT color=3Dblack><SPAN=20
        style=3D"COLOR: black">&nbsp;</SPAN></FONT></SPAN><FONT =
color=3Dblack><SPAN=20
        style=3D"COLOR: =
black">--Tom<o:p></o:p></SPAN></FONT></P><O:P></O:P></DIV></DIV></DIV></D=
IV></DIV></DIV>
        <P class=3DMsoNormal><FONT face=3D"Times New Roman" =
size=3D3><SPAN=20
        style=3D"FONT-SIZE: =
12pt"><O:P></O:P><o:p>&nbsp;</o:p></SPAN></FONT></P></BLOCKQUOTE></BLOCKQ=
UOTE></DIV><O:P></O:P><O:P></O:P><O:P></O:P><O:P></O:P><O:P></O:P></SPAN>=
</DIV></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C83776.3E1B4EEC--

Delivery-date: Wed, 05 Dec 2007 17:01:36 +0000
Date: Thu, 06 Dec 2007 01:00:41 +0800
From: Dan Li <[email-masked]>
Subject: Re: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt
To: Diego Caviglia <[email-masked]>, [email-masked], Attila Takacs <[email-masked]>, [email-masked]
Cc: [email-masked]

This is a multi-part message in MIME format.

--Boundary_(ID_ri+RKGJ58xhymCKK5aRKfw)
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: quoted-printable

MessageHi,

I think there is a misunderstanding with respect to the objective of =
this draft.=20

As I read this draft, it describes how to extend the RSVP protocol to =
support the configuration/enable the OAM function of Ethernet LSP, which =
I think is a good thing to do, it is not saying to use signaling =
protocol to do the OAM work. But anyway, it may be necessary to clarify =
the objective at the beginning of this draft.

Regards,

Dan

  ----- Original Message -----=20
  From: Diego Caviglia=20
  To: [email-masked] ; Attila Takacs ; [email-masked]=20
  Cc: [email-masked]=20
  Sent: Thursday, December 06, 2007 12:27 AM
  Subject: RE: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt

  Hi Neil,

             Yes I totally agree with your analysis.

  =20

  The is not going to redefine or reinvent the OAM that, as Thomas as =
pointed out, is done by IEEE, the ID just specify how to use a control =
plane mechanism (GMPLS) set-up at the same time data plane circuit and =
the related OAM.

  =20

  Frankly specking I don't see any layer violation here.

  =20

  BR

  =20

  Diego

  =20

-------------------------------------------------------------------------=
-----

  From: [email-masked] [mailto:[email-masked]]=20
  Sent: marted=EC 4 dicembre 2007 22.55
  To: Attila Takacs; [email-masked]; Diego Caviglia
  Cc: [email-masked]
  Subject: RE: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt

  =20

  I'm puzzled.  I read the draft and thought it was excellent.  It is =
addressing an important operational issue, ie a critical operational OAM =
requirement is to ensure that whatever mechanism (MP or CP) is used to =
set-up/tear-down a connection (so this only applies to co-cs or co-ps =
modes....the cl-ps mode does not have connections of course) is =
harmonised to the activation/deactivation of the OAM.....specifically a =
CV/CC flow.   If we don't ensure this then there will be obvious =
operational problems.  This is essentially what the draft is about.

  =20

  Further, GMPLS is a generic OOB CP technique.....it is not a specific =
layer network technology per se (but it is specific in it's choice of =
signalling and routing components).  So one can apply a largely similar =
(GMPLS) CP technique to all co-cs mode technologies (whether they are =
partitioning a space, freq or time resource - see Note) and co-ps mode =
technologies (which only applies to partitioning a time resource - see =
Note) on the assumption that the technology is correctly architected in =
the DP for the mode considered.  It's pretty hard not to correctly =
architect the co-cs mode, but it's quite easy to incorrectly architect =
the co-ps mode, eg one can't violate the rules of a connection in the =
co-cs mode but one can in the co-ps mode.

  =20

  Note - When we partition a time resource in regular time-slices we =
create a co-cs mode layer network.  When we partition a time resource in =
irregular time-slices we create a co-ps mode layer network.  More =
information on labelling and resource partitioning can be found in the =
work on unified modelling (of networks) in G.800.

  =20

  regards, Neil

    -----Original Message-----
    From: [email-masked] [mailto:[email-masked]] On =
Behalf Of Attila Takacs
    Sent: 05 December 2007 02:03
    To: Thomas Nadeau; Diego Caviglia
    Cc: [email-masked]
    Subject: RE: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt

    Hi Tom,

    please see inline.

    Best regards,

    Attila

      =20

-------------------------------------------------------------------------=
-

      From: Thomas Nadeau [mailto:[email-masked]]=20
      Sent: Wednesday, December 05, 2007 2:19 AM
      To: Diego Caviglia
      Cc: Attila Takacs; [email-masked]; [email-masked]
      Subject: Re: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt

      =20

      On Dec 4, 2007, at 7:33 PM, Diego Caviglia wrote:

      Hi Thomas,

                       My understanding of the ID was that RSVP-TE can =
be used to 'piggyback' CFM set-up, otherwise the scenario is: usage of =
RSVP-TE to set-up the LSP and NMS (meaning everything that is not =
control plane) to enable to CFM for the LSP.

      =20

      As I understand it, the IEEE is working on set-up of CFM (and =
MEPs), as are some vendors I know. *)

      This to me seems like the right way to do this.

      =20

    IEEE specified CFM and MIBs to setup CFM.=20

    Diego's summary is correct: one can use an NMS or a control plane to =
setup the data plane. In this case we propose to use GMPLS to setup the =
data plane: both forwarding + OAM.

        From your comment I see that you're not happy with the fact the =
ID is so technology specific am I right? =20

      =20

      Precisely; its gluing CFM to RSVP-TE/GMPLS as a transport.=20

    I do not see your point with gluing. What do you mean by "as =
transport"? GMPLS is just controlling OAM, CFM is run solely in the data =
plane.

    =20

    =20

        If yes do you agree with the fact that could be useful in =
general to use the same signaling 'session' to set-up the LSP and to =
enable the CFM?

      =20

      No, I do not agree.  Again, if CFM is to be set-up e2e, let the =
IEEE define this. Leave GMPLS to CCAMP.

    =20

    =20

    Sorry, I cannot follow.

    =20

    =20

      =20

      =20

      =20

      --Tom

      =20

      =20

       Best Regards

      Diego

-------------------------------------------------------------------------=
-

      From: [email-masked] [mailto:[email-masked]] =
On Behalf Of Thomas Nadeau
      Sent: marted=EC 4 dicembre 2007 11.30
      To: Attila Takacs
      Cc: [email-masked]; [email-masked]
      Subject: Re: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt

      On Dec 4, 2007, at 1:51 PM, Attila Takacs wrote:

      Hi Thomas,

      Thank you for the comments!

      Please see answers inline.

      Best regards,
      Attila

------------------------------------------------------------------------

        From: Thomas Nadeau [mailto:[email-masked]]=20
        Sent: Tuesday, December 04, 2007 2:58 PM
        To: [email-masked]
        Cc: Attila Takacs; [email-masked]
        Subject: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt

        After reading this draft, I have some questions/comments.

        1) Overall, I am concerned that the definition of a new TLV and =
these procedures represent=20

        what amounts to a laying violation and ask that the ADs take a =
look at this

        approach closely. This is similar to the now-rejected approach =
that was proposed

        in the l2vpn WG about munging CFM + PWs.  To my reading, this is =
essentially

        the same thing. If you want to run CFM, run it natively over the =
ethernet interfaces and

        have no regard for the underlying topology (GMPLS, PWs, etc...) =
otherwise you=20

        will be creating a mess for implementations and =
interoperability. =20

      The application of the draft is exactly for what you are calling =
out: when CFM is run natively over the Ethernet interfaces. The document =
focuses on GELS and Ethernet LSPs. That is, to establish CFM entities =
for GMPLS controlled Ethernet LSPs. Hence, I think there is no layer =
violation issue.

                This solution specifically only works for GMPLS ethernet =
LSPs, right? =20

      What do I do if I want to set up MPLS ethernet LSPs (i.e.: PWs) =
and do CFM over those? Oh,

      that is a different solution, right?  Then what do I do if I want =
to run CFM over some new type of

      ethernet LSP in the future? More protocol hacks?  The point is to =
use CFM over an ethernet interface

      without the underlying layers knowing. This is good networking =
architecture design, that simplifies

      implementations and makes them more robust, as well as makes using =
them operationally much

      easier.=20

          2) The introductory sections in this draft give a lot of =
discussion about fast fault detection. I

          am puzzled by this given that GMPLS networks tend to run over =
quickly self-healing

          optical infrastructures. Is it therefore truly necessary to =
motivate this work by

          requiring fast CFMs?

        It is right that frequent CCMs are not required if the layers =
below Ethernet handle protection. However, the ID focuses on Ethernet =
LSPs where Ethernet is not just a single hop above a transport LSP. In =
this case Ethernet layer (for clarity GELS) may provide protection for =
Ethernet LSPs. In any case,  the whole point of the ID is to allow for =
the appropriate configuration of CFM for Ethernet LSPs with GMPLS.

          3) This document does not cover E-LMI. Why not?

        E-LMI is run over the MEF UNI. The ID focuses on Ethernet LSPs =
within a network.

          For the purposes of this document, we only discuss Ethernet =
OAM

             [IEEE-CFM] aspects that are relevant for the connectivity =
monitoring

             of bidirectional point-to-point PBB-TE connections. =20

          4) Is this the right place to define this document or should =
this be done in GELS?

        Well, GELS is done in CCAMP...this seems to be the right place.

          5)   In section 2 you make the following statement:

          2.  GMPLS RSVP-TE Extensions

              To simplify the configuration of connectivity monitoring, =
when an

             Ethernet LSP is signalled the associated MEPs should be =
automatically

              established.  Further more, GMPLS signalling should be =
able to

            enable/disable connectivity monitoring of a particular =
Ethernet LSP.

          To my point in #1 above, you should use the native CFM =
functionality over the ethernet interface and signal

          those capabilities to the bridges at both ends using the IEEE =
CFM signaling procedures (when and if they

          are created).  If you want to test the underlying GMPLS =
LSP(s), then you should use some

          other mechanism defined for that layer such as the work stated =
in draft-ali-ccamp-gmpls-LSP-ping-traceroute-00.txt

        See the note to your point #1. There is no relation to the =
gmpls-LSP-ping draft.=20

                The point I am making is that perhaps it should.

                --Tom

      =20

--Boundary_(ID_ri+RKGJ58xhymCKK5aRKfw)
Content-type: text/html; charset=iso-8859-1
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:st1 =3D=20
"urn:schemas-microsoft-com:office:smarttags"><HEAD><TITLE>Message</TITLE>=

<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.6000.16544" 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 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 Definitions */
 @font-face
	{font-family:Helvetica;
	panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:"Comic Sans MS";
	panose-1:3 15 7 2 3 3 2 2 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	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.EmailStyle20
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.Section1
	{page:Section1;}
-->
</STYLE>
</HEAD>
<BODY lang=3DEN-US=20
style=3D"WORD-WRAP: break-word; webkit-nbsp-mode: space; =
webkit-line-break: after-white-space"=20
vLink=3Dblue link=3Dblue bgColor=3D#ffffff>
<DIV>Hi,</DIV>
<DIV>&nbsp;</DIV>
<DIV>I think there is a misunderstanding with respect to&nbsp;the =
objective of=20
this draft. </DIV>
<DIV>&nbsp;</DIV>
<DIV>As I read this draft, it describes how to&nbsp;extend the&nbsp;RSVP =

protocol to support the&nbsp;configuration/enable the OAM function of =
Ethernet=20
LSP, which I think is a good thing to do, it is&nbsp;not saying to use =
signaling=20
protocol to do the OAM work. But anyway, it may be necessary to clarify =
the=20
objective at the beginning of this draft.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Regards,</DIV>
<DIV>&nbsp;</DIV>
<DIV>Dan</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A title=[email-masked]=20
  href=3D"mailto:[email-masked]">Diego Caviglia</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=[email-masked]=20
  href=3D"mailto:[email-masked]">[email-masked]</A> ; <A =

  title=[email-masked]=20
  href=3D"mailto:[email-masked]">Attila Takacs</A> ; <A=20
  title=[email-masked]=20
  href=3D"mailto:[email-masked]">[email-masked]</A> =
</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Cc:</B> <A =
title=[email-masked]=20
  href=3D"mailto:[email-masked]">[email-masked]</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Thursday, December 06, =
2007 12:27=20
  AM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> RE:=20
  draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt</DIV>
  <DIV><BR></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
  Neil,<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;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  Yes I totally agree with your analysis.<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">The is not =
going to=20
  redefine or reinvent the OAM that, as Thomas as pointed out, is done =
by IEEE,=20
  the ID just specify how to use a control plane mechanism (GMPLS) =
set-up at the=20
  same time data plane circuit and the related =
OAM.<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">Frankly =
specking I=20
  don=92t see any layer violation here.<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">BR<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">Diego<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=20
  style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0cm; BORDER-TOP: =
medium none; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0cm; BORDER-LEFT: blue =
1.5pt solid; PADDING-TOP: 0cm; BORDER-BOTTOM: medium none">
  <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"> <A=20
  href=3D"mailto:[email-masked]">[email-masked]</A>=20
  [mailto:[email-masked]] <BR><B><SPAN=20
  style=3D"FONT-WEIGHT: bold">Sent:</SPAN></B> marted=EC 4 dicembre 2007 =

  22.55<BR><B><SPAN style=3D"FONT-WEIGHT: bold">To:</SPAN></B> =
<st1:PersonName=20
  w:st=3D"on">Attila Takacs</st1:PersonName>; <A=20
  href=3D"mailto:[email-masked]">[email-masked]</A>; =
Diego=20
  Caviglia<BR><B><SPAN style=3D"FONT-WEIGHT: bold">Cc:</SPAN></B> <A=20
  href=3D"mailto:[email-masked]">[email-masked]</A><BR><B><SPAN=20
  style=3D"FONT-WEIGHT: bold">Subject:</SPAN></B> RE:=20
  =
draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt</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>
  <P class=3DMsoNormal><FONT face=3D"Comic Sans MS" color=3Dmaroon =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: maroon; FONT-FAMILY: 'Comic Sans =
MS'">I'm=20
  puzzled.&nbsp; I read the draft and thought it was excellent.&nbsp; It =
is=20
  addressing an important operational issue, ie a critical operational =
OAM=20
  requirement is to ensure that whatever mechanism (MP or CP) is used to =

  set-up/tear-down a connection (so this only applies to co-cs or co-ps=20
  modes....the cl-ps mode does not have connections of course) is =
harmonised to=20
  the activation/deactivation of the OAM.....specifically a CV/CC=20
  flow.&nbsp;&nbsp; If we don't ensure this then there will be obvious=20
  operational problems.&nbsp; This is essentially what the draft is=20
  about.</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=3D"Comic Sans MS" color=3Dmaroon =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: maroon; FONT-FAMILY: 'Comic Sans =
MS'">Further,=20
  GMPLS is a generic&nbsp;OOB&nbsp;CP technique.....it is not a specific =
layer=20
  network technology per se (but it is specific in it's choice of =
signalling and=20
  routing components).&nbsp; So one can apply a largely similar (GMPLS) =
CP=20
  technique to all co-cs mode technologies (whether they are =
partitioning a=20
  space, freq or&nbsp;time resource - see Note) and co-ps mode =
technologies=20
  (which only applies to partitioning a time resource - see Note) on the =

  assumption that the technology is correctly architected in the DP for =
the mode=20
  considered.&nbsp;&nbsp;It's pretty hard not to correctly architect the =
co-cs=20
  mode, but it's quite easy to incorrectly architect the co-ps mode, eg =
one=20
  can't violate the rules of a connection in the co-cs mode but one can =
in the=20
  co-ps mode.</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=3D"Comic Sans MS" color=3Dmaroon =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: maroon; FONT-FAMILY: 'Comic Sans =
MS'">Note -=20
  When we partition a time resource in regular time-slices we create a =
co-cs=20
  mode layer network.&nbsp; When we partition a time resource in =
irregular=20
  time-slices we create a co-ps mode layer network.&nbsp; More =
information on=20
  labelling and resource partitioning can be found in the work on =
unified=20
  modelling (of networks) in G.800.</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=3D"Comic Sans MS" color=3Dmaroon =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: maroon; FONT-FAMILY: 'Comic Sans =
MS'">regards,=20
  Neil</SPAN></FONT><o:p></o:p></P></DIV>
  <BLOCKQUOTE=20
  style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0cm; BORDER-TOP: =
medium none; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0cm; MARGIN: 5pt 0cm 5pt =
3.75pt; BORDER-LEFT: maroon 1.5pt solid; PADDING-TOP: 0cm; =
BORDER-BOTTOM: medium none">
    <P class=3DMsoNormal style=3D"MARGIN-BOTTOM: 12pt"><FONT =
face=3DTahoma=20
    size=3D2><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma">-----Original=20
    Message-----<BR><B><SPAN style=3D"FONT-WEIGHT: =
bold">From:</SPAN></B>=20
    [email-masked] [mailto:[email-masked]] <B><SPAN=20
    style=3D"FONT-WEIGHT: bold">On Behalf Of </SPAN></B><st1:PersonName=20
    w:st=3D"on">Attila Takacs</st1:PersonName><BR><B><SPAN=20
    style=3D"FONT-WEIGHT: bold">Sent:</SPAN></B> 05 December 2007=20
    02:03<BR><B><SPAN style=3D"FONT-WEIGHT: bold">To:</SPAN></B> Thomas =
Nadeau;=20
    Diego Caviglia<BR><B><SPAN style=3D"FONT-WEIGHT: =
bold">Cc:</SPAN></B>=20
    [email-masked]<BR><B><SPAN style=3D"FONT-WEIGHT: =
bold">Subject:</SPAN></B>=20
    RE:=20
    =
draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt</SPAN></FONT><o:p></o:p></P=
    <DIV>
    <P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Hi=20
    Tom,</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">please =
see=20
    inline.</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">Best=20
    regards,</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">Attila</SPAN></FONT><o:p></o:p></P></DIV>
    <BLOCKQUOTE=20
    style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0cm; BORDER-TOP: =
medium none; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0cm; MARGIN: 5pt 0cm 5pt =
3.75pt; BORDER-LEFT: blue 1.5pt solid; PADDING-TOP: 0cm; BORDER-BOTTOM: =
medium none">
      <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN =

      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
      Thomas Nadeau [mailto:[email-masked]] <BR><B><SPAN=20
      style=3D"FONT-WEIGHT: bold">Sent:</SPAN></B> Wednesday, December =
05, 2007=20
      2:19 AM<BR><B><SPAN style=3D"FONT-WEIGHT: bold">To:</SPAN></B> =
Diego=20
      Caviglia<BR><B><SPAN style=3D"FONT-WEIGHT: bold">Cc:</SPAN></B>=20
      <st1:PersonName w:st=3D"on">Attila Takacs</st1:PersonName>;=20
      [email-masked]; [email-masked]<BR><B><SPAN=20
      style=3D"FONT-WEIGHT: bold">Subject:</SPAN></B> Re:=20
      =
draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt</SPAN></FONT><o:p></o:p></P=
      <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN =

      style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
      <DIV>
      <DIV>
      <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN =

      style=3D"FONT-SIZE: 12pt">On Dec 4, 2007, at 7:33 PM, Diego =
Caviglia=20
      wrote:<o:p></o:p></SPAN></FONT></P></DIV>
      <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN =

      style=3D"FONT-SIZE: =
12pt"><BR><BR><o:p></o:p></SPAN></FONT></P><SPAN=20
      style=3D"WORD-SPACING: 0px; orphans: 2; widows: 2; =
webkit-border-horizontal-spacing: 0px; webkit-border-vertical-spacing: =
0px; webkit-text-decorations-in-effect: none; webkit-text-size-adjust: =
auto; webkit-text-stroke-width: 0">
      <DIV=20
      style=3D"WORD-WRAP: break-word; webkit-nbsp-mode: space; =
webkit-line-break: after-white-space"=20
      vlink=3D"blue" link=3D"blue">
      <DIV>
      <DIV>
      <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy =
size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Hi=20
      Thomas,<O:P></O:P></SPAN></FONT><FONT color=3Dblack><SPAN=20
      style=3D"COLOR: black"><o:p></o:p></SPAN></FONT></P></DIV>
      <DIV>
      <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy =
size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
      My understanding of the ID was that RSVP-TE can be used to =
=91piggyback=92 CFM=20
      set-up, otherwise the scenario is: usage of RSVP-TE to set-up the =
LSP and=20
      NMS (meaning everything that is not control plane) to enable to =
CFM for=20
      the LSP.</SPAN></FONT><FONT color=3Dblack><SPAN=20
      style=3D"COLOR: =
black"><o:p></o:p></SPAN></FONT></P></DIV></DIV></DIV></SPAN>
      <DIV>
      <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN =

      style=3D"FONT-SIZE: =
12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P></DIV>
      <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN =

      style=3D"FONT-SIZE: 12pt">As I understand it, the IEEE is working =
on set-up=20
      of CFM (and MEPs), as are some vendors I know.=20
      *)<o:p></o:p></SPAN></FONT></P></DIV>
      <DIV>
      <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN =

      style=3D"FONT-SIZE: 12pt">This to me seems like the right way to =
do=20
      this.<o:p></o:p></SPAN></FONT></P></DIV>
      <DIV>
      <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN =

      style=3D"FONT-SIZE: =
12pt">&nbsp;<o:p></o:p></SPAN></FONT></P></DIV></BLOCKQUOTE>
    <DIV>
    <P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">IEEE =
specified CFM=20
    and MIBs to setup CFM.&nbsp;</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">Diego's =
summary is=20
    correct: one can use an NMS or&nbsp;a control plane to setup the =
data plane.=20
    In this case we propose to use&nbsp;GMPLS to setup the data plane: =
both=20
    forwarding + OAM.</SPAN></FONT><o:p></o:p></P></DIV>
    <BLOCKQUOTE=20
    style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0cm; BORDER-TOP: =
medium none; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0cm; MARGIN: 5pt 0cm 5pt =
3.75pt; BORDER-LEFT: blue 1.5pt solid; PADDING-TOP: 0cm; BORDER-BOTTOM: =
medium none"=20
    type=3D"cite"><SPAN=20
      style=3D"WORD-SPACING: 0px; orphans: 2; widows: 2; =
webkit-border-horizontal-spacing: 0px; webkit-border-vertical-spacing: =
0px; webkit-text-decorations-in-effect: none; webkit-text-size-adjust: =
auto; webkit-text-stroke-width: 0"><O:P></O:P>
      <BLOCKQUOTE style=3D"MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt"><SPAN=20
        style=3D"webkit-text-stroke-width: -1">
        <DIV=20
        style=3D"WORD-WRAP: break-word; webkit-nbsp-mode: space; =
webkit-line-break: after-white-space"=20
        vlink=3D"blue" link=3D"blue">
        <DIV>
        <P class=3DMsoNormal><SPAN class=3Dapple-style-span><FONT=20
        face=3D"Times New Roman" color=3D#144fae size=3D2><SPAN=20
        style=3D"FONT-SIZE: 10pt; COLOR: #144fae">From your comment I =
see that=20
        you=92re not happy with the fact the ID is so technology =
specific am I=20
        right? &nbsp;</SPAN></SPAN></FONT></SPAN><FONT =
color=3Dblack><SPAN=20
        style=3D"COLOR: =
black"><o:p></o:p></SPAN></FONT></P></DIV></DIV></BLOCKQUOTE></SPAN>
      <DIV>
      <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN =

      style=3D"FONT-SIZE: =
12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P></DIV>
      <DIV>
      <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN =

      style=3D"FONT-SIZE: 12pt">Precisely; its gluing CFM to =
RSVP-TE/GMPLS as a=20
      transport.&nbsp;<o:p></o:p></SPAN></FONT></P></DIV></BLOCKQUOTE>
    <DIV>
    <P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">I do not =
see your=20
    point with gluing. What do you mean by "as transport"? GMPLS is just =

    controlling OAM, CFM is run solely in the data=20
    plane.</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=3D"Times New Roman" size=3D3><SPAN=20
    style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P></DIV>
    <BLOCKQUOTE=20
    style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0cm; BORDER-TOP: =
medium none; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0cm; MARGIN: 5pt 0cm 5pt =
3.75pt; BORDER-LEFT: blue 1.5pt solid; PADDING-TOP: 0cm; BORDER-BOTTOM: =
medium none"=20
    type=3D"cite"><SPAN=20
      style=3D"WORD-SPACING: 0px; orphans: 2; widows: 2; =
webkit-border-horizontal-spacing: 0px; webkit-border-vertical-spacing: =
0px; webkit-text-decorations-in-effect: none; webkit-text-size-adjust: =
auto; webkit-text-stroke-width: 0">
      <BLOCKQUOTE style=3D"MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt"><SPAN=20
        style=3D"webkit-text-stroke-width: -1">
        <DIV=20
        style=3D"WORD-WRAP: break-word; webkit-nbsp-mode: space; =
webkit-line-break: after-white-space"=20
        vlink=3D"blue" link=3D"blue">
        <DIV>
        <P class=3DMsoNormal><SPAN class=3Dapple-style-span><FONT=20
        face=3D"Times New Roman" color=3D#144fae size=3D2><SPAN=20
        style=3D"FONT-SIZE: 10pt; COLOR: #144fae">If yes do you agree =
with the=20
        fact that could be useful in general to use the same signaling =
=91session=92=20
        to set-up the LSP and to enable the=20
        CFM?</SPAN></SPAN></FONT></SPAN><FONT color=3Dblack><SPAN=20
        style=3D"COLOR: =
black"><o:p></o:p></SPAN></FONT></P></DIV></DIV></BLOCKQUOTE></SPAN>
      <DIV>
      <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN =

      style=3D"FONT-SIZE: =
12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P></DIV>
      <DIV>
      <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN =

      style=3D"FONT-SIZE: 12pt">No, I do not agree. &nbsp;Again, if CFM =
is to be=20
      set-up e2e, let the IEEE define this. Leave GMPLS to=20
      CCAMP.<o:p></o:p></SPAN></FONT></P></DIV></BLOCKQUOTE>
    <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=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">Sorry, I =
cannot=20
    follow.</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=3D"Times New Roman" size=3D3><SPAN=20
    style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p></SPAN></FONT></P></DIV>
    <BLOCKQUOTE=20
    style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0cm; BORDER-TOP: =
medium none; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0cm; MARGIN: 5pt 0cm 5pt =
3.75pt; BORDER-LEFT: blue 1.5pt solid; PADDING-TOP: 0cm; BORDER-BOTTOM: =
medium none">
      <DIV>
      <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN =

      style=3D"FONT-SIZE: =
12pt">&nbsp;<o:p></o:p></SPAN></FONT></P></DIV>
      <DIV>
      <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN =

      style=3D"FONT-SIZE: =
12pt">&nbsp;<o:p></o:p></SPAN></FONT></P></DIV>
      <DIV>
      <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN =

      style=3D"FONT-SIZE: =
12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P></DIV>
      <DIV>
      <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN =

      style=3D"FONT-SIZE: 12pt">--Tom<o:p></o:p></SPAN></FONT></P></DIV>
      <DIV>
      <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN =

      style=3D"FONT-SIZE: =
12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P></DIV>
      <DIV>
      <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN =

      style=3D"FONT-SIZE: =
12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P></DIV>
      <DIV>
      <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN =

      style=3D"FONT-SIZE: =
12pt"><BR><BR><o:p></o:p></SPAN></FONT></P><SPAN=20
      style=3D"WORD-SPACING: 0px; orphans: 2; widows: 2; =
webkit-border-horizontal-spacing: 0px; webkit-border-vertical-spacing: =
0px; webkit-text-decorations-in-effect: none; webkit-text-size-adjust: =
auto; webkit-text-stroke-width: 0"><O:P>
      <DIV=20
      style=3D"WORD-WRAP: break-word; webkit-nbsp-mode: space; =
webkit-line-break: after-white-space"=20
      vlink=3D"blue" link=3D"blue">
      <DIV>
      <DIV>
      <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy =
size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">&nbsp;<SPAN=20
      style=3D"webkit-text-stroke-width: -1"></SPAN></FONT><SPAN=20
      class=3Dapple-style-span><FONT face=3DArial color=3D#144fae =
size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; COLOR: #144fae; FONT-FAMILY: Arial">Best =

      Regards</SPAN></SPAN></FONT></O:P></SPAN><FONT color=3Dblack><SPAN =

      style=3D"COLOR: black"><o:p></o:p></SPAN></FONT></P></DIV>
      <DIV>
      <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy =
size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><BR>Diego<O:P></O:P></SPAN></FONT><FONT=20
      color=3Dblack><SPAN=20
      style=3D"COLOR: black"><o:p></o:p></SPAN></FONT></P></DIV><FONT=20
      face=3D"Times New Roman" color=3Dblack size=3D3><SPAN=20
      style=3D"FONT-SIZE: 12pt; COLOR: black; FONT-FAMILY: 'Times New =
Roman'"><O:P></O:P></SPAN></FONT>
      <DIV=20
      style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0cm; =
BORDER-TOP: medium none; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0cm; =
BORDER-LEFT: blue 1.5pt solid; PADDING-TOP: 0cm; BORDER-BOTTOM: medium =
none">
      <DIV>
      <DIV class=3DMsoNormal style=3D"TEXT-ALIGN: center" =
align=3Dcenter><FONT=20
      face=3D"Times New Roman" color=3Dblack size=3D3><SPAN=20
      style=3D"FONT-SIZE: 12pt; COLOR: black">
      <HR tabIndex=3D-1 align=3Dcenter width=3D"100%" SIZE=3D2>
      </SPAN></FONT></DIV>
      <DIV>
      <P class=3DMsoNormal><B><FONT face=3DTahoma color=3Dblack =
size=3D2><SPAN=20
      style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; COLOR: black; =
FONT-FAMILY: Tahoma">From:</SPAN></FONT></B><SPAN=20
      class=3Dapple-converted-space><FONT face=3DTahoma color=3Dblack =
size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: =
Tahoma">&nbsp;</SPAN></FONT></SPAN><FONT=20
      face=3DTahoma color=3Dblack size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: Tahoma"><A=20
      =
href=3D"mailto:[email-masked]">[email-masked]</A> =
[<A=20
      =
href=3D"mailto:[email-masked]">mailto:[email-masked]<=
/A>]<SPAN=20
      class=3Dapple-converted-space>&nbsp;</SPAN><B><SPAN=20
      style=3D"FONT-WEIGHT: bold">On Behalf Of<SPAN=20
      class=3Dapple-converted-space>&nbsp;</SPAN></SPAN></B>Thomas=20
      Nadeau<BR><B><SPAN style=3D"FONT-WEIGHT: =
bold">Sent:</SPAN></B><SPAN=20
      class=3Dapple-converted-space>&nbsp;</SPAN>marted=EC 4 dicembre =
2007=20
      11.30<BR><B><SPAN style=3D"FONT-WEIGHT: bold">To:</SPAN></B><SPAN=20
      class=3Dapple-converted-space>&nbsp;</SPAN><st1:PersonName =
w:st=3D"on">Attila=20
      Takacs</st1:PersonName><BR><B><SPAN=20
      style=3D"FONT-WEIGHT: bold">Cc:</SPAN></B><SPAN=20
      class=3Dapple-converted-space>&nbsp;</SPAN><A=20
      href=3D"mailto:[email-masked]">[email-masked]</A>;<SPAN=20
      class=3Dapple-converted-space>&nbsp;</SPAN><A=20
      =
href=3D"mailto:[email-masked]">[email-masked]</A><BR>=
<B><SPAN=20
      style=3D"FONT-WEIGHT: bold">Subject:</SPAN></B><SPAN=20
      class=3Dapple-converted-space>&nbsp;</SPAN>Re:=20
      draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt</SPAN></FONT><FONT=20
      color=3Dblack><SPAN=20
      style=3D"COLOR: =
black"><o:p></o:p></SPAN></FONT></P><O:P></O:P></DIV></DIV>
      <DIV>
      <DIV>
      <DIV>
      <P class=3DMsoNormal><FONT face=3D"Times New Roman" color=3Dblack =
size=3D3><SPAN=20
      style=3D"FONT-SIZE: 12pt; COLOR: black"><O:P></O:P><O:P></O:P>On =
Dec 4,=20
      2007, at 1:51 PM, <st1:PersonName w:st=3D"on">Attila =
Takacs</st1:PersonName>=20
      wrote:<O:P></O:P><o:p></o:p></SPAN></FONT></P></DIV></DIV>
      <DIV>
      <P class=3DMsoNormal><FONT face=3D"Times New Roman" color=3Dblack =
size=3D3><SPAN=20
      style=3D"FONT-SIZE: 12pt; COLOR: =
black"><BR><BR><BR><o:p></o:p></SPAN></FONT></P></DIV><O:P></O:P>
      <DIV style=3D"WORD-WRAP: break-word">
      <DIV>
      <DIV>
      <P class=3DMsoNormal><FONT face=3DArial color=3Dblue =
size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Hi=20
      Thomas,</SPAN></FONT><FONT color=3Dblack><SPAN=20
      style=3D"COLOR: =
black"><o:p></o:p></SPAN></FONT></P><O:P></O:P></DIV></DIV>
      <DIV>
      <DIV>
      <P class=3DMsoNormal><FONT face=3DArial color=3Dblue =
size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
Arial"><O:P></O:P>Thank=20
      you&nbsp;for the comments!</SPAN></FONT><FONT color=3Dblack><SPAN=20
      style=3D"COLOR: =
black"><o:p></o:p></SPAN></FONT></P><O:P></O:P></DIV></DIV>
      <DIV>
      <DIV>
      <P class=3DMsoNormal><FONT face=3DArial color=3Dblue =
size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Please =
see=20
      answers inline.</SPAN></FONT><FONT color=3Dblack><SPAN=20
      style=3D"COLOR: =
black"><o:p></o:p></SPAN></FONT></P><O:P></O:P></DIV></DIV>
      <DIV>
      <DIV>
      <P class=3DMsoNormal><FONT face=3DArial color=3Dblue =
size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
Arial"><O:P></O:P>Best=20
      regards,<BR>Attila</SPAN></FONT><FONT color=3Dblack><SPAN=20
      style=3D"COLOR: =
black"><o:p></o:p></SPAN></FONT></P><O:P></O:P></DIV></DIV><FONT=20
      face=3D"Times New Roman" color=3Dblack size=3D3><SPAN=20
      style=3D"FONT-SIZE: 12pt; COLOR: black; FONT-FAMILY: 'Times New =
Roman'"><O:P></O:P></SPAN></FONT>
      <BLOCKQUOTE=20
      style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0cm; =
BORDER-TOP: medium none; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0cm; MARGIN: =
5pt 0cm 5pt 3.75pt; BORDER-LEFT: blue 1.5pt solid; PADDING-TOP: 0cm; =
BORDER-BOTTOM: medium none">
        <DIV class=3DMsoNormal style=3D"TEXT-ALIGN: center" =
align=3Dcenter><FONT=20
        face=3D"Times New Roman" color=3Dblack size=3D3><SPAN=20
        style=3D"FONT-SIZE: 12pt; COLOR: black">
        <HR tabIndex=3D-1 align=3Dcenter width=3D"100%" SIZE=3D2>
        </SPAN></FONT></DIV>
        <DIV>
        <P class=3DMsoNormal><B><FONT face=3DTahoma color=3Dblack =
size=3D2><SPAN=20
        style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; COLOR: black; =
FONT-FAMILY: Tahoma">From:</SPAN></FONT></B><SPAN=20
        class=3Dapple-converted-space><FONT face=3DTahoma color=3Dblack =
size=3D2><SPAN=20
        style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: =
Tahoma">&nbsp;</SPAN></FONT></SPAN><FONT=20
        face=3DTahoma color=3Dblack size=3D2><SPAN=20
        style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: =
Tahoma">Thomas Nadeau=20
        [<A=20
        =
href=3D"mailto:[email-masked]">mailto:[email-masked]</A=
>]<SPAN=20
        class=3Dapple-converted-space>&nbsp;</SPAN><BR><B><SPAN=20
        style=3D"FONT-WEIGHT: bold">Sent:</SPAN></B><SPAN=20
        class=3Dapple-converted-space>&nbsp;</SPAN>Tuesday, December 04, =
2007 2:58=20
        PM<BR><B><SPAN style=3D"FONT-WEIGHT: bold">To:</SPAN></B><SPAN=20
        class=3Dapple-converted-space>&nbsp;</SPAN><A=20
        =
href=3D"mailto:[email-masked]">[email-masked]</A><BR><B><SPAN=20
        style=3D"FONT-WEIGHT: bold">Cc:</SPAN></B><SPAN=20
        class=3Dapple-converted-space>&nbsp;</SPAN><st1:PersonName=20
        w:st=3D"on">Attila Takacs</st1:PersonName>;<SPAN=20
        class=3Dapple-converted-space>&nbsp;</SPAN><A=20
        =
href=3D"mailto:[email-masked]">[email-masked]</A><BR>=
<B><SPAN=20
        style=3D"FONT-WEIGHT: bold">Subject:</SPAN></B><SPAN=20
        =
class=3Dapple-converted-space>&nbsp;</SPAN>draft-takacs-ccamp-rsvp-te-eth=
-oam-ext-00.txt</SPAN></FONT><FONT=20
        color=3Dblack><SPAN=20
        style=3D"COLOR: =
black"><o:p></o:p></SPAN></FONT></P><O:P></O:P></DIV>
        <DIV>
        <DIV>
        <P class=3DMsoNormal><FONT face=3D"Times New Roman" =
color=3Dblack size=3D3><SPAN=20
        style=3D"FONT-SIZE: 12pt; COLOR: =
black"><O:P></O:P><O:P></O:P>After=20
        reading this draft, I have some=20
        =
questions/comments.<O:P></O:P><o:p></o:p></SPAN></FONT></P></DIV></DIV>
        <DIV>
        <DIV>
        <P class=3DMsoNormal><FONT face=3D"Times New Roman" =
color=3Dblack size=3D3><SPAN=20
        style=3D"FONT-SIZE: 12pt; COLOR: black"><O:P></O:P>1) =
Overall,&nbsp;I am=20
        concerned that the definition of a new TLV and these procedures=20
        =
represent&nbsp;<O:P></O:P><o:p></o:p></SPAN></FONT></P></DIV></DIV>
        <DIV>
        <DIV>
        <P class=3DMsoNormal><FONT face=3D"Times New Roman" =
color=3Dblack size=3D3><SPAN=20
        style=3D"FONT-SIZE: 12pt; COLOR: black">what amounts to a laying =
violation=20
        and ask that the ADs take a look at=20
        this<O:P></O:P><o:p></o:p></SPAN></FONT></P></DIV></DIV>
        <DIV>
        <DIV>
        <P class=3DMsoNormal><FONT face=3D"Times New Roman" =
color=3Dblack size=3D3><SPAN=20
        style=3D"FONT-SIZE: 12pt; COLOR: black">approach closely. This =
is similar=20
        to the now-rejected approach that was=20
        proposed<O:P></O:P><o:p></o:p></SPAN></FONT></P></DIV></DIV>
        <DIV>
        <DIV>
        <P class=3DMsoNormal><FONT face=3D"Times New Roman" =
color=3Dblack size=3D3><SPAN=20
        style=3D"FONT-SIZE: 12pt; COLOR: black">in the l2vpn WG about =
munging CFM=20
        + PWs. &nbsp;To my reading, this is=20
        essentially<O:P></O:P><o:p></o:p></SPAN></FONT></P></DIV></DIV>
        <DIV>
        <DIV>
        <P class=3DMsoNormal><FONT face=3D"Times New Roman" =
color=3Dblack size=3D3><SPAN=20
        style=3D"FONT-SIZE: 12pt; COLOR: black">the same thing. If you =
want to run=20
        CFM, run it natively over the ethernet interfaces=20
        and<O:P></O:P><o:p></o:p></SPAN></FONT></P></DIV></DIV>
        <DIV>
        <DIV>
        <P class=3DMsoNormal><FONT face=3D"Times New Roman" =
color=3Dblack size=3D3><SPAN=20
        style=3D"FONT-SIZE: 12pt; COLOR: black">have no regard for the =
underlying=20
        topology (GMPLS, PWs, etc...) otherwise=20
        you&nbsp;<O:P></O:P><o:p></o:p></SPAN></FONT></P></DIV></DIV>
        <DIV>
        <DIV>
        <P class=3DMsoNormal><FONT face=3D"Times New Roman" =
color=3Dblack size=3D3><SPAN=20
        style=3D"FONT-SIZE: 12pt; COLOR: black">will be creating a mess =
for=20
        implementations and interoperability.&nbsp;</SPAN></FONT><FONT=20
        face=3DArial color=3Dblue size=3D2><SPAN=20
        style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
Arial">&nbsp;</SPAN></FONT><FONT=20
        color=3Dblack><SPAN=20
        style=3D"COLOR: =
black"><o:p></o:p></SPAN></FONT></P><O:P></O:P></DIV></DIV></BLOCKQUOTE>
      <DIV>
      <DIV>
      <P class=3DMsoNormal><FONT face=3DArial color=3Dblue =
size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">The=20
      application&nbsp;of the draft is exactly for what you are calling =
out:=20
      when CFM is run natively over the Ethernet interfaces. The =
document=20
      focuses on GELS and Ethernet LSPs.&nbsp;That is,&nbsp;to establish =
CFM=20
      entities for GMPLS controlled Ethernet LSPs.&nbsp;Hence, I think =
there is=20
      no layer violation issue.</SPAN></FONT><FONT color=3Dblack><SPAN=20
      style=3D"COLOR: =
black"><o:p></o:p></SPAN></FONT></P><O:P></O:P></DIV></DIV></DIV>
      <DIV>
      <P class=3DMsoNormal><SPAN class=3Dapple-tab-span><O:P></O:P><FONT =

      face=3D"Times New Roman" color=3Dblack size=3D3><SPAN=20
      style=3D"FONT-SIZE: 12pt; COLOR: =
black">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</SPAN></FON=
T></SPAN><SPAN=20
      class=3Dapple-converted-space><FONT color=3Dblack><SPAN=20
      style=3D"COLOR: black">&nbsp;</SPAN></FONT></SPAN><FONT =
color=3Dblack><SPAN=20
      style=3D"COLOR: black">This solution specifically only works for =
GMPLS=20
      ethernet LSPs, right?=20
      &nbsp;<o:p></o:p></SPAN></FONT></P><O:P></O:P></DIV></DIV>
      <DIV>
      <DIV>
      <P class=3DMsoNormal><FONT face=3D"Times New Roman" color=3Dblack =
size=3D3><SPAN=20
      style=3D"FONT-SIZE: 12pt; COLOR: black">What do I do if I want to =
set up=20
      MPLS ethernet LSPs (i.e.: PWs)&nbsp;and do CFM over those?=20
      Oh,<O:P></O:P><o:p></o:p></SPAN></FONT></P></DIV></DIV>
      <DIV>
      <DIV>
      <P class=3DMsoNormal><FONT face=3D"Times New Roman" color=3Dblack =
size=3D3><SPAN=20
      style=3D"FONT-SIZE: 12pt; COLOR: black">that is a different =
solution, right?=20
      &nbsp;Then what do I do if I want to run CFM over some new type=20
      of<O:P></O:P><o:p></o:p></SPAN></FONT></P></DIV></DIV>
      <DIV>
      <DIV>
      <P class=3DMsoNormal><FONT face=3D"Times New Roman" color=3Dblack =
size=3D3><SPAN=20
      style=3D"FONT-SIZE: 12pt; COLOR: black">ethernet LSP in the =
future? More=20
      protocol hacks? &nbsp;The point is to use CFM over an ethernet=20
      interface<O:P></O:P><o:p></o:p></SPAN></FONT></P></DIV></DIV>
      <DIV>
      <DIV>
      <P class=3DMsoNormal><FONT face=3D"Times New Roman" color=3Dblack =
size=3D3><SPAN=20
      style=3D"FONT-SIZE: 12pt; COLOR: black">without the underlying =
layers=20
      knowing. This is good networking architecture design, that=20
      simplifies<O:P></O:P><o:p></o:p></SPAN></FONT></P></DIV></DIV>
      <DIV>
      <DIV>
      <P class=3DMsoNormal><FONT face=3D"Times New Roman" color=3Dblack =
size=3D3><SPAN=20
      style=3D"FONT-SIZE: 12pt; COLOR: black">implementations and makes =
them more=20
      robust, as well as makes using them operationally=20
      much<O:P></O:P><o:p></o:p></SPAN></FONT></P></DIV></DIV>
      <DIV>
      <DIV>
      <P class=3DMsoNormal><FONT face=3D"Times New Roman" color=3Dblack =
size=3D3><SPAN=20
      style=3D"FONT-SIZE: 12pt; COLOR: =
black">easier.&nbsp;<O:P></O:P><o:p></o:p></SPAN></FONT></P></DIV></DIV>
      <DIV>
      <BLOCKQUOTE style=3D"MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt" =
type=3D"cite">
        <DIV style=3D"WORD-WRAP: break-word">
        <BLOCKQUOTE=20
        style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0cm; =
BORDER-TOP: medium none; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0cm; MARGIN: =
5pt 0cm 5pt 3.75pt; BORDER-LEFT: blue 1.5pt solid; PADDING-TOP: 0cm; =
BORDER-BOTTOM: medium none">
          <DIV>
          <DIV>
          <P class=3DMsoNormal><FONT face=3D"Times New Roman" =
color=3Dblack=20
          size=3D3><SPAN style=3D"FONT-SIZE: 12pt; COLOR: =
black">2)&nbsp;The=20
          introductory sections in this draft give a lot of discussion =
about=20
          fast fault detection.=20
          I<O:P></O:P><o:p></o:p></SPAN></FONT></P></DIV></DIV>
          <DIV>
          <DIV>
          <P class=3DMsoNormal><FONT face=3D"Times New Roman" =
color=3Dblack=20
          size=3D3><SPAN style=3D"FONT-SIZE: 12pt; COLOR: black">am =
puzzled by this=20
          given that GMPLS networks tend to run over quickly=20
          =
self-healing<O:P></O:P><o:p></o:p></SPAN></FONT></P></DIV></DIV>
          <DIV>
          <DIV>
          <P class=3DMsoNormal><FONT face=3D"Times New Roman" =
color=3Dblack=20
          size=3D3><SPAN style=3D"FONT-SIZE: 12pt; COLOR: black">optical =

          infrastructures. Is it therefore&nbsp;truly&nbsp;necessary to =
motivate=20
          this work =
by<O:P></O:P><o:p></o:p></SPAN></FONT></P></DIV></DIV>
          <DIV>
          <DIV>
          <P class=3DMsoNormal><FONT face=3D"Times New Roman" =
color=3Dblack=20
          size=3D3><SPAN style=3D"FONT-SIZE: 12pt; COLOR: =
black">requiring fast=20
          =
CFMs?<O:P></O:P><o:p></o:p></SPAN></FONT></P></DIV></DIV></BLOCKQUOTE>
        <DIV>
        <DIV>
        <P class=3DMsoNormal><FONT face=3DArial color=3Dblue =
size=3D2><SPAN=20
        style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">It is =
right=20
        that frequent CCMs are not required if the layers below Ethernet =
handle=20
        protection. However, the ID focuses on Ethernet LSPs where =
Ethernet=20
        is&nbsp;not just a single hop&nbsp;above a transport =
LSP.&nbsp;In this=20
        case&nbsp;Ethernet layer (for clarity GELS) may provide =
protection for=20
        Ethernet LSPs.&nbsp;In any case,&nbsp; the whole point of the ID =
is to=20
        allow for the appropriate configuration of CFM for Ethernet LSPs =
with=20
        GMPLS.</SPAN></FONT><FONT color=3Dblack><SPAN=20
        style=3D"COLOR: =
black"><o:p></o:p></SPAN></FONT></P><O:P></O:P></DIV></DIV>
        <BLOCKQUOTE=20
        style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0cm; =
BORDER-TOP: medium none; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0cm; MARGIN: =
5pt 0cm 5pt 3.75pt; BORDER-LEFT: blue 1.5pt solid; PADDING-TOP: 0cm; =
BORDER-BOTTOM: medium none">
          <DIV>
          <DIV>
          <P class=3DMsoNormal><FONT face=3D"Times New Roman" =
color=3Dblack=20
          size=3D3><SPAN style=3D"FONT-SIZE: 12pt; COLOR: =
black"><O:P></O:P>3) This=20
          document does not cover E-LMI. Why=20
          =
not?<O:P></O:P><o:p></o:p></SPAN></FONT></P></DIV></DIV></BLOCKQUOTE>
        <DIV>
        <DIV>
        <P class=3DMsoNormal><FONT face=3DArial color=3Dblue =
size=3D2><SPAN=20
        style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">E-LMI =
is run=20
        over the MEF UNI. The&nbsp;ID focuses on Ethernet LSPs within a=20
        network.</SPAN></FONT><FONT color=3Dblack><SPAN=20
        style=3D"COLOR: =
black"><o:p></o:p></SPAN></FONT></P><O:P></O:P></DIV></DIV>
        <BLOCKQUOTE=20
        style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0cm; =
BORDER-TOP: medium none; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0cm; MARGIN: =
5pt 0cm 5pt 3.75pt; BORDER-LEFT: blue 1.5pt solid; PADDING-TOP: 0cm; =
BORDER-BOTTOM: medium none">
          <DIV>
          <DIV>
          <P class=3DMsoNormal><SPAN =
class=3Dapple-style-span><O:P></O:P><FONT=20
          face=3D"Times New Roman" color=3Dblack size=3D1><SPAN=20
          style=3D"FONT-SIZE: 9pt; COLOR: black"><O:P></O:P>For the =
purposes of=20
          this document, we only discuss Ethernet =
OAM</SPAN></FONT></SPAN><FONT=20
          color=3Dblack><SPAN=20
          style=3D"COLOR: =
black"><o:p></o:p></SPAN></FONT></P><O:P></O:P></DIV></DIV>
          <DIV>
          <DIV>
          <P class=3DMsoNormal><FONT face=3DHelvetica color=3Dblack =
size=3D1><SPAN=20
          style=3D"FONT-SIZE: 9pt; COLOR: black; FONT-FAMILY: =
Helvetica">&nbsp;&nbsp;=20
          [IEEE-CFM] aspects that are relevant for the connectivity=20
          monitoring<O:P></O:P></SPAN></FONT><FONT color=3Dblack><SPAN=20
          style=3D"COLOR: =
black"><o:p></o:p></SPAN></FONT></P></DIV></DIV>
          <DIV>
          <DIV>
          <P class=3DMsoNormal><FONT face=3DHelvetica color=3Dblack =
size=3D1><SPAN=20
          style=3D"FONT-SIZE: 9pt; COLOR: black; FONT-FAMILY: =
Helvetica">&nbsp;&nbsp;=20
          of bidirectional point-to-point PBB-TE connections.=20
          &nbsp;<O:P></O:P></SPAN></FONT><FONT color=3Dblack><SPAN=20
          style=3D"COLOR: =
black"><o:p></o:p></SPAN></FONT></P></DIV></DIV>
          <DIV>
          <DIV>
          <P class=3DMsoNormal><FONT face=3DHelvetica color=3Dblack =
size=3D1><SPAN=20
          style=3D"FONT-SIZE: 9pt; COLOR: black; FONT-FAMILY: =
Helvetica"><O:P></O:P>4)=20
          Is this the right place to define this document or should this =
be done=20
          in GELS?<O:P></O:P></SPAN></FONT><FONT color=3Dblack><SPAN=20
          style=3D"COLOR: =
black"><o:p></o:p></SPAN></FONT></P></DIV></DIV></BLOCKQUOTE>
        <DIV>
        <DIV>
        <P class=3DMsoNormal><FONT face=3DArial color=3Dblue =
size=3D2><SPAN=20
        style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Well, =
GELS is=20
        done in CCAMP...this seems to be the right =
place.</SPAN></FONT><FONT=20
        color=3Dblack><SPAN=20
        style=3D"COLOR: =
black"><o:p></o:p></SPAN></FONT></P><O:P></O:P></DIV></DIV>
        <BLOCKQUOTE=20
        style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0cm; =
BORDER-TOP: medium none; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0cm; MARGIN: =
5pt 0cm 5pt 3.75pt; BORDER-LEFT: blue 1.5pt solid; PADDING-TOP: 0cm; =
BORDER-BOTTOM: medium none">
          <DIV>
          <DIV>
          <P class=3DMsoNormal><FONT face=3DHelvetica color=3Dblack =
size=3D1><SPAN=20
          style=3D"FONT-SIZE: 9pt; COLOR: black; FONT-FAMILY: =
Helvetica"><O:P></O:P><O:P></O:P>5)=20
          &nbsp; In section 2 you make the following=20
          statement:<O:P></O:P></SPAN></FONT><FONT color=3Dblack><SPAN=20
          style=3D"COLOR: =
black"><o:p></o:p></SPAN></FONT></P></DIV></DIV>
          <DIV>
          <DIV>
          <P class=3DMsoNormal><FONT face=3DHelvetica color=3Dblack =
size=3D1><SPAN=20
          style=3D"FONT-SIZE: 9pt; COLOR: black; FONT-FAMILY: =
Helvetica"><O:P></O:P>2.&nbsp;=20
          GMPLS RSVP-TE Extensions<O:P></O:P></SPAN></FONT><FONT=20
          color=3Dblack><SPAN=20
          style=3D"COLOR: =
black"><o:p></o:p></SPAN></FONT></P></DIV></DIV>
          <DIV>
          <DIV>
          <P class=3DMsoNormal><FONT face=3DHelvetica color=3Dblack =
size=3D1><SPAN=20
          style=3D"FONT-SIZE: 9pt; COLOR: black; FONT-FAMILY: =
Helvetica"><O:P></O:P>&nbsp;<SPAN=20
          class=3Dapple-converted-space>&nbsp;</SPAN>&nbsp; To simplify =
the=20
          configuration of connectivity monitoring, when=20
          an<O:P></O:P></SPAN></FONT><FONT color=3Dblack><SPAN=20
          style=3D"COLOR: =
black"><o:p></o:p></SPAN></FONT></P></DIV></DIV>
          <DIV>
          <DIV>
          <P class=3DMsoNormal><FONT face=3DHelvetica color=3Dblack =
size=3D1><SPAN=20
          style=3D"FONT-SIZE: 9pt; COLOR: black; FONT-FAMILY: =
Helvetica">&nbsp;&nbsp;=20
          Ethernet LSP is signalled the associated MEPs should be=20
          automatically<O:P></O:P></SPAN></FONT><FONT =
color=3Dblack><SPAN=20
          style=3D"COLOR: =
black"><o:p></o:p></SPAN></FONT></P></DIV></DIV>
          <DIV>
          <DIV>
          <P class=3DMsoNormal><FONT face=3DHelvetica color=3Dblack =
size=3D1><SPAN=20
          style=3D"FONT-SIZE: 9pt; COLOR: black; FONT-FAMILY: =
Helvetica">&nbsp;<SPAN=20
          class=3Dapple-converted-space>&nbsp;</SPAN>&nbsp; =
established.&nbsp;=20
          Further more, GMPLS signalling should be able=20
          to<O:P></O:P></SPAN></FONT><FONT color=3Dblack><SPAN=20
          style=3D"COLOR: =
black"><o:p></o:p></SPAN></FONT></P></DIV></DIV>
          <DIV>
          <DIV>
          <P class=3DMsoNormal><FONT face=3DHelvetica color=3Dblack =
size=3D1><SPAN=20
          style=3D"FONT-SIZE: 9pt; COLOR: black; FONT-FAMILY: =
Helvetica">&nbsp;&nbsp;enable/disable=20
          connectivity monitoring of a particular Ethernet=20
          LSP.<O:P></O:P></SPAN></FONT><FONT color=3Dblack><SPAN=20
          style=3D"COLOR: =
black"><o:p></o:p></SPAN></FONT></P></DIV></DIV>
          <DIV>
          <DIV>
          <P class=3DMsoNormal><FONT face=3DHelvetica color=3Dblack =
size=3D1><SPAN=20
          style=3D"FONT-SIZE: 9pt; COLOR: black; FONT-FAMILY: =
Helvetica"><O:P></O:P><O:P></O:P>To=20
          my point in #1 above, you should use the native CFM =
functionality over=20
          the ethernet interface and =
signal<O:P></O:P></SPAN></FONT><FONT=20
          color=3Dblack><SPAN=20
          style=3D"COLOR: =
black"><o:p></o:p></SPAN></FONT></P></DIV></DIV>
          <DIV>
          <DIV>
          <P class=3DMsoNormal><FONT face=3DHelvetica color=3Dblack =
size=3D1><SPAN=20
          style=3D"FONT-SIZE: 9pt; COLOR: black; FONT-FAMILY: =
Helvetica">those=20
          capabilities to the bridges at both ends using the IEEE CFM =
signaling=20
          procedures (when and if they<O:P></O:P></SPAN></FONT><FONT=20
          color=3Dblack><SPAN=20
          style=3D"COLOR: =
black"><o:p></o:p></SPAN></FONT></P></DIV></DIV>
          <DIV>
          <DIV>
          <P class=3DMsoNormal><FONT face=3DHelvetica color=3Dblack =
size=3D1><SPAN=20
          style=3D"FONT-SIZE: 9pt; COLOR: black; FONT-FAMILY: =
Helvetica">are=20
          created). &nbsp;If you want to test the underlying GMPLS =
LSP(s), then=20
          you should use some<O:P></O:P></SPAN></FONT><FONT =
color=3Dblack><SPAN=20
          style=3D"COLOR: =
black"><o:p></o:p></SPAN></FONT></P></DIV></DIV>
          <DIV>
          <DIV>
          <P class=3DMsoNormal><FONT face=3DHelvetica color=3Dblack =
size=3D1><SPAN=20
          style=3D"FONT-SIZE: 9pt; COLOR: black; FONT-FAMILY: =
Helvetica">other=20
          mechanism defined for that layer such as the work stated=20
          in&nbsp;</SPAN></FONT><SPAN class=3Dapple-style-span><B><FONT=20
          face=3DHelvetica color=3Dblack size=3D2><SPAN=20
          style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; COLOR: black; =
FONT-FAMILY: =
Helvetica">draft-ali-ccamp-gmpls-LSP-ping-traceroute-00.txt</SPAN></FONT>=
</B></SPAN><FONT=20
          color=3Dblack><SPAN=20
          style=3D"COLOR: =
black"><O:P></O:P><o:p></o:p></SPAN></FONT></P></DIV></DIV></BLOCKQUOTE>
        <DIV>
        <DIV>
        <P class=3DMsoNormal><FONT face=3DArial color=3Dblue =
size=3D2><SPAN=20
        style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">See =
the=20
        note&nbsp;to your point #1. There is no relation&nbsp;to the=20
        gmpls-LSP-ping draft.&nbsp;</SPAN></FONT><FONT =
color=3Dblack><SPAN=20
        style=3D"COLOR: =
black"><O:P></O:P><o:p></o:p></SPAN></FONT></P></DIV></DIV></DIV></BLOCKQ=
UOTE>
      <DIV>
      <P class=3DMsoNormal><SPAN class=3Dapple-tab-span><O:P></O:P><FONT =

      face=3D"Times New Roman" color=3Dblack size=3D3><SPAN=20
      style=3D"FONT-SIZE: 12pt; COLOR: =
black">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</SPAN></FON=
T></SPAN><SPAN=20
      class=3Dapple-converted-space><FONT color=3Dblack><SPAN=20
      style=3D"COLOR: black">&nbsp;</SPAN></FONT></SPAN><FONT =
color=3Dblack><SPAN=20
      style=3D"COLOR: black">The point I am making is that perhaps it=20
      should.<o:p></o:p></SPAN></FONT></P><O:P></O:P></DIV></DIV>
      <DIV>
      <DIV>
      <P class=3DMsoNormal><SPAN class=3Dapple-tab-span><O:P></O:P><FONT =

      face=3D"Times New Roman" color=3Dblack size=3D3><SPAN=20
      style=3D"FONT-SIZE: 12pt; COLOR: =
black">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</SPAN></FON=
T></SPAN><SPAN=20
      class=3Dapple-converted-space><FONT color=3Dblack><SPAN=20
      style=3D"COLOR: black">&nbsp;</SPAN></FONT></SPAN><FONT =
color=3Dblack><SPAN=20
      style=3D"COLOR: =
black">--Tom<o:p></o:p></SPAN></FONT></P><O:P></O:P></DIV></DIV></DIV></D=
IV></DIV></DIV>
      <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN =

      style=3D"FONT-SIZE: =
12pt"><O:P></O:P><o:p>&nbsp;</o:p></SPAN></FONT></P></BLOCKQUOTE></BLOCKQ=
UOTE></DIV><O:P></O:P><O:P></O:P><O:P></O:P><O:P></O:P><O:P></O:P></SPAN>=
</DIV></BLOCKQUOTE></BODY></HTML>

--Boundary_(ID_ri+RKGJ58xhymCKK5aRKfw)--

Delivery-date: Wed, 05 Dec 2007 16:53:44 +0000
Content-class: urn:content-classes:message
Subject: RE: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt
Date: Wed, 5 Dec 2007 17:52:41 +0100
From: "Diego Caviglia" <[email-masked]>
To: "Thomas Nadeau" <[email-masked]>
Cc: "Attila Takacs" <[email-masked]>, <[email-masked]>, <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C8375F.41AC3A97
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Thomas,

                  Please see some more comment in line.

=20

BR

=20

Diego

=20

________________________________

From: Thomas Nadeau [mailto:[email-masked]]=20
Sent: marted=EC 4 dicembre 2007 17.19
To: Diego Caviglia
Cc: Attila Takacs; [email-masked]; [email-masked]
Subject: Re: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt

=20

=20

On Dec 4, 2007, at 7:33 PM, Diego Caviglia wrote:

Hi Thomas,

                 My understanding of the ID was that RSVP-TE can be used =
to 'piggyback' CFM set-up, otherwise the scenario is: usage of RSVP-TE =
to set-up the LSP and NMS (meaning everything that is not control plane) =
to enable to CFM for the LSP.

=20

          As I understand it, the IEEE is working on set-up of CFM (and =
MEPs), as are some vendors I know. *)

This to me seems like the right way to do this.

[DC] no doubt about this and in fact I don't think the ID was about =
defining the CFM is was just about the usage of GMPLS to enable it.

>From your comment I see that you're not happy with the fact the ID is so =
technology specific am I right? =20

=20

          Precisely; its gluing CFM to RSVP-TE/GMPLS as a transport.=20

If yes do you agree with the fact that could be useful in general to use =
the same signaling 'session' to set-up the LSP and to enable the CFM?

=20

          No, I do not agree.  Again, if CFM is to be set-up e2e, let =
the IEEE define this. Leave GMPLS to CCAMP.

[DC] I think that we have a total agreement on this, no one is saying =
that CCAMP has to define the or re-define the CFM as no one redefined =
g707 or other SDH ITU-T spec when we developed GMPLS for SONET/SDH.

=20

          --Tom

=20

=20

 Best Regards

Diego

=20

________________________________

From: [email-masked] [mailto:[email-masked]] On =
Behalf Of Thomas Nadeau
Sent: marted=EC 4 dicembre 2007 11.30
To: Attila Takacs
Cc: [email-masked]; [email-masked]
Subject: Re: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt

=20

=20

On Dec 4, 2007, at 1:51 PM, Attila Takacs wrote:

Hi Thomas,

=20

Thank you for the comments!

Please see answers inline.

=20

Best regards,
Attila

	=20

=09
________________________________

	From: Thomas Nadeau [mailto:[email-masked]]=20
	Sent: Tuesday, December 04, 2007 2:58 PM
	To: [email-masked]
	Cc: Attila Takacs; [email-masked]
	Subject: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt

	=20

	=20

	After reading this draft, I have some questions/comments.

	=20

	1) Overall, I am concerned that the definition of a new TLV and these =
procedures represent=20

	what amounts to a laying violation and ask that the ADs take a look at =
this

	approach closely. This is similar to the now-rejected approach that was =
proposed

	in the l2vpn WG about munging CFM + PWs.  To my reading, this is =
essentially

	the same thing. If you want to run CFM, run it natively over the =
ethernet interfaces and

	have no regard for the underlying topology (GMPLS, PWs, etc...) =
otherwise you=20

	will be creating a mess for implementations and interoperability. =20

The application of the draft is exactly for what you are calling out: =
when CFM is run natively over the Ethernet interfaces. The document =
focuses on GELS and Ethernet LSPs. That is, to establish CFM entities =
for GMPLS controlled Ethernet LSPs. Hence, I think there is no layer =
violation issue.

=20

          This solution specifically only works for GMPLS ethernet LSPs, =
right? =20

What do I do if I want to set up MPLS ethernet LSPs (i.e.: PWs) and do =
CFM over those? Oh,

that is a different solution, right?  Then what do I do if I want to run =
CFM over some new type of

ethernet LSP in the future? More protocol hacks?  The point is to use =
CFM over an ethernet interface

without the underlying layers knowing. This is good networking =
architecture design, that simplifies

implementations and makes them more robust, as well as makes using them =
operationally much

easier.=20

		2) The introductory sections in this draft give a lot of discussion =
about fast fault detection. I

		am puzzled by this given that GMPLS networks tend to run over quickly =
self-healing

		optical infrastructures. Is it therefore truly necessary to motivate =
this work by

		requiring fast CFMs?

	It is right that frequent CCMs are not required if the layers below =
Ethernet handle protection. However, the ID focuses on Ethernet LSPs =
where Ethernet is not just a single hop above a transport LSP. In this =
case Ethernet layer (for clarity GELS) may provide protection for =
Ethernet LSPs. In any case,  the whole point of the ID is to allow for =
the appropriate configuration of CFM for Ethernet LSPs with GMPLS.

	=20

		3) This document does not cover E-LMI. Why not?

	E-LMI is run over the MEF UNI. The ID focuses on Ethernet LSPs within a =
network.

	=20

	=20

		For the purposes of this document, we only discuss Ethernet OAM

		   [IEEE-CFM] aspects that are relevant for the connectivity =
monitoring

		   of bidirectional point-to-point PBB-TE connections. =20

		=20

		4) Is this the right place to define this document or should this be =
done in GELS?

	Well, GELS is done in CCAMP...this seems to be the right place.

		=20

		=20

		5)   In section 2 you make the following statement:

		=20

		2.  GMPLS RSVP-TE Extensions

		=20

		    To simplify the configuration of connectivity monitoring, when an

		   Ethernet LSP is signalled the associated MEPs should be =
automatically

		    established.  Further more, GMPLS signalling should be able to

		  enable/disable connectivity monitoring of a particular Ethernet LSP.

		=20

		=20

		To my point in #1 above, you should use the native CFM functionality =
over the ethernet interface and signal

		those capabilities to the bridges at both ends using the IEEE CFM =
signaling procedures (when and if they

		are created).  If you want to test the underlying GMPLS LSP(s), then =
you should use some

		other mechanism defined for that layer such as the work stated in =
draft-ali-ccamp-gmpls-LSP-ping-traceroute-00.txt

	See the note to your point #1. There is no relation to the =
gmpls-LSP-ping draft.=20

=20

          The point I am making is that perhaps it should.

=20

          --Tom

=20

=20

	=20

	=20

	=20

=20

=20

------_=_NextPart_001_01C8375F.41AC3A97
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">
<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>

<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"PersonName"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Helvetica;
	panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	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.EmailStyle20
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dblue style=3D'word-wrap: =
break-word;-webkit-nbsp-mode: space;
-webkit-line-break: after-white-space'>

<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 =
Thomas,<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'>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0 =A0=A0=A0=A0Please see some more
comment in line.<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'>BR<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'>Diego<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 style=3D'border:none;border-left:solid blue 1.5pt;padding:0cm 0cm =
0cm 4.0pt'>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=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-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'> =
Thomas Nadeau
[mailto:[email-masked]] <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> marted=EC 4 =
dicembre 2007
17.19<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Diego Caviglia<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> <st1:PersonName =
w:st=3D"on">Attila
 Takacs</st1:PersonName>; [email-masked]; =
[email-masked]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> Re:
draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt</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=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>On Dec 4, 2007, at 7:33 PM, Diego Caviglia =
wrote:<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'><br>
<br>
<o:p></o:p></span></font></p>

<span style=3D'orphans: 2;text-align:auto;widows: =
2;-webkit-border-horizontal-spacing: 0px;
-webkit-border-vertical-spacing: 0px;-webkit-text-decorations-in-effect: =
none;
-webkit-text-size-adjust: auto;-webkit-text-stroke-width: =
0;word-spacing:0px'>

<div link=3Dblue vlink=3Dblue style=3D'word-wrap: =
break-word;-webkit-nbsp-mode: space;
-webkit-line-break: after-white-space'>

<div>

<div>

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

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
My understanding of the ID was that RSVP-TE can be used to =
&#8216;piggyback&#8217; CFM
set-up, otherwise the scenario is: usage of RSVP-TE to set-up the LSP =
and NMS
(meaning everything that is not control plane) to enable to CFM for the =
LSP.</span></font><font
color=3Dblack><span style=3D'color:black'><o:p></o:p></span></font></p>

</div>

</div>

</div>

</span>

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

<p class=3DMsoNormal><span class=3Dapple-tab-span><font size=3D3
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt'>=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
</span></font></span>As
I understand it, the IEEE is working on set-up of CFM (and MEPs), as are =
some
vendors I know. *)<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'>This to me seems like the right way to do =
this.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><b><i><font size=3D2 color=3Dnavy =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy;font-weight:bold;
font-style:italic'>[DC] no doubt about this and in fact I don&#8217;t =
think the ID
was about defining the CFM is was just about the usage of GMPLS to =
enable it.</span></font></i></b><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>

</div>

<div>

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

<span style=3D'orphans: 2;text-align:auto;widows: =
2;-webkit-border-horizontal-spacing: 0px;
-webkit-border-vertical-spacing: 0px;-webkit-text-decorations-in-effect: =
none;
-webkit-text-size-adjust: auto;-webkit-text-stroke-width: =
0;word-spacing:0px'><u1:p></u1:p><span
style=3D'-webkit-text-stroke-width: -1'>

<div link=3Dblue vlink=3Dblue style=3D'word-wrap: =
break-word;-webkit-nbsp-mode: space;
-webkit-line-break: after-white-space'>

<div>

<div>

<p class=3DMsoNormal><span class=3Dapple-style-span><font size=3D2 =
color=3D"#144fae"
face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt;color:#144FAE'>From your
comment I see that you&#8217;re not happy with the fact the ID is so =
technology
specific am I right? &nbsp;</span></span></font></span><font =
color=3Dblack><span
style=3D'color:black'><o:p></o:p></span></font></p>

</div>

</div>

</div>

</span>

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

<div>

<p class=3DMsoNormal><span class=3Dapple-tab-span><font size=3D3
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt'>=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
</span></font></span>Precisely;
its gluing CFM to RSVP-TE/GMPLS as a transport.&nbsp;<o:p></o:p></p>

</div>

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

<span style=3D'orphans: 2;text-align:auto;widows: =
2;-webkit-border-horizontal-spacing: 0px;
-webkit-border-vertical-spacing: 0px;-webkit-text-decorations-in-effect: =
none;
-webkit-text-size-adjust: auto;-webkit-text-stroke-width: =
0;word-spacing:0px'><span
style=3D'-webkit-text-stroke-width: -1'>

<div link=3Dblue vlink=3Dblue style=3D'word-wrap: =
break-word;-webkit-nbsp-mode: space;
-webkit-line-break: after-white-space'>

<div>

<div>

<p class=3DMsoNormal><span class=3Dapple-style-span><font size=3D2 =
color=3D"#144fae"
face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt;color:#144FAE'>If yes do
you agree with the fact that could be useful in general to use the same
signaling &#8216;session&#8217; to set-up the LSP and to enable the =
CFM?</span></span></font></span><font
color=3Dblack><span style=3D'color:black'><o:p></o:p></span></font></p>

</div>

</div>

</div>

</span>

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

<p class=3DMsoNormal><span class=3Dapple-tab-span><font size=3D3
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt'>=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
</span></font></span>No,
I do not agree. &nbsp;Again, if CFM is to be set-up e2e, let the IEEE =
define
this. Leave GMPLS to CCAMP.<o:p></o:p></p>

<p class=3DMsoNormal><b><i><font size=3D2 color=3Dnavy =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy;font-weight:bold;
font-style:italic'>[DC] I think that we have a total agreement on this, =
no one
is saying that CCAMP has to define the or re-define the CFM as no one =
redefined
g707 or other SDH ITU-T spec when we developed GMPLS for =
SONET/SDH.</span></font></i></b><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>

</div>

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

<div>

<p class=3DMsoNormal><span class=3Dapple-tab-span><font size=3D3
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt'>=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
</span></font></span>--Tom<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'><o:p>&nbsp;</o:p></span></font></p>

</div>

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

<div>

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

<span style=3D'orphans: 2;text-align:auto;widows: =
2;-webkit-border-horizontal-spacing: 0px;
-webkit-border-vertical-spacing: 0px;-webkit-text-decorations-in-effect: =
none;
-webkit-text-size-adjust: auto;-webkit-text-stroke-width: =
0;word-spacing:0px'><u1:p>

<div link=3Dblue vlink=3Dblue style=3D'word-wrap: =
break-word;-webkit-nbsp-mode: space;
-webkit-line-break: after-white-space'>

<div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;<span =
style=3D'-webkit-text-stroke-width: -1'></span></font><span
class=3Dapple-style-span><font size=3D2 color=3D"#144fae" =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:#144FAE'>Best =
Regards</span></span></font></u1:p></span><font
color=3Dblack><span style=3D'color:black'><o:p></o:p></span></font></p>

</div>

<div>

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

</div>

<div>

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

</div>

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0cm 0cm =
0cm 4.0pt;
border-width:initial;border-color:initial'>

<div>

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

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

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

<div>

<p class=3DMsoNormal><b><font size=3D2 color=3Dblack face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma;color:black;font-weight:bold=
'>From:</span></font></b><span
class=3Dapple-converted-space><font size=3D2 color=3Dblack =
face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma;color:black'>&nbsp;</span></=
font></span><font
size=3D2 color=3Dblack face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma;
color:black'><a =
href=3D"mailto:[email-masked]">[email-masked]</a>
[<a =
href=3D"mailto:[email-masked]">mailto:[email-masked]<=
/a>]<span
class=3Dapple-converted-space>&nbsp;</span><b><span =
style=3D'font-weight:bold'>On
Behalf Of<span =
class=3Dapple-converted-space>&nbsp;</span></span></b>Thomas
Nadeau<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b><span
class=3Dapple-converted-space>&nbsp;</span>marted=EC 4 dicembre 2007 =
11.30<br>
<b><span style=3D'font-weight:bold'>To:</span></b><span
class=3Dapple-converted-space>&nbsp;</span><st1:PersonName =
w:st=3D"on">Attila
 Takacs</st1:PersonName><br>
<b><span style=3D'font-weight:bold'>Cc:</span></b><span
class=3Dapple-converted-space>&nbsp;</span><a =
href=3D"mailto:[email-masked]">[email-masked]</a>;<span
class=3Dapple-converted-space>&nbsp;</span><a
href=3D"mailto:[email-masked]">[email-masked]</a><br>=

<b><span style=3D'font-weight:bold'>Subject:</span></b><span
class=3Dapple-converted-space>&nbsp;</span>Re:
draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt</span></font><font =
color=3Dblack><span
style=3D'color:black'><o:p></o:p></span></font></p>

<u1:p></u1:p></div>

</div>

<div>

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

</div>

<div>

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

</div>

<div>

<div>

<div>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:black'>On Dec 4, 2007, at 1:51 PM, =
<st1:PersonName
w:st=3D"on">Attila Takacs</st1:PersonName> =
wrote:<u1:p></u1:p><o:p></o:p></span></font></p>

</div>

</div>

<div>

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

</div>

<u1:p></u1:p>

<div style=3D'word-wrap: break-word'>

<div>

<div>

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

<u1:p></u1:p></div>

</div>

<div>

<div>

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

</div>

</div>

<div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Thank you&nbsp;for the =
comments!</span></font><font
color=3Dblack><span style=3D'color:black'><o:p></o:p></span></font></p>

<u1:p></u1:p></div>

</div>

<div>

<div>

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

<u1:p></u1:p></div>

</div>

<div>

<div>

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

</div>

</div>

<div>

<div>

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

<u1:p></u1:p></div>

</div>

<blockquote style=3D'border:none;border-left:solid blue =
1.5pt;padding:0cm 0cm 0cm 4.0pt;
margin-left:3.75pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt;=

border-width:initial;border-color:initial'>

<div>

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

</div>

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

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

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

<div>

<p class=3DMsoNormal><b><font size=3D2 color=3Dblack face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma;color:black;font-weight:bold=
'>From:</span></font></b><span
class=3Dapple-converted-space><font size=3D2 color=3Dblack =
face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma;color:black'>&nbsp;</span></=
font></span><font
size=3D2 color=3Dblack face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma;
color:black'>Thomas Nadeau [<a =
href=3D"mailto:[email-masked]">mailto:[email-masked]</a=
>]<span
class=3Dapple-converted-space>&nbsp;</span><br>
<b><span style=3D'font-weight:bold'>Sent:</span></b><span
class=3Dapple-converted-space>&nbsp;</span>Tuesday, December 04, 2007 =
2:58 PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b><span
class=3Dapple-converted-space>&nbsp;</span><a =
href=3D"mailto:[email-masked]">[email-masked]</a><br>
<b><span style=3D'font-weight:bold'>Cc:</span></b><span
class=3Dapple-converted-space>&nbsp;</span><st1:PersonName =
w:st=3D"on">Attila
 Takacs</st1:PersonName>;<span =
class=3Dapple-converted-space>&nbsp;</span><a
href=3D"mailto:[email-masked]">[email-masked]</a><br>=

<b><span style=3D'font-weight:bold'>Subject:</span></b><span
class=3Dapple-converted-space>&nbsp;</span>draft-takacs-ccamp-rsvp-te-eth=
-oam-ext-00.txt</span></font><font
color=3Dblack><span style=3D'color:black'><o:p></o:p></span></font></p>

<u1:p></u1:p></div>

<div>

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

</div>

<div>

<div>

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

</div>

</div>

<div>

<div>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:black'>After reading this draft, I have =
some
questions/comments.<u1:p></u1:p><o:p></o:p></span></font></p>

</div>

</div>

<div>

<div>

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

</div>

</div>

<div>

<div>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:black'>1) Overall,&nbsp;I am concerned =
that the
definition of a new TLV and these procedures =
represent&nbsp;<u1:p></u1:p><o:p></o:p></span></font></p>

</div>

</div>

<div>

<div>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:black'>what amounts to a laying =
violation and ask
that the ADs take a look at =
this<u1:p></u1:p><o:p></o:p></span></font></p>

</div>

</div>

<div>

<div>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:black'>approach closely. This is similar =
to the
now-rejected approach that was =
proposed<u1:p></u1:p><o:p></o:p></span></font></p>

</div>

</div>

<div>

<div>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:black'>in the l2vpn WG about munging CFM =
+ PWs.
&nbsp;To my reading, this is =
essentially<u1:p></u1:p><o:p></o:p></span></font></p>

</div>

</div>

<div>

<div>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:black'>the same thing. If you want to =
run CFM,
run it natively over the ethernet interfaces =
and<u1:p></u1:p><o:p></o:p></span></font></p>

</div>

</div>

<div>

<div>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:black'>have no regard for the underlying =
topology
(GMPLS, PWs, etc...) otherwise =
you&nbsp;<u1:p></u1:p><o:p></o:p></span></font></p>

</div>

</div>

<div>

<div>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:black'>will be creating a mess for
implementations and interoperability.&nbsp;</span></font><font size=3D2
color=3Dblue face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:blue'>&nbsp;</span></font><font color=3Dblack><span =
style=3D'color:black'><o:p></o:p></span></font></p>

<u1:p></u1:p></div>

</div>

</blockquote>

<div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>The application&nbsp;of the draft =
is
exactly for what you are calling out: when CFM is run natively over the
Ethernet interfaces. The document focuses on GELS and Ethernet =
LSPs.&nbsp;That
is,&nbsp;to establish CFM entities for GMPLS controlled Ethernet
LSPs.&nbsp;Hence, I think there is no layer violation =
issue.</span></font><font
color=3Dblack><span style=3D'color:black'><o:p></o:p></span></font></p>

<u1:p></u1:p></div>

</div>

</div>

<div>

<div>

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

</div>

</div>

<div>

<p class=3DMsoNormal><span class=3Dapple-tab-span><font size=3D3 =
color=3Dblack
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt;color:black'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;</span></font></span><span
class=3Dapple-converted-space><font color=3Dblack><span =
style=3D'color:black'>&nbsp;</span></font></span><font
color=3Dblack><span style=3D'color:black'>This solution specifically =
only works for
GMPLS ethernet LSPs, right? &nbsp;<o:p></o:p></span></font></p>

<u1:p></u1:p></div>

</div>

<div>

<div>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:black'>What do I do if I want to set up =
MPLS
ethernet LSPs (i.e.: PWs)&nbsp;and do CFM over those? =
Oh,<u1:p></u1:p><o:p></o:p></span></font></p>

</div>

</div>

<div>

<div>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:black'>that is a different solution, =
right?
&nbsp;Then what do I do if I want to run CFM over some new type =
of<u1:p></u1:p><o:p></o:p></span></font></p>

</div>

</div>

<div>

<div>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:black'>ethernet LSP in the future? More =
protocol
hacks? &nbsp;The point is to use CFM over an ethernet =
interface<u1:p></u1:p><o:p></o:p></span></font></p>

</div>

</div>

<div>

<div>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:black'>without the underlying layers =
knowing.
This is good networking architecture design, that =
simplifies<u1:p></u1:p><o:p></o:p></span></font></p>

</div>

</div>

<div>

<div>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:black'>implementations and makes them =
more
robust, as well as makes using them operationally =
much<u1:p></u1:p><o:p></o:p></span></font></p>

</div>

</div>

<div>

<div>

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

</div>

</div>

<div>

<blockquote style=3D'margin-top:5.0pt;margin-bottom:5.0pt' type=3Dcite>

<div style=3D'word-wrap: break-word'>

<blockquote style=3D'border:none;border-left:solid blue =
1.5pt;padding:0cm 0cm 0cm 4.0pt;
margin-left:3.75pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt'=

<div>

<div>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:black'>2)&nbsp;The introductory sections =
in this
draft give a lot of discussion about fast fault detection. =
I<u1:p></u1:p><o:p></o:p></span></font></p>

</div>

</div>

<div>

<div>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:black'>am puzzled by this given that =
GMPLS
networks tend to run over quickly =
self-healing<u1:p></u1:p><o:p></o:p></span></font></p>

</div>

</div>

<div>

<div>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:black'>optical infrastructures. Is it
therefore&nbsp;truly&nbsp;necessary to motivate this work =
by<u1:p></u1:p><o:p></o:p></span></font></p>

</div>

</div>

<div>

<div>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:black'>requiring fast =
CFMs?<u1:p></u1:p><o:p></o:p></span></font></p>

</div>

</div>

</blockquote>

<div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>It is right that frequent CCMs are =
not
required if the layers below Ethernet handle protection. However, the ID
focuses on Ethernet LSPs where Ethernet is&nbsp;not just a single
hop&nbsp;above a transport LSP.&nbsp;In this case&nbsp;Ethernet layer =
(for
clarity GELS) may provide protection for Ethernet LSPs.&nbsp;In any =
case,&nbsp;
the whole point of the ID is to allow for the appropriate configuration =
of CFM
for Ethernet LSPs with GMPLS.</span></font><font color=3Dblack><span
style=3D'color:black'><o:p></o:p></span></font></p>

<u1:p></u1:p></div>

</div>

<div>

<div>

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

</div>

</div>

<blockquote style=3D'border:none;border-left:solid blue =
1.5pt;padding:0cm 0cm 0cm 4.0pt;
margin-left:3.75pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt;=

border-width:initial;border-color:initial'>

<div>

<div>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:black'>3) This document does not cover =
E-LMI. Why
not?<u1:p></u1:p><o:p></o:p></span></font></p>

</div>

</div>

</blockquote>

<div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>E-LMI is run over the MEF UNI. =
The&nbsp;ID
focuses on Ethernet LSPs within a network.</span></font><font =
color=3Dblack><span
style=3D'color:black'><o:p></o:p></span></font></p>

<u1:p></u1:p></div>

</div>

<div>

<div>

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

</div>

</div>

<div>

<div>

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

</div>

</div>

<blockquote style=3D'border:none;border-left:solid blue =
1.5pt;padding:0cm 0cm 0cm 4.0pt;
margin-left:3.75pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt;=

border-width:initial;border-color:initial'>

<div>

<div>

<p class=3DMsoNormal><span class=3Dapple-style-span><font size=3D1 =
color=3Dblack
face=3D"Times New Roman"><span style=3D'font-size:9.0pt;color:black'>For =
the
purposes of this document, we only discuss Ethernet =
OAM</span></font></span><font
color=3Dblack><span style=3D'color:black'><o:p></o:p></span></font></p>

<u1:p></u1:p></div>

</div>

<div>

<div>

<p class=3DMsoNormal><font size=3D1 color=3Dblack face=3DHelvetica><span
style=3D'font-size:9.0pt;font-family:Helvetica;color:black'>&nbsp;&nbsp; =
[IEEE-CFM]
aspects that are relevant for the connectivity =
monitoring<u1:p></u1:p></span></font><font
color=3Dblack><span style=3D'color:black'><o:p></o:p></span></font></p>

</div>

</div>

<div>

<div>

<p class=3DMsoNormal><font size=3D1 color=3Dblack face=3DHelvetica><span
style=3D'font-size:9.0pt;font-family:Helvetica;color:black'>&nbsp;&nbsp; =
of
bidirectional point-to-point PBB-TE connections. =
&nbsp;<u1:p></u1:p></span></font><font
color=3Dblack><span style=3D'color:black'><o:p></o:p></span></font></p>

</div>

</div>

<div>

<div>

<p class=3DMsoNormal><font size=3D1 color=3Dblack face=3DHelvetica><span
style=3D'font-size:9.0pt;font-family:Helvetica;color:black'><u1:p>&nbsp;<=
/u1:p></span></font><font
color=3Dblack><span style=3D'color:black'><o:p></o:p></span></font></p>

</div>

</div>

<div>

<div>

<p class=3DMsoNormal><font size=3D1 color=3Dblack face=3DHelvetica><span
style=3D'font-size:9.0pt;font-family:Helvetica;color:black'>4) Is this =
the right
place to define this document or should this be done in =
GELS?<u1:p></u1:p></span></font><font
color=3Dblack><span style=3D'color:black'><o:p></o:p></span></font></p>

</div>

</div>

</blockquote>

<div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Well, GELS is done in CCAMP...this =
seems
to be the right place.</span></font><font color=3Dblack><span =
style=3D'color:black'><o:p></o:p></span></font></p>

<u1:p></u1:p></div>

</div>

<blockquote style=3D'border:none;border-left:solid blue =
1.5pt;padding:0cm 0cm 0cm 4.0pt;
margin-left:3.75pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt;=

border-width:initial;border-color:initial'>

<div>

<div>

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

</div>

</div>

<div>

<div>

<p class=3DMsoNormal><font size=3D1 color=3Dblack face=3DHelvetica><span
style=3D'font-size:9.0pt;font-family:Helvetica;color:black'><u1:p>&nbsp;<=
/u1:p></span></font><font
color=3Dblack><span style=3D'color:black'><o:p></o:p></span></font></p>

</div>

</div>

<div>

<div>

<p class=3DMsoNormal><font size=3D1 color=3Dblack face=3DHelvetica><span
style=3D'font-size:9.0pt;font-family:Helvetica;color:black'>5) &nbsp; In =
section
2 you make the following statement:<u1:p></u1:p></span></font><font
color=3Dblack><span style=3D'color:black'><o:p></o:p></span></font></p>

</div>

</div>

<div>

<div>

<p class=3DMsoNormal><font size=3D1 color=3Dblack face=3DHelvetica><span
style=3D'font-size:9.0pt;font-family:Helvetica;color:black'><u1:p>&nbsp;<=
/u1:p></span></font><font
color=3Dblack><span style=3D'color:black'><o:p></o:p></span></font></p>

</div>

</div>

<div>

<div>

<p class=3DMsoNormal><font size=3D1 color=3Dblack face=3DHelvetica><span
style=3D'font-size:9.0pt;font-family:Helvetica;color:black'>2.&nbsp; =
GMPLS
RSVP-TE Extensions<u1:p></u1:p></span></font><font color=3Dblack><span
style=3D'color:black'><o:p></o:p></span></font></p>

</div>

</div>

<u1:p>

<div style=3D'min-height: 14px'>

<div>

<p class=3DMsoNormal><font size=3D1 color=3Dblack face=3DHelvetica><span
style=3D'font-size:9.0pt;font-family:Helvetica;color:black'>&nbsp;</u1:p>=
</span></font><font
color=3Dblack><span style=3D'color:black'><o:p></o:p></span></font></p>

</div>

</div>

<div>

<div>

<p class=3DMsoNormal><font size=3D1 color=3Dblack face=3DHelvetica><span
style=3D'font-size:9.0pt;font-family:Helvetica;color:black'>&nbsp;<span
class=3Dapple-converted-space>&nbsp;</span>&nbsp; To simplify the =
configuration
of connectivity monitoring, when an<u1:p></u1:p></span></font><font
color=3Dblack><span style=3D'color:black'><o:p></o:p></span></font></p>

</div>

</div>

<div>

<div>

<p class=3DMsoNormal><font size=3D1 color=3Dblack face=3DHelvetica><span
style=3D'font-size:9.0pt;font-family:Helvetica;color:black'>&nbsp;&nbsp; =
Ethernet
LSP is signalled the associated MEPs should be =
automatically<u1:p></u1:p></span></font><font
color=3Dblack><span style=3D'color:black'><o:p></o:p></span></font></p>

</div>

</div>

<div>

<div>

<p class=3DMsoNormal><font size=3D1 color=3Dblack face=3DHelvetica><span
style=3D'font-size:9.0pt;font-family:Helvetica;color:black'>&nbsp;<span
class=3Dapple-converted-space>&nbsp;</span>&nbsp; established.&nbsp; =
Further
more, GMPLS signalling should be able to<u1:p></u1:p></span></font><font
color=3Dblack><span style=3D'color:black'><o:p></o:p></span></font></p>

</div>

</div>

<div>

<div>

<p class=3DMsoNormal><font size=3D1 color=3Dblack face=3DHelvetica><span
style=3D'font-size:9.0pt;font-family:Helvetica;color:black'>&nbsp;&nbsp;e=
nable/disable
connectivity monitoring of a particular Ethernet =
LSP.<u1:p></u1:p></span></font><font
color=3Dblack><span style=3D'color:black'><o:p></o:p></span></font></p>

</div>

</div>

<div>

<div>

<p class=3DMsoNormal><font size=3D1 color=3Dblack face=3DHelvetica><span
style=3D'font-size:9.0pt;font-family:Helvetica;color:black'><u1:p>&nbsp;<=
/u1:p></span></font><font
color=3Dblack><span style=3D'color:black'><o:p></o:p></span></font></p>

</div>

</div>

<div>

<div>

<p class=3DMsoNormal><font size=3D1 color=3Dblack face=3DHelvetica><span
style=3D'font-size:9.0pt;font-family:Helvetica;color:black'><u1:p>&nbsp;<=
/u1:p></span></font><font
color=3Dblack><span style=3D'color:black'><o:p></o:p></span></font></p>

</div>

</div>

<div>

<div>

<p class=3DMsoNormal><font size=3D1 color=3Dblack face=3DHelvetica><span
style=3D'font-size:9.0pt;font-family:Helvetica;color:black'>To my point =
in #1
above, you should use the native CFM functionality over the ethernet =
interface
and signal<u1:p></u1:p></span></font><font color=3Dblack><span =
style=3D'color:black'><o:p></o:p></span></font></p>

</div>

</div>

<div>

<div>

<p class=3DMsoNormal><font size=3D1 color=3Dblack face=3DHelvetica><span
style=3D'font-size:9.0pt;font-family:Helvetica;color:black'>those =
capabilities to
the bridges at both ends using the IEEE CFM signaling procedures (when =
and if
they<u1:p></u1:p></span></font><font color=3Dblack><span =
style=3D'color:black'><o:p></o:p></span></font></p>

</div>

</div>

<div>

<div>

<p class=3DMsoNormal><font size=3D1 color=3Dblack face=3DHelvetica><span
style=3D'font-size:9.0pt;font-family:Helvetica;color:black'>are =
created).
&nbsp;If you want to test the underlying GMPLS LSP(s), then you should =
use some<u1:p></u1:p></span></font><font
color=3Dblack><span style=3D'color:black'><o:p></o:p></span></font></p>

</div>

</div>

<div>

<div>

<p class=3DMsoNormal><font size=3D1 color=3Dblack face=3DHelvetica><span
style=3D'font-size:9.0pt;font-family:Helvetica;color:black'>other =
mechanism
defined for that layer such as the work stated =
in&nbsp;</span></font><span
class=3Dapple-style-span><b><font size=3D2 color=3Dblack =
face=3DHelvetica><span
style=3D'font-size:10.0pt;font-family:Helvetica;color:black;font-weight:b=
old'>draft-ali-ccamp-gmpls-LSP-ping-traceroute-00.txt</span></font></b></=
span><font
color=3Dblack><span =
style=3D'color:black'><u1:p></u1:p><o:p></o:p></span></font></p>

</div>

</div>

</blockquote>

<div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>See the note&nbsp;to your point #1. =
There
is no relation&nbsp;to the gmpls-LSP-ping =
draft.&nbsp;</span></font><font
color=3Dblack><span =
style=3D'color:black'><u1:p></u1:p><o:p></o:p></span></font></p>

</div>

</div>

</div>

</blockquote>

<div>

<div>

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

</div>

</div>

<div>

<p class=3DMsoNormal><span class=3Dapple-tab-span><font size=3D3 =
color=3Dblack
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt;color:black'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;</span></font></span><span
class=3Dapple-converted-space><font color=3Dblack><span =
style=3D'color:black'>&nbsp;</span></font></span><font
color=3Dblack><span style=3D'color:black'>The point I am making is that =
perhaps it
should.<o:p></o:p></span></font></p>

<u1:p></u1:p></div>

</div>

<div>

<div>

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

</div>

</div>

<div>

<div>

<p class=3DMsoNormal><span class=3Dapple-tab-span><font size=3D3 =
color=3Dblack
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt;color:black'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;</span></font></span><span
class=3Dapple-converted-space><font color=3Dblack><span =
style=3D'color:black'>&nbsp;</span></font></span><font
color=3Dblack><span =
style=3D'color:black'>--Tom<o:p></o:p></span></font></p>

<u1:p></u1:p></div>

</div>

<div>

<div>

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

</div>

</div>

<div>

<div>

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

</div>

</div>

<div>

<blockquote style=3D'margin-top:5.0pt;margin-bottom:5.0pt' =
type=3Dcite><u1:p>

<div style=3D'word-wrap: break-word'>

<div>

<div>

<p class=3DMsoNormal><font size=3D1 color=3Dblack face=3DHelvetica><span
style=3D'font-size:9.0pt;font-family:Helvetica;color:black'>&nbsp;</u1:p>=
</span></font><font
color=3Dblack><span style=3D'color:black'><o:p></o:p></span></font></p>

</div>

</div>

<div>

<div>

<p class=3DMsoNormal><font size=3D1 color=3Dblack face=3DHelvetica><span
style=3D'font-size:9.0pt;font-family:Helvetica;color:black'>&nbsp;<u1:p><=
/u1:p></span></font><font
color=3Dblack><span style=3D'color:black'><o:p></o:p></span></font></p>

</div>

</div>

<div>

<div>

<p class=3DMsoNormal><font size=3D1 color=3Dblack face=3DHelvetica><span
style=3D'font-size:9.0pt;font-family:Helvetica;color:black'>&nbsp;<u1:p><=
/u1:p></span></font><font
color=3Dblack><span style=3D'color:black'><o:p></o:p></span></font></p>

</div>

</div>

</div>

</blockquote>

</div>

<div>

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

</div>

</div>

</div>

</div>

</div>

</span>

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

</div>

</body>

</html>

------_=_NextPart_001_01C8375F.41AC3A97--

Delivery-date: Wed, 05 Dec 2007 16:30:23 +0000
Content-class: urn:content-classes:message
Subject: RE: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt
Date: Wed, 5 Dec 2007 17:27:44 +0100
From: "Diego Caviglia" <[email-masked]>
To: <[email-masked]>, "Attila Takacs" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C8375B.C5166677
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Neil,

           Yes I totally agree with your analysis.

=20

The is not going to redefine or reinvent the OAM that, as Thomas as =
pointed out, is done by IEEE, the ID just specify how to use a control =
plane mechanism (GMPLS) set-up at the same time data plane circuit and =
the related OAM.

=20

Frankly specking I don't see any layer violation here.

=20

BR

=20

Diego

=20

________________________________

From: [email-masked] [mailto:[email-masked]]=20
Sent: marted=EC 4 dicembre 2007 22.55
To: Attila Takacs; [email-masked]; Diego Caviglia
Cc: [email-masked]
Subject: RE: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt

=20

I'm puzzled.  I read the draft and thought it was excellent.  It is =
addressing an important operational issue, ie a critical operational OAM =
requirement is to ensure that whatever mechanism (MP or CP) is used to =
set-up/tear-down a connection (so this only applies to co-cs or co-ps =
modes....the cl-ps mode does not have connections of course) is =
harmonised to the activation/deactivation of the OAM.....specifically a =
CV/CC flow.   If we don't ensure this then there will be obvious =
operational problems.  This is essentially what the draft is about.

=20

Further, GMPLS is a generic OOB CP technique.....it is not a specific =
layer network technology per se (but it is specific in it's choice of =
signalling and routing components).  So one can apply a largely similar =
(GMPLS) CP technique to all co-cs mode technologies (whether they are =
partitioning a space, freq or time resource - see Note) and co-ps mode =
technologies (which only applies to partitioning a time resource - see =
Note) on the assumption that the technology is correctly architected in =
the DP for the mode considered.  It's pretty hard not to correctly =
architect the co-cs mode, but it's quite easy to incorrectly architect =
the co-ps mode, eg one can't violate the rules of a connection in the =
co-cs mode but one can in the co-ps mode.

=20

Note - When we partition a time resource in regular time-slices we =
create a co-cs mode layer network.  When we partition a time resource in =
irregular time-slices we create a co-ps mode layer network.  More =
information on labelling and resource partitioning can be found in the =
work on unified modelling (of networks) in G.800.

=20

regards, Neil

	-----Original Message-----
	From: [email-masked] [mailto:[email-masked]] On =
Behalf Of Attila Takacs
	Sent: 05 December 2007 02:03
	To: Thomas Nadeau; Diego Caviglia
	Cc: [email-masked]
	Subject: RE: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt

	Hi Tom,

	please see inline.

	Best regards,

	Attila

		=20

	=09
________________________________

		From: Thomas Nadeau [mailto:[email-masked]]=20
		Sent: Wednesday, December 05, 2007 2:19 AM
		To: Diego Caviglia
		Cc: Attila Takacs; [email-masked]; [email-masked]
		Subject: Re: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt

		=20

		On Dec 4, 2007, at 7:33 PM, Diego Caviglia wrote:

	=09
	=09
	=09

	=09

		Hi Thomas,

		                 My understanding of the ID was that RSVP-TE can be =
used to 'piggyback' CFM set-up, otherwise the scenario is: usage of =
RSVP-TE to set-up the LSP and NMS (meaning everything that is not =
control plane) to enable to CFM for the LSP.

		=20

		As I understand it, the IEEE is working on set-up of CFM (and MEPs), =
as are some vendors I know. *)

		This to me seems like the right way to do this.

		=20

	IEEE specified CFM and MIBs to setup CFM.=20

	Diego's summary is correct: one can use an NMS or a control plane to =
setup the data plane. In this case we propose to use GMPLS to setup the =
data plane: both forwarding + OAM.

	=09

		=09

			From your comment I see that you're not happy with the fact the ID is =
so technology specific am I right? =20

		=20

		Precisely; its gluing CFM to RSVP-TE/GMPLS as a transport.=20

	I do not see your point with gluing. What do you mean by "as =
transport"? GMPLS is just controlling OAM, CFM is run solely in the data =
plane.

	=20

	=20

	=09

		=09

			If yes do you agree with the fact that could be useful in general to =
use the same signaling 'session' to set-up the LSP and to enable the =
CFM?

		=20

		No, I do not agree.  Again, if CFM is to be set-up e2e, let the IEEE =
define this. Leave GMPLS to CCAMP.

	=20

	=20

	Sorry, I cannot follow.

	=20

	=20

		=20

		=20

		=20

		--Tom

		=20

		=20

	=09
	=09
	=09

	=09

		 Best Regards

	=09
		Diego

	=09
	=09
________________________________

		From: [email-masked] [mailto:[email-masked]] On =
Behalf Of Thomas Nadeau
		Sent: marted=EC 4 dicembre 2007 11.30
		To: Attila Takacs
		Cc: [email-masked]; [email-masked]
		Subject: Re: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt

		On Dec 4, 2007, at 1:51 PM, Attila Takacs wrote:

	=09
	=09
	=09
	=09

		Hi Thomas,

		Thank you for the comments!

		Please see answers inline.

		Best regards,
		Attila

	=09

		=09
________________________________

			From: Thomas Nadeau [mailto:[email-masked]]=20
			Sent: Tuesday, December 04, 2007 2:58 PM
			To: [email-masked]
			Cc: Attila Takacs; [email-masked]
			Subject: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt

			After reading this draft, I have some questions/comments.

			1) Overall, I am concerned that the definition of a new TLV and these =
procedures represent=20

			what amounts to a laying violation and ask that the ADs take a look =
at this

			approach closely. This is similar to the now-rejected approach that =
was proposed

			in the l2vpn WG about munging CFM + PWs.  To my reading, this is =
essentially

			the same thing. If you want to run CFM, run it natively over the =
ethernet interfaces and

			have no regard for the underlying topology (GMPLS, PWs, etc...) =
otherwise you=20

			will be creating a mess for implementations and interoperability. =20

		The application of the draft is exactly for what you are calling out: =
when CFM is run natively over the Ethernet interfaces. The document =
focuses on GELS and Ethernet LSPs. That is, to establish CFM entities =
for GMPLS controlled Ethernet LSPs. Hence, I think there is no layer =
violation issue.

		          This solution specifically only works for GMPLS ethernet =
LSPs, right? =20

		What do I do if I want to set up MPLS ethernet LSPs (i.e.: PWs) and do =
CFM over those? Oh,

		that is a different solution, right?  Then what do I do if I want to =
run CFM over some new type of

		ethernet LSP in the future? More protocol hacks?  The point is to use =
CFM over an ethernet interface

		without the underlying layers knowing. This is good networking =
architecture design, that simplifies

		implementations and makes them more robust, as well as makes using =
them operationally much

		easier.=20

				2) The introductory sections in this draft give a lot of discussion =
about fast fault detection. I

				am puzzled by this given that GMPLS networks tend to run over =
quickly self-healing

				optical infrastructures. Is it therefore truly necessary to motivate =
this work by

				requiring fast CFMs?

			It is right that frequent CCMs are not required if the layers below =
Ethernet handle protection. However, the ID focuses on Ethernet LSPs =
where Ethernet is not just a single hop above a transport LSP. In this =
case Ethernet layer (for clarity GELS) may provide protection for =
Ethernet LSPs. In any case,  the whole point of the ID is to allow for =
the appropriate configuration of CFM for Ethernet LSPs with GMPLS.

				3) This document does not cover E-LMI. Why not?

			E-LMI is run over the MEF UNI. The ID focuses on Ethernet LSPs within =
a network.

				For the purposes of this document, we only discuss Ethernet OAM

				   [IEEE-CFM] aspects that are relevant for the connectivity =
monitoring

				   of bidirectional point-to-point PBB-TE connections. =20

				4) Is this the right place to define this document or should this be =
done in GELS?

			Well, GELS is done in CCAMP...this seems to be the right place.

				5)   In section 2 you make the following statement:

				2.  GMPLS RSVP-TE Extensions

				    To simplify the configuration of connectivity monitoring, when =
an

				   Ethernet LSP is signalled the associated MEPs should be =
automatically

				    established.  Further more, GMPLS signalling should be able to

				  enable/disable connectivity monitoring of a particular Ethernet =
LSP.

				To my point in #1 above, you should use the native CFM functionality =
over the ethernet interface and signal

				those capabilities to the bridges at both ends using the IEEE CFM =
signaling procedures (when and if they

				are created).  If you want to test the underlying GMPLS LSP(s), then =
you should use some

				other mechanism defined for that layer such as the work stated in =
draft-ali-ccamp-gmpls-LSP-ping-traceroute-00.txt

			See the note to your point #1. There is no relation to the =
gmpls-LSP-ping draft.=20

		          The point I am making is that perhaps it should.

		          --Tom

		=20

------_=_NextPart_001_01C8375B.C5166677
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

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

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<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]-->
<title>Message</title>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"PersonName"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Helvetica;
	panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:"Comic Sans MS";
	panose-1:3 15 7 2 3 3 2 2 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	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.EmailStyle20
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dblue style=3D'WORD-WRAP: =
break-word;webkit-nbsp-mode: space;
webkit-line-break: after-white-space'>

<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 =
Neil,<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'>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Yes =
I totally agree with your analysis.<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'>The is not going to redefine or =
reinvent
the OAM that, as Thomas as pointed out, is done by IEEE, the ID just =
specify how
to use a control plane mechanism (GMPLS) set-up at the same time data =
plane
circuit and the related OAM.<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'>Frankly specking I don&#8217;t see =
any
layer violation here.<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'>BR<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'>Diego<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 style=3D'border:none;border-left:solid blue 1.5pt;padding:0cm 0cm =
0cm 4.0pt'>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=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-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]] <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> marted=EC 4 =
dicembre 2007
22.55<br>
<b><span style=3D'font-weight:bold'>To:</span></b> <st1:PersonName =
w:st=3D"on">Attila
 Takacs</st1:PersonName>; [email-masked]; Diego Caviglia<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> =
[email-masked]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE:
draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt</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>

<p class=3DMsoNormal><font size=3D2 color=3Dmaroon face=3D"Comic Sans =
MS"><span
style=3D'font-size:10.0pt;font-family:"Comic Sans MS";color:maroon'>I'm
puzzled.&nbsp; I read the draft and thought it was excellent.&nbsp; It =
is
addressing an important operational issue, ie a critical operational OAM
requirement is to ensure that whatever mechanism (MP or CP) is used to
set-up/tear-down a connection (so this only applies to co-cs or co-ps
modes....the cl-ps mode does not have connections of course) is =
harmonised to
the activation/deactivation of the OAM.....specifically a CV/CC
flow.&nbsp;&nbsp; If we don't ensure this then there will be obvious
operational problems.&nbsp; This is essentially what the draft is =
about.</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=3Dmaroon face=3D"Comic Sans =
MS"><span
style=3D'font-size:10.0pt;font-family:"Comic Sans =
MS";color:maroon'>Further,
GMPLS is a generic&nbsp;OOB&nbsp;CP technique.....it is not a specific =
layer
network technology per se (but it is specific in it's choice of =
signalling and
routing components).&nbsp; So one can apply a largely similar (GMPLS) CP
technique to all co-cs mode technologies (whether they are partitioning =
a
space, freq or&nbsp;time resource - see Note) and co-ps mode =
technologies
(which only applies to partitioning a time resource - see Note) on the
assumption that the technology is correctly architected in the DP for =
the mode
considered.&nbsp;&nbsp;It's pretty hard not to correctly architect the =
co-cs
mode, but it's quite easy to incorrectly architect the co-ps mode, eg =
one can't
violate the rules of a connection in the co-cs mode but one can in the =
co-ps
mode.</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=3Dmaroon face=3D"Comic Sans =
MS"><span
style=3D'font-size:10.0pt;font-family:"Comic Sans MS";color:maroon'>Note =
- When
we partition a time resource in regular time-slices we create a co-cs =
mode
layer network.&nbsp; When we partition a time resource in irregular =
time-slices
we create a co-ps mode layer network.&nbsp; More information on =
labelling and
resource partitioning can be found in the work on unified modelling (of
networks) in G.800.</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=3Dmaroon face=3D"Comic Sans =
MS"><span
style=3D'font-size:10.0pt;font-family:"Comic Sans =
MS";color:maroon'>regards, Neil</span></font><o:p></o:p></p>

</div>

<blockquote style=3D'border:none;border-left:solid maroon =
1.5pt;padding:0cm 0cm 0cm 4.0pt;
margin-left:3.75pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt'=

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><font size=3D2 =
face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma'>-----Original =
Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> =
[email-masked]
[mailto:[email-masked]] <b><span style=3D'font-weight:bold'>On =
Behalf
Of </span></b><st1:PersonName w:st=3D"on">Attila =
Takacs</st1:PersonName><br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> 05 December 2007 =
02:03<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Thomas Nadeau; Diego =
Caviglia<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> =
[email-masked]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE:
draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt</span></font><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'>Hi =
Tom,</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'>please see =
inline.</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'>Best =
regards,</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'>Attila</span></font><o:p></o:p></p>

</div>

<blockquote style=3D'border:none;border-left:solid blue =
1.5pt;padding:0cm 0cm 0cm 4.0pt;
margin-left:3.75pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt'=

<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 =
size=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:</spa=
n></font></b><font
size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma'> Thomas
Nadeau [mailto:[email-masked]] <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Wednesday, December =
05, 2007
2:19 AM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Diego Caviglia<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> <st1:PersonName =
w:st=3D"on">Attila
 Takacs</st1:PersonName>; [email-masked]; =
[email-masked]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> Re:
draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt</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>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>On Dec 4, 2007, at 7:33 PM, Diego Caviglia =
wrote:<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'><br>
<br>
<o:p></o:p></span></font></p>

<span style=3D'orphans: 2;widows: 2;webkit-border-horizontal-spacing: =
0px;
webkit-border-vertical-spacing: 0px;webkit-text-decorations-in-effect: =
none;
webkit-text-size-adjust: auto;webkit-text-stroke-width: =
0;word-spacing:0px'>

<div style=3D'WORD-WRAP: break-word;webkit-nbsp-mode: =
space;webkit-line-break: after-white-space'
link=3Dblue vlink=3Dblue>

<div>

<div>

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

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
My understanding of the ID was that RSVP-TE can be used to =
&#8216;piggyback&#8217;
CFM set-up, otherwise the scenario is: usage of RSVP-TE to set-up the =
LSP and
NMS (meaning everything that is not control plane) to enable to CFM for =
the
LSP.</span></font><font color=3Dblack><span =
style=3D'color:black'><o:p></o:p></span></font></p>

</div>

</div>

</div>

</span>

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

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>As I understand it, the IEEE is working on set-up of CFM (and =
MEPs), as
are some vendors I know. *)<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>This to me seems like the right way to do =
this.<o:p></o:p></span></font></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>

</blockquote>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>IEEE specified CFM and MIBs to =
setup
CFM.&nbsp;</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'>Diego's summary is correct: one can =
use an
NMS or&nbsp;a control plane to setup the data plane. In this case we =
propose to
use&nbsp;GMPLS to setup the data plane: both forwarding + =
OAM.</span></font><o:p></o:p></p>

</div>

<blockquote style=3D'border:none;border-left:solid blue =
1.5pt;padding:0cm 0cm 0cm 4.0pt;
margin-left:3.75pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt'=

type=3Dcite><span style=3D'orphans: 2;widows: =
2;webkit-border-horizontal-spacing: 0px;
webkit-border-vertical-spacing: 0px;webkit-text-decorations-in-effect: =
none;
webkit-text-size-adjust: auto;webkit-text-stroke-width: =
0;word-spacing:0px'><O:P></O:P>

<blockquote style=3D'margin-top:5.0pt;margin-bottom:5.0pt'><span
style=3D'webkit-text-stroke-width: -1'>

<div style=3D'WORD-WRAP: break-word;webkit-nbsp-mode: =
space;webkit-line-break: after-white-space'
link=3Dblue vlink=3Dblue>

<div>

<p class=3DMsoNormal><span class=3Dapple-style-span><font size=3D2 =
color=3D"#144fae"
face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt;color:#144FAE'>From your
comment I see that you&#8217;re not happy with the fact the ID is so =
technology
specific am I right? &nbsp;</span></span></font></span><font =
color=3Dblack><span
style=3D'color:black'><o:p></o:p></span></font></p>

</div>

</div>

</blockquote>

</span>

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

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>Precisely; its gluing CFM to RSVP-TE/GMPLS as a =
transport.&nbsp;<o:p></o:p></span></font></p>

</div>

</blockquote>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>I do not see your point with =
gluing. What
do you mean by &quot;as transport&quot;? GMPLS is just controlling OAM, =
CFM is
run solely in the data plane.</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=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

</div>

<blockquote style=3D'border:none;border-left:solid blue =
1.5pt;padding:0cm 0cm 0cm 4.0pt;
margin-left:3.75pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt'=

type=3Dcite><span style=3D'orphans: 2;widows: =
2;webkit-border-horizontal-spacing: 0px;
webkit-border-vertical-spacing: 0px;webkit-text-decorations-in-effect: =
none;
webkit-text-size-adjust: auto;webkit-text-stroke-width: =
0;word-spacing:0px'>

<blockquote style=3D'margin-top:5.0pt;margin-bottom:5.0pt'><span
style=3D'webkit-text-stroke-width: -1'>

<div style=3D'WORD-WRAP: break-word;webkit-nbsp-mode: =
space;webkit-line-break: after-white-space'
link=3Dblue vlink=3Dblue>

<div>

<p class=3DMsoNormal><span class=3Dapple-style-span><font size=3D2 =
color=3D"#144fae"
face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt;color:#144FAE'>If yes do
you agree with the fact that could be useful in general to use the same
signaling &#8216;session&#8217; to set-up the LSP and to enable the =
CFM?</span></span></font></span><font
color=3Dblack><span style=3D'color:black'><o:p></o:p></span></font></p>

</div>

</div>

</blockquote>

</span>

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

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>No, I do not agree. &nbsp;Again, if CFM is to be set-up e2e, let =
the
IEEE define this. Leave GMPLS to CCAMP.<o:p></o:p></span></font></p>

</div>

</blockquote>

<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=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'>Sorry, I cannot =
follow.</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=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<blockquote style=3D'border:none;border-left:solid blue =
1.5pt;padding:0cm 0cm 0cm 4.0pt;
margin-left:3.75pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt'=

<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=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=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

</div>

<div>

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

</div>

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

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

<div>

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

<span style=3D'orphans: 2;widows: 2;webkit-border-horizontal-spacing: =
0px;
webkit-border-vertical-spacing: 0px;webkit-text-decorations-in-effect: =
none;
webkit-text-size-adjust: auto;webkit-text-stroke-width: =
0;word-spacing:0px'><O:P>

<div style=3D'WORD-WRAP: break-word;webkit-nbsp-mode: =
space;webkit-line-break: after-white-space'
link=3Dblue vlink=3Dblue>

<div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;<span =
style=3D'webkit-text-stroke-width: -1'></span></font><span
class=3Dapple-style-span><font size=3D2 color=3D"#144fae" =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:#144FAE'>Best =
Regards</span></span></font></O:P></span><font
color=3Dblack><span style=3D'color:black'><o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><br>
Diego<O:P></O:P></span></font><font color=3Dblack><span =
style=3D'color:black'><o:p></o:p></span></font></p>

</div>

<font size=3D3 color=3Dblack face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt;
font-family:"Times New Roman";color:black'><O:P></O:P></span></font>

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0cm 0cm =
0cm 4.0pt'>

<div>

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

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

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

<div>

<p class=3DMsoNormal><b><font size=3D2 color=3Dblack face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma;color:black;font-weight:bold=
'>From:</span></font></b><span
class=3Dapple-converted-space><font size=3D2 color=3Dblack =
face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma;color:black'>&nbsp;</span></=
font></span><font
size=3D2 color=3Dblack face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma;
color:black'><a =
href=3D"mailto:[email-masked]">[email-masked]</a>
[<a =
href=3D"mailto:[email-masked]">mailto:[email-masked]<=
/a>]<span
class=3Dapple-converted-space>&nbsp;</span><b><span =
style=3D'font-weight:bold'>On
Behalf Of<span =
class=3Dapple-converted-space>&nbsp;</span></span></b>Thomas
Nadeau<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b><span
class=3Dapple-converted-space>&nbsp;</span>marted=EC 4 dicembre 2007 =
11.30<br>
<b><span style=3D'font-weight:bold'>To:</span></b><span
class=3Dapple-converted-space>&nbsp;</span><st1:PersonName =
w:st=3D"on">Attila
 Takacs</st1:PersonName><br>
<b><span style=3D'font-weight:bold'>Cc:</span></b><span
class=3Dapple-converted-space>&nbsp;</span><a =
href=3D"mailto:[email-masked]">[email-masked]</a>;<span
class=3Dapple-converted-space>&nbsp;</span><a
href=3D"mailto:[email-masked]">[email-masked]</a><br>=

<b><span style=3D'font-weight:bold'>Subject:</span></b><span
class=3Dapple-converted-space>&nbsp;</span>Re:
draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt</span></font><font =
color=3Dblack><span
style=3D'color:black'><o:p></o:p></span></font></p>

<O:P></O:P></div>

</div>

<div>

<div>

<div>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:black'><O:P></O:P><O:P></O:P>On Dec 4, =
2007, at
1:51 PM, <st1:PersonName w:st=3D"on">Attila Takacs</st1:PersonName> =
wrote:<O:P></O:P><o:p></o:p></span></font></p>

</div>

</div>

<div>

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

</div>

<O:P></O:P>

<div style=3D'WORD-WRAP: break-word'>

<div>

<div>

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

<O:P></O:P></div>

</div>

<div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'><O:P></O:P>Thank you&nbsp;for the =
comments!</span></font><font
color=3Dblack><span style=3D'color:black'><o:p></o:p></span></font></p>

<O:P></O:P></div>

</div>

<div>

<div>

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

<O:P></O:P></div>

</div>

<div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'><O:P></O:P>Best regards,<br>
Attila</span></font><font color=3Dblack><span =
style=3D'color:black'><o:p></o:p></span></font></p>

<O:P></O:P></div>

</div>

<font size=3D3 color=3Dblack face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt;
font-family:"Times New Roman";color:black'><O:P></O:P></span></font>

<blockquote style=3D'border:none;border-left:solid blue =
1.5pt;padding:0cm 0cm 0cm 4.0pt;
margin-left:3.75pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt'=

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

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

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

<div>

<p class=3DMsoNormal><b><font size=3D2 color=3Dblack face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma;color:black;font-weight:bold=
'>From:</span></font></b><span
class=3Dapple-converted-space><font size=3D2 color=3Dblack =
face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma;color:black'>&nbsp;</span></=
font></span><font
size=3D2 color=3Dblack face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma;
color:black'>Thomas Nadeau [<a =
href=3D"mailto:[email-masked]">mailto:[email-masked]</a=
>]<span
class=3Dapple-converted-space>&nbsp;</span><br>
<b><span style=3D'font-weight:bold'>Sent:</span></b><span
class=3Dapple-converted-space>&nbsp;</span>Tuesday, December 04, 2007 =
2:58 PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b><span
class=3Dapple-converted-space>&nbsp;</span><a =
href=3D"mailto:[email-masked]">[email-masked]</a><br>
<b><span style=3D'font-weight:bold'>Cc:</span></b><span
class=3Dapple-converted-space>&nbsp;</span><st1:PersonName =
w:st=3D"on">Attila
 Takacs</st1:PersonName>;<span =
class=3Dapple-converted-space>&nbsp;</span><a
href=3D"mailto:[email-masked]">[email-masked]</a><br>=

<b><span style=3D'font-weight:bold'>Subject:</span></b><span
class=3Dapple-converted-space>&nbsp;</span>draft-takacs-ccamp-rsvp-te-eth=
-oam-ext-00.txt</span></font><font
color=3Dblack><span style=3D'color:black'><o:p></o:p></span></font></p>

<O:P></O:P></div>

<div>

<div>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:black'><O:P></O:P><O:P></O:P>After =
reading this
draft, I have some =
questions/comments.<O:P></O:P><o:p></o:p></span></font></p>

</div>

</div>

<div>

<div>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:black'><O:P></O:P>1) Overall,&nbsp;I am =
concerned
that the definition of a new TLV and these procedures =
represent&nbsp;<O:P></O:P><o:p></o:p></span></font></p>

</div>

</div>

<div>

<div>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:black'>what amounts to a laying =
violation and ask
that the ADs take a look at this<O:P></O:P><o:p></o:p></span></font></p>

</div>

</div>

<div>

<div>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:black'>approach closely. This is similar =
to the
now-rejected approach that was =
proposed<O:P></O:P><o:p></o:p></span></font></p>

</div>

</div>

<div>

<div>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:black'>in the l2vpn WG about munging CFM =
+ PWs.
&nbsp;To my reading, this is =
essentially<O:P></O:P><o:p></o:p></span></font></p>

</div>

</div>

<div>

<div>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:black'>the same thing. If you want to =
run CFM,
run it natively over the ethernet interfaces =
and<O:P></O:P><o:p></o:p></span></font></p>

</div>

</div>

<div>

<div>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:black'>have no regard for the underlying =
topology
(GMPLS, PWs, etc...) otherwise =
you&nbsp;<O:P></O:P><o:p></o:p></span></font></p>

</div>

</div>

<div>

<div>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:black'>will be creating a mess for
implementations and interoperability.&nbsp;</span></font><font size=3D2
color=3Dblue face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:blue'>&nbsp;</span></font><font color=3Dblack><span =
style=3D'color:black'><o:p></o:p></span></font></p>

<O:P></O:P></div>

</div>

</blockquote>

<div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>The application&nbsp;of the draft =
is
exactly for what you are calling out: when CFM is run natively over the
Ethernet interfaces. The document focuses on GELS and Ethernet =
LSPs.&nbsp;That
is,&nbsp;to establish CFM entities for GMPLS controlled Ethernet
LSPs.&nbsp;Hence, I think there is no layer violation =
issue.</span></font><font
color=3Dblack><span style=3D'color:black'><o:p></o:p></span></font></p>

<O:P></O:P></div>

</div>

</div>

<div>

<p class=3DMsoNormal><span class=3Dapple-tab-span><O:P></O:P><font =
size=3D3
color=3Dblack face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt;color:black'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;</span></font></span><span
class=3Dapple-converted-space><font color=3Dblack><span =
style=3D'color:black'>&nbsp;</span></font></span><font
color=3Dblack><span style=3D'color:black'>This solution specifically =
only works for
GMPLS ethernet LSPs, right? &nbsp;<o:p></o:p></span></font></p>

<O:P></O:P></div>

</div>

<div>

<div>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:black'>What do I do if I want to set up =
MPLS
ethernet LSPs (i.e.: PWs)&nbsp;and do CFM over those? =
Oh,<O:P></O:P><o:p></o:p></span></font></p>

</div>

</div>

<div>

<div>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:black'>that is a different solution, =
right?
&nbsp;Then what do I do if I want to run CFM over some new type =
of<O:P></O:P><o:p></o:p></span></font></p>

</div>

</div>

<div>

<div>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:black'>ethernet LSP in the future? More =
protocol
hacks? &nbsp;The point is to use CFM over an ethernet =
interface<O:P></O:P><o:p></o:p></span></font></p>

</div>

</div>

<div>

<div>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:black'>without the underlying layers =
knowing.
This is good networking architecture design, that =
simplifies<O:P></O:P><o:p></o:p></span></font></p>

</div>

</div>

<div>

<div>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:black'>implementations and makes them =
more
robust, as well as makes using them operationally =
much<O:P></O:P><o:p></o:p></span></font></p>

</div>

</div>

<div>

<div>

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

</div>

</div>

<div>

<blockquote style=3D'margin-top:5.0pt;margin-bottom:5.0pt' type=3Dcite>

<div style=3D'WORD-WRAP: break-word'>

<blockquote style=3D'border:none;border-left:solid blue =
1.5pt;padding:0cm 0cm 0cm 4.0pt;
margin-left:3.75pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt'=

<div>

<div>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:black'>2)&nbsp;The introductory sections =
in this
draft give a lot of discussion about fast fault detection. =
I<O:P></O:P><o:p></o:p></span></font></p>

</div>

</div>

<div>

<div>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:black'>am puzzled by this given that =
GMPLS
networks tend to run over quickly =
self-healing<O:P></O:P><o:p></o:p></span></font></p>

</div>

</div>

<div>

<div>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:black'>optical infrastructures. Is it
therefore&nbsp;truly&nbsp;necessary to motivate this work =
by<O:P></O:P><o:p></o:p></span></font></p>

</div>

</div>

<div>

<div>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:black'>requiring fast =
CFMs?<O:P></O:P><o:p></o:p></span></font></p>

</div>

</div>

</blockquote>

<div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>It is right that frequent CCMs are =
not
required if the layers below Ethernet handle protection. However, the ID
focuses on Ethernet LSPs where Ethernet is&nbsp;not just a single
hop&nbsp;above a transport LSP.&nbsp;In this case&nbsp;Ethernet layer =
(for
clarity GELS) may provide protection for Ethernet LSPs.&nbsp;In any =
case,&nbsp;
the whole point of the ID is to allow for the appropriate configuration =
of CFM
for Ethernet LSPs with GMPLS.</span></font><font color=3Dblack><span
style=3D'color:black'><o:p></o:p></span></font></p>

<O:P></O:P></div>

</div>

<blockquote style=3D'border:none;border-left:solid blue =
1.5pt;padding:0cm 0cm 0cm 4.0pt;
margin-left:3.75pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt'=

<div>

<div>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:black'><O:P></O:P>3) This document does =
not cover
E-LMI. Why not?<O:P></O:P><o:p></o:p></span></font></p>

</div>

</div>

</blockquote>

<div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>E-LMI is run over the MEF UNI. =
The&nbsp;ID
focuses on Ethernet LSPs within a network.</span></font><font =
color=3Dblack><span
style=3D'color:black'><o:p></o:p></span></font></p>

<O:P></O:P></div>

</div>

<blockquote style=3D'border:none;border-left:solid blue =
1.5pt;padding:0cm 0cm 0cm 4.0pt;
margin-left:3.75pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt'=

<div>

<div>

<p class=3DMsoNormal><span class=3Dapple-style-span><O:P></O:P><font =
size=3D1
color=3Dblack face=3D"Times New Roman"><span =
style=3D'font-size:9.0pt;color:black'><O:P></O:P>For
the purposes of this document, we only discuss Ethernet =
OAM</span></font></span><font
color=3Dblack><span style=3D'color:black'><o:p></o:p></span></font></p>

<O:P></O:P></div>

</div>

<div>

<div>

<p class=3DMsoNormal><font size=3D1 color=3Dblack face=3DHelvetica><span
style=3D'font-size:9.0pt;font-family:Helvetica;color:black'>&nbsp;&nbsp;
[IEEE-CFM] aspects that are relevant for the connectivity =
monitoring<O:P></O:P></span></font><font
color=3Dblack><span style=3D'color:black'><o:p></o:p></span></font></p>

</div>

</div>

<div>

<div>

<p class=3DMsoNormal><font size=3D1 color=3Dblack face=3DHelvetica><span
style=3D'font-size:9.0pt;font-family:Helvetica;color:black'>&nbsp;&nbsp; =
of
bidirectional point-to-point PBB-TE connections. =
&nbsp;<O:P></O:P></span></font><font
color=3Dblack><span style=3D'color:black'><o:p></o:p></span></font></p>

</div>

</div>

<div>

<div>

<p class=3DMsoNormal><font size=3D1 color=3Dblack face=3DHelvetica><span
style=3D'font-size:9.0pt;font-family:Helvetica;color:black'><O:P></O:P>4)=
 Is this
the right place to define this document or should this be done in =
GELS?<O:P></O:P></span></font><font
color=3Dblack><span style=3D'color:black'><o:p></o:p></span></font></p>

</div>

</div>

</blockquote>

<div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Well, GELS is done in CCAMP...this =
seems
to be the right place.</span></font><font color=3Dblack><span =
style=3D'color:black'><o:p></o:p></span></font></p>

<O:P></O:P></div>

</div>

<blockquote style=3D'border:none;border-left:solid blue =
1.5pt;padding:0cm 0cm 0cm 4.0pt;
margin-left:3.75pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt'=

<div>

<div>

<p class=3DMsoNormal><font size=3D1 color=3Dblack face=3DHelvetica><span
style=3D'font-size:9.0pt;font-family:Helvetica;color:black'><O:P></O:P><O=
:P></O:P>5)
&nbsp; In section 2 you make the following =
statement:<O:P></O:P></span></font><font
color=3Dblack><span style=3D'color:black'><o:p></o:p></span></font></p>

</div>

</div>

<div>

<div>

<p class=3DMsoNormal><font size=3D1 color=3Dblack face=3DHelvetica><span
style=3D'font-size:9.0pt;font-family:Helvetica;color:black'><O:P></O:P>2.=
&nbsp;
GMPLS RSVP-TE Extensions<O:P></O:P></span></font><font =
color=3Dblack><span
style=3D'color:black'><o:p></o:p></span></font></p>

</div>

</div>

<div>

<div>

<p class=3DMsoNormal><font size=3D1 color=3Dblack face=3DHelvetica><span
style=3D'font-size:9.0pt;font-family:Helvetica;color:black'><O:P></O:P>&n=
bsp;<span
class=3Dapple-converted-space>&nbsp;</span>&nbsp; To simplify the =
configuration
of connectivity monitoring, when an<O:P></O:P></span></font><font =
color=3Dblack><span
style=3D'color:black'><o:p></o:p></span></font></p>

</div>

</div>

<div>

<div>

<p class=3DMsoNormal><font size=3D1 color=3Dblack face=3DHelvetica><span
style=3D'font-size:9.0pt;font-family:Helvetica;color:black'>&nbsp;&nbsp; =
Ethernet
LSP is signalled the associated MEPs should be =
automatically<O:P></O:P></span></font><font
color=3Dblack><span style=3D'color:black'><o:p></o:p></span></font></p>

</div>

</div>

<div>

<div>

<p class=3DMsoNormal><font size=3D1 color=3Dblack face=3DHelvetica><span
style=3D'font-size:9.0pt;font-family:Helvetica;color:black'>&nbsp;<span
class=3Dapple-converted-space>&nbsp;</span>&nbsp; established.&nbsp; =
Further
more, GMPLS signalling should be able to<O:P></O:P></span></font><font
color=3Dblack><span style=3D'color:black'><o:p></o:p></span></font></p>

</div>

</div>

<div>

<div>

<p class=3DMsoNormal><font size=3D1 color=3Dblack face=3DHelvetica><span
style=3D'font-size:9.0pt;font-family:Helvetica;color:black'>&nbsp;&nbsp;e=
nable/disable
connectivity monitoring of a particular Ethernet =
LSP.<O:P></O:P></span></font><font
color=3Dblack><span style=3D'color:black'><o:p></o:p></span></font></p>

</div>

</div>

<div>

<div>

<p class=3DMsoNormal><font size=3D1 color=3Dblack face=3DHelvetica><span
style=3D'font-size:9.0pt;font-family:Helvetica;color:black'><O:P></O:P><O=
:P></O:P>To
my point in #1 above, you should use the native CFM functionality over =
the
ethernet interface and signal<O:P></O:P></span></font><font =
color=3Dblack><span
style=3D'color:black'><o:p></o:p></span></font></p>

</div>

</div>

<div>

<div>

<p class=3DMsoNormal><font size=3D1 color=3Dblack face=3DHelvetica><span
style=3D'font-size:9.0pt;font-family:Helvetica;color:black'>those =
capabilities to
the bridges at both ends using the IEEE CFM signaling procedures (when =
and if
they<O:P></O:P></span></font><font color=3Dblack><span =
style=3D'color:black'><o:p></o:p></span></font></p>

</div>

</div>

<div>

<div>

<p class=3DMsoNormal><font size=3D1 color=3Dblack face=3DHelvetica><span
style=3D'font-size:9.0pt;font-family:Helvetica;color:black'>are =
created).
&nbsp;If you want to test the underlying GMPLS LSP(s), then you should =
use some<O:P></O:P></span></font><font
color=3Dblack><span style=3D'color:black'><o:p></o:p></span></font></p>

</div>

</div>

<div>

<div>

<p class=3DMsoNormal><font size=3D1 color=3Dblack face=3DHelvetica><span
style=3D'font-size:9.0pt;font-family:Helvetica;color:black'>other =
mechanism
defined for that layer such as the work stated =
in&nbsp;</span></font><span
class=3Dapple-style-span><b><font size=3D2 color=3Dblack =
face=3DHelvetica><span
style=3D'font-size:10.0pt;font-family:Helvetica;color:black;font-weight:b=
old'>draft-ali-ccamp-gmpls-LSP-ping-traceroute-00.txt</span></font></b></=
span><font
color=3Dblack><span =
style=3D'color:black'><O:P></O:P><o:p></o:p></span></font></p>

</div>

</div>

</blockquote>

<div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>See the note&nbsp;to your point #1. =
There
is no relation&nbsp;to the gmpls-LSP-ping =
draft.&nbsp;</span></font><font
color=3Dblack><span =
style=3D'color:black'><O:P></O:P><o:p></o:p></span></font></p>

</div>

</div>

</div>

</blockquote>

<div>

<p class=3DMsoNormal><span class=3Dapple-tab-span><O:P></O:P><font =
size=3D3
color=3Dblack face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt;color:black'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;</span></font></span><span
class=3Dapple-converted-space><font color=3Dblack><span =
style=3D'color:black'>&nbsp;</span></font></span><font
color=3Dblack><span style=3D'color:black'>The point I am making is that =
perhaps it
should.<o:p></o:p></span></font></p>

<O:P></O:P></div>

</div>

<div>

<div>

<p class=3DMsoNormal><span class=3Dapple-tab-span><O:P></O:P><font =
size=3D3
color=3Dblack face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt;color:black'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;</span></font></span><span
class=3Dapple-converted-space><font color=3Dblack><span =
style=3D'color:black'>&nbsp;</span></font></span><font
color=3Dblack><span =
style=3D'color:black'>--Tom<o:p></o:p></span></font></p>

<O:P></O:P></div>

</div>

</div>

</div>

</div>

</div>

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

</blockquote>

</blockquote>

</div>

<O:P></O:P><O:P></O:P><O:P></O:P><O:P></O:P><O:P></O:P></span></div>

</body>

</html>

------_=_NextPart_001_01C8375B.C5166677--

Delivery-date: Wed, 05 Dec 2007 13:12:11 +0000
Cc: <[email-masked]>, "Otani Tomohiro" <[email-masked]>
From: Thomas Nadeau <[email-masked]>
To: "Zafar Ali (zali)" <[email-masked]>
Subject: Re: draft-ali-ccamp-gmpls-LSP-ping-traceroute-00.txt 
Date: Wed, 5 Dec 2007 08:09:38 -0500

On Dec 5, 2007, at 5:33 AM, Zafar Ali (zali) wrote:

> Hi Tom-
>
> Thanks for your review; please see comments in-line.
>
> Thanks
>
> Regards... Zafar
>
>> -----Original Message-----
>> From: Thomas Nadeau [mailto:[email-masked]]
>> Sent: Tuesday, December 04, 2007 8:43 AM
>> To: [email-masked]
>> Cc: Otani Tomohiro; Zafar Ali (zali)
>> Subject: draft-ali-ccamp-gmpls-LSP-ping-traceroute-00.txt
>>
>>
>> 	I have some questions/comments about this draft.
>> 	
>> 	0) The draft needs to be organized a bit better so that it is
>> 		clear what you are trying to achieve.
>
> Sure we will spend efforts to clarify the text further.
>
>> For example,
>> 		some of the introductory text is unclear as to whether
>> 		or not you are verifying the control or data planes (or
>> 		both).
>
> Data plane.

	Can you explain in the document how this works? That, how do  
intermediate
nodes use LMP to check the data plane along the path. It seems to me  
for instance,
that since you are using LMP, you are testing each "segment" of the  
optical path.
This is certainly not end2end testing, so please be clear on this.   
Also the procedures
for how this works need to be clear. Take a look at RFC4379 for  
examples of how
they (we) specified this. The clearest form IMHO is to use pseudo-code/ 
algorithmic
descriptions of all the steps. This way everyone can clearly see what  
is going on
here.

>> At least to my reading.
>>
>> 	1) This solution seems tightly coupled between RFCs
>> 4204 and 4379.
>> 		Is it reasonable to assume that all implementations
>> 		will support 4204?
>
> Yes, LMP is already widely implemented (for GMPLS) and already  
> provides
> lots of GMPLS OAM solutions. I don't see any reason not to reuse it.
>
>> This also seems to beg the question
>> 		of "are there too many moving parts here?" for this
>> 		to ultimately work and interoperate between 2 vendors.
>>
>
> No, I don't think so. Reusing existing protocol/ tool further helps  
> this
> cause.

	See below.

>> 	2) Which packet formats are to be used in this
>> approach? All I see
>> 		are statements like "send Test messages", but
>> no details of
>> 		that.
>>
>
> All encoding methods for TEST message that are defined in LMP
> specification are assumed to be permissible. We can add a more  
> elaborate
> text to state the same.

	Cool. I think the document needs far more details for others to  
implement/understand
it for sure.

>> 	3) Can this approach guarantee that the data plane is checked
>> 		completely, and if not, what percentage of coverage is
>> 		given?
>>
>
> Yes, it does guarantee data plane connectivity. We can chat more
> off-line on this.

	OK.

>> 	4) In section 2.2, you stipulate:
>>
>> 	To limit the scope of LSP Verification to a
>>         particular LSP, LSP-id is used in LOCAL_LINK_ID or
>>         REMOTE_LINK_ID fields of the LMP message exchanges during
>>         verification.
>>
>> 	Something similar has been proposed as an addition to
>> lsp ping for
>> 	the multi-cast case. Please check into this to see if this is
>> 	similar enough to reuse that object.
>>
>
> Sure, we will look into this.
>
>> 	5) Is the link verification actually sent over the LMP
>> control channel or
>> 		the actual data path? Your text is unclear on this:
>>
>
> Control messages to setup link/ LSP verification, e.g., BeginVerify,
> etc. are sent via control channel and "Test" message is sent in-band  
> of
> LSP. Think of LSP as a TE link.
	
	This gets to my point about "too many moving parts". What concerns me
about this is not the re-use of LMP per se; thats a good idea in the  
sense of
code/protocol re-use; however, what worries me is one protocol  
stimulating
actions in another like this. There are security implications here  
that need to
be addressed. Also, how certain are you that the implementations of  
LMP out there
will all behave the same way once you initiate the generation of these  
messages?

>> 	        To initiate the link verification
>> procedure, the Ingress
>>         (Egress) node MUST send a BeginVerify message over a control
>>         channel with IP address of the destination (source) node of
>>         the LSP.  To limit the scope of LSP Verification to a
>>         particular LSP, LSP-id is used in LOCAL_LINK_ID or
>>         REMOTE_LINK_ID fields of the LMP message exchanges during
>>         verification. If the LINK_ID field is zero, the verification
>>         can span multiple LSPs between the set of
>> Ingress/Egress nodes
>>         involved in the verification process. The rest of the details
>>         for LSP verification follow the LMP link verification
>>         procedure [RFC4204].
>>
>> 	RFC4204 states that the link verify messages are NOT to be sent
>> 	over the control channel,
>
> You meant "Test" message is not sent over the control channel, right.
> Yes, this is also the case of this draft.

	This needs to be clarified.

>> and since you want to verify the
>> 	data plane you should follow its rules for this:
>>
>> 	12.5.6.  Test Message (Msg Type = 10)
>>
>> 	   The Test message is transmitted over the data link
>> and is used to
>> 	   verify its physical connectivity.  Unless explicitly
>> stated, these
>> 	   messages MUST be transmitted over UDP like all other
>> LMP messages.
>> 	   The format of the Test messages is as follows:
>>
>> 	   <Test Message> ::= <Common Header>
>> <LOCAL_INTERFACE_ID> <VERIFY_ID>
>>
>> 	   The above transmission order SHOULD be followed.
>>
>> 	   Note that this message is sent over a data link and
>> NOT over the
>>  	  control channel.  The transport mechanism for the
>> Test message is
>>  	  negotiated using the Verify Transport Mechanism field of the
>>  	  BEGIN_VERIFY object and the Verify Transport Response
>> field of the
>>  	  BEGIN_VERIFY_ACK object (see Sections 13.8 and 13.9).
>>
>>
>> 	6) I suggest passing this document by the MPLS WG and
>> the LSP ping co- authors
>> 		to ensure that your desire to reuse that
>> protocol will indeed
>> 		work, and that if this is eventually adopted as
>> a CCAMP work item
>> 		that it not pass WG last call until the MPLS WG
>> has reviewed it.
>>
>
> Most certainly. We will send a private email to LSP Ping co-authors  
> and
> MPLS WG Chairs (w/ CCAMP WG Chair cc'ed).

	Thanks.

	--Tom

Delivery-date: Wed, 05 Dec 2007 10:35:49 +0000
Content-class: urn:content-classes:message
Subject: RE: draft-ali-ccamp-gmpls-LSP-ping-traceroute-00.txt 
Date: Wed, 5 Dec 2007 05:33:11 -0500
From: "Zafar Ali (zali)" <[email-masked]>
To: "Thomas Nadeau" <[email-masked]>, <[email-masked]>
Cc: "Otani Tomohiro" <[email-masked]>

Hi Tom-=20

Thanks for your review; please see comments in-line. =20

Thanks

Regards... Zafar=20

> -----Original Message-----
> From: Thomas Nadeau [mailto:[email-masked]]=20
> Sent: Tuesday, December 04, 2007 8:43 AM
> To: [email-masked]
> Cc: Otani Tomohiro; Zafar Ali (zali)
> Subject: draft-ali-ccamp-gmpls-LSP-ping-traceroute-00.txt=20
>=20
>=20
> 	I have some questions/comments about this draft.
> =09
> 	0) The draft needs to be organized a bit better so that it is
> 		clear what you are trying to achieve. =20

Sure we will spend efforts to clarify the text further.=20

> For example,
> 		some of the introductory text is unclear as to whether
> 		or not you are verifying the control or data planes (or
> 		both).=20

Data plane.=20

> At least to my reading.
>=20
> 	1) This solution seems tightly coupled between RFCs=20
> 4204 and 4379.
> 		Is it reasonable to assume that all implementations
> 		will support 4204? =20

Yes, LMP is already widely implemented (for GMPLS) and already provides
lots of GMPLS OAM solutions. I don't see any reason not to reuse it.=20

> This also seems to beg the question
> 		of "are there too many moving parts here?" for this
> 		to ultimately work and interoperate between 2 vendors.
>=20

No, I don't think so. Reusing existing protocol/ tool further helps this
cause.=20

> 	2) Which packet formats are to be used in this=20
> approach? All I see
> 		are statements like "send Test messages", but=20
> no details of
> 		that.
>=20

All encoding methods for TEST message that are defined in LMP
specification are assumed to be permissible. We can add a more elaborate
text to state the same.=20

> 	3) Can this approach guarantee that the data plane is checked
> 		completely, and if not, what percentage of coverage is
> 		given?
>=20

Yes, it does guarantee data plane connectivity. We can chat more
off-line on this.=20

> 	4) In section 2.2, you stipulate:
>=20
> 	To limit the scope of LSP Verification to a
>          particular LSP, LSP-id is used in LOCAL_LINK_ID or
>          REMOTE_LINK_ID fields of the LMP message exchanges during
>          verification.
>=20
> 	Something similar has been proposed as an addition to=20
> lsp ping for
> 	the multi-cast case. Please check into this to see if this is
> 	similar enough to reuse that object.
>=20

Sure, we will look into this.=20

> 	5) Is the link verification actually sent over the LMP=20
> control channel or
> 		the actual data path? Your text is unclear on this:
>=20

Control messages to setup link/ LSP verification, e.g., BeginVerify,
etc. are sent via control channel and "Test" message is sent in-band of
LSP. Think of LSP as a TE link.=20

> 		        To initiate the link verification=20
> procedure, the Ingress
>          (Egress) node MUST send a BeginVerify message over a control
>          channel with IP address of the destination (source) node of
>          the LSP.  To limit the scope of LSP Verification to a
>          particular LSP, LSP-id is used in LOCAL_LINK_ID or
>          REMOTE_LINK_ID fields of the LMP message exchanges during
>          verification. If the LINK_ID field is zero, the verification
>          can span multiple LSPs between the set of=20
> Ingress/Egress nodes
>          involved in the verification process. The rest of the details
>          for LSP verification follow the LMP link verification
>          procedure [RFC4204].
>=20
> 	RFC4204 states that the link verify messages are NOT to be sent
> 	over the control channel,=20

You meant "Test" message is not sent over the control channel, right.
Yes, this is also the case of this draft.=20

> and since you want to verify the
> 	data plane you should follow its rules for this:
>=20
> 	12.5.6.  Test Message (Msg Type =3D 10)
>=20
> 	   The Test message is transmitted over the data link=20
> and is used to
> 	   verify its physical connectivity.  Unless explicitly=20
> stated, these
> 	   messages MUST be transmitted over UDP like all other=20
> LMP messages.
> 	   The format of the Test messages is as follows:
>=20
> 	   <Test Message> ::=3D <Common Header>=20
> <LOCAL_INTERFACE_ID> <VERIFY_ID>
>=20
> 	   The above transmission order SHOULD be followed.
>=20
> 	   Note that this message is sent over a data link and=20
> NOT over the
>   	  control channel.  The transport mechanism for the=20
> Test message is
>   	  negotiated using the Verify Transport Mechanism field of the
>   	  BEGIN_VERIFY object and the Verify Transport Response=20
> field of the
>   	  BEGIN_VERIFY_ACK object (see Sections 13.8 and 13.9).
>=20
>=20
> 	6) I suggest passing this document by the MPLS WG and=20
> the LSP ping co- authors
> 		to ensure that your desire to reuse that=20
> protocol will indeed
> 		work, and that if this is eventually adopted as=20
> a CCAMP work item
> 		that it not pass WG last call until the MPLS WG=20
> has reviewed it.
>=20

Most certainly. We will send a private email to LSP Ping co-authors and
MPLS WG Chairs (w/ CCAMP WG Chair cc'ed).=20

> =09
>=20
>=20

Delivery-date: Wed, 05 Dec 2007 07:00:05 +0000
Content-class: urn:content-classes:message
Subject: RE: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt
Date: Wed, 5 Dec 2007 06:55:15 -0000
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C8370C.22930EF6
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I'm puzzled.  I read the draft and thought it was excellent.  It is =
addressing an important operational issue, ie a critical operational OAM =
requirement is to ensure that whatever mechanism (MP or CP) is used to =
set-up/tear-down a connection (so this only applies to co-cs or co-ps =
modes....the cl-ps mode does not have connections of course) is =
harmonised to the activation/deactivation of the OAM.....specifically a =
CV/CC flow.   If we don't ensure this then there will be obvious =
operational problems.  This is essentially what the draft is about.
=20
Further, GMPLS is a generic OOB CP technique.....it is not a specific =
layer network technology per se (but it is specific in it's choice of =
signalling and routing components).  So one can apply a largely similar =
(GMPLS) CP technique to all co-cs mode technologies (whether they are =
partitioning a space, freq or time resource - see Note) and co-ps mode =
technologies (which only applies to partitioning a time resource - see =
Note) on the assumption that the technology is correctly architected in =
the DP for the mode considered.  It's pretty hard not to correctly =
architect the co-cs mode, but it's quite easy to incorrectly architect =
the co-ps mode, eg one can't violate the rules of a connection in the =
co-cs mode but one can in the co-ps mode.
=20
Note - When we partition a time resource in regular time-slices we =
create a co-cs mode layer network.  When we partition a time resource in =
irregular time-slices we create a co-ps mode layer network.  More =
information on labelling and resource partitioning can be found in the =
work on unified modelling (of networks) in G.800.
=20
regards, Neil

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On =
Behalf Of Attila Takacs
Sent: 05 December 2007 02:03
To: Thomas Nadeau; Diego Caviglia
Cc: [email-masked]
Subject: RE: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt

Hi Tom,
please see inline.
Best regards,
Attila

  _____ =20

From: Thomas Nadeau [mailto:[email-masked]]=20
Sent: Wednesday, December 05, 2007 2:19 AM
To: Diego Caviglia
Cc: Attila Takacs; [email-masked]; [email-masked]
Subject: Re: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt

On Dec 4, 2007, at 7:33 PM, Diego Caviglia wrote:

Hi Thomas,
                 My understanding of the ID was that RSVP-TE can be used =
to 'piggyback' CFM set-up, otherwise the scenario is: usage of RSVP-TE =
to set-up the LSP and NMS (meaning everything that is not control plane) =
to enable to CFM for the LSP.

As I understand it, the IEEE is working on set-up of CFM (and MEPs), as =
are some vendors I know. *)
This to me seems like the right way to do this.
=20

IEEE specified CFM and MIBs to setup CFM.=20
Diego's summary is correct: one can use an NMS or a control plane to =
setup the data plane. In this case we propose to use GMPLS to setup the =
data plane: both forwarding + OAM.

>From your comment I see that you're not happy with the fact the ID is so =
technology specific am I right? =20

Precisely; its gluing CFM to RSVP-TE/GMPLS as a transport.=20

I do not see your point with gluing. What do you mean by "as transport"? =
GMPLS is just controlling OAM, CFM is run solely in the data plane.
=20

If yes do you agree with the fact that could be useful in general to use =
the same signaling 'session' to set-up the LSP and to enable the CFM?

No, I do not agree.  Again, if CFM is to be set-up e2e, let the IEEE =
define this. Leave GMPLS to CCAMP.

=20
=20
Sorry, I cannot follow.
=20
=20

=20
=20

--Tom

 Best Regards

Diego

  _____ =20

From: [email-masked] [mailto:[email-masked]] On =
Behalf Of Thomas Nadeau
Sent: marted=EC 4 dicembre 2007 11.30
To: Attila Takacs
Cc: [email-masked]; [email-masked]
Subject: Re: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt

On Dec 4, 2007, at 1:51 PM, Attila Takacs wrote:

Hi Thomas,

Thank you for the comments!
Please see answers inline.

Best regards,
Attila

  _____ =20

From: Thomas Nadeau [mailto:[email-masked]]=20
Sent: Tuesday, December 04, 2007 2:58 PM
To: [email-masked]
Cc: Attila Takacs; [email-masked]
Subject: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt

After reading this draft, I have some questions/comments.

1) Overall, I am concerned that the definition of a new TLV and these =
procedures represent=20
what amounts to a laying violation and ask that the ADs take a look at =
this
approach closely. This is similar to the now-rejected approach that was =
proposed
in the l2vpn WG about munging CFM + PWs.  To my reading, this is =
essentially
the same thing. If you want to run CFM, run it natively over the =
ethernet interfaces and
have no regard for the underlying topology (GMPLS, PWs, etc...) =
otherwise you=20
will be creating a mess for implementations and interoperability. =20

The application of the draft is exactly for what you are calling out: =
when CFM is run natively over the Ethernet interfaces. The document =
focuses on GELS and Ethernet LSPs. That is, to establish CFM entities =
for GMPLS controlled Ethernet LSPs. Hence, I think there is no layer =
violation issue.

          This solution specifically only works for GMPLS ethernet LSPs, =
right? =20
What do I do if I want to set up MPLS ethernet LSPs (i.e.: PWs) and do =
CFM over those? Oh,
that is a different solution, right?  Then what do I do if I want to run =
CFM over some new type of
ethernet LSP in the future? More protocol hacks?  The point is to use =
CFM over an ethernet interface
without the underlying layers knowing. This is good networking =
architecture design, that simplifies
implementations and makes them more robust, as well as makes using them =
operationally much
easier.=20

2) The introductory sections in this draft give a lot of discussion =
about fast fault detection. I
am puzzled by this given that GMPLS networks tend to run over quickly =
self-healing
optical infrastructures. Is it therefore truly necessary to motivate =
this work by
requiring fast CFMs?

It is right that frequent CCMs are not required if the layers below =
Ethernet handle protection. However, the ID focuses on Ethernet LSPs =
where Ethernet is not just a single hop above a transport LSP. In this =
case Ethernet layer (for clarity GELS) may provide protection for =
Ethernet LSPs. In any case,  the whole point of the ID is to allow for =
the appropriate configuration of CFM for Ethernet LSPs with GMPLS.

3) This document does not cover E-LMI. Why not?

E-LMI is run over the MEF UNI. The ID focuses on Ethernet LSPs within a =
network.

For the purposes of this document, we only discuss Ethernet OAM
   [IEEE-CFM] aspects that are relevant for the connectivity monitoring
   of bidirectional point-to-point PBB-TE connections. =20

4) Is this the right place to define this document or should this be =
done in GELS?

Well, GELS is done in CCAMP...this seems to be the right place.

5)   In section 2 you make the following statement:

2.  GMPLS RSVP-TE Extensions

    To simplify the configuration of connectivity monitoring, when an
   Ethernet LSP is signalled the associated MEPs should be automatically
    established.  Further more, GMPLS signalling should be able to
  enable/disable connectivity monitoring of a particular Ethernet LSP.

To my point in #1 above, you should use the native CFM functionality =
over the ethernet interface and signal
those capabilities to the bridges at both ends using the IEEE CFM =
signaling procedures (when and if they
are created).  If you want to test the underlying GMPLS LSP(s), then you =
should use some
other mechanism defined for that layer such as the work stated in =
draft-ali-ccamp-gmpls-LSP-ping-traceroute-00.txt

See the note to your point #1. There is no relation to the =
gmpls-LSP-ping draft.=20

          The point I am making is that perhaps it should.

          --Tom

------_=_NextPart_001_01C8370C.22930EF6
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>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<TITLE>Message</TITLE>

<META content=3D"MSHTML 6.00.2900.2769" name=3DGENERATOR></HEAD>
<BODY=20
style=3D"WORD-WRAP: break-word; webkit-nbsp-mode: space; =
webkit-line-break: after-white-space">
<DIV><SPAN class=3D673011106-05122007><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
size=3D2>I'm puzzled.&nbsp; I read the draft and thought it was =
excellent.&nbsp;=20
It is addressing an important operational issue, ie a critical =
operational OAM=20
requirement is to ensure that whatever mechanism (MP or CP) is used to=20
set-up/tear-down a connection (so this only applies to co-cs or co-ps=20
modes....the cl-ps mode does not have connections of course) is =
harmonised to=20
the activation/deactivation of the OAM.....specifically a CV/CC=20
flow.&nbsp;&nbsp; If we don't ensure this then there will be obvious =
operational=20
problems.&nbsp; This is essentially what the draft is =
about.</FONT></SPAN></DIV>
<DIV><SPAN class=3D673011106-05122007><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D673011106-05122007><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
size=3D2>Further, GMPLS is a generic&nbsp;OOB&nbsp;CP technique.....it =
is not a=20
specific layer network technology per se (but it is specific in it's =
choice of=20
signalling and routing components).&nbsp; So one can apply a largely =
similar=20
(GMPLS) CP technique to all co-cs mode technologies (whether they are=20
partitioning a space, freq or&nbsp;time resource - see Note) and co-ps =
mode=20
technologies (which only applies to partitioning a time resource - see =
Note) on=20
the assumption that the technology is correctly architected in the DP =
for the=20
mode considered.&nbsp;&nbsp;It's pretty hard not to correctly architect =
the=20
co-cs mode, but it's quite easy to incorrectly architect the co-ps mode, =
eg one=20
can't violate the rules of a connection in the co-cs mode but one can in =
the=20
co-ps mode.</FONT></SPAN></DIV>
<DIV><SPAN class=3D673011106-05122007><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D673011106-05122007><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
size=3D2>Note - When we partition a time resource in regular time-slices =
we create=20
a co-cs mode layer network.&nbsp; When we partition a time resource in =
irregular=20
time-slices we create a co-ps mode layer network.&nbsp; More information =
on=20
labelling and resource partitioning can be found in the work on unified=20
modelling (of networks) in G.800.</FONT></SPAN></DIV>
<DIV><SPAN class=3D673011106-05122007><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D673011106-05122007><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
size=3D2>regards, Neil</FONT></SPAN></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #800000 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>=20
  [email-masked] [mailto:[email-masked]] <B>On =
Behalf Of=20
  </B>Attila Takacs<BR><B>Sent:</B> 05 December 2007 02:03<BR><B>To:</B> =
Thomas=20
  Nadeau; Diego Caviglia<BR><B>Cc:</B> =
[email-masked]<BR><B>Subject:</B> RE:=20
  draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt<BR><BR></FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D993515301-05122007>Hi=20
  Tom,</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D993515301-05122007>please see inline.</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D993515301-05122007>Best=20
  regards,</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D993515301-05122007>Attila</SPAN></FONT></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> Thomas Nadeau=20
    [mailto:[email-masked]] <BR><B>Sent:</B> Wednesday, =
December 05,=20
    2007 2:19 AM<BR><B>To:</B> Diego Caviglia<BR><B>Cc:</B> Attila =
Takacs;=20
    [email-masked]; [email-masked]<BR><B>Subject:</B> Re:=20
    draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt<BR></FONT><BR></DIV>
    <DIV></DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT><FONT =
face=3DArial=20
    color=3D#0000ff size=3D2></FONT><BR>
    <DIV>
    <DIV>On Dec 4, 2007, at 7:33 PM, Diego Caviglia wrote:</DIV><BR=20
    class=3DApple-interchange-newline>
    <BLOCKQUOTE type=3D"cite"><SPAN class=3DApple-style-span=20
      style=3D"WORD-SPACING: 0px; FONT: 13px Helvetica; TEXT-TRANSFORM: =
none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; =
LETTER-SPACING: normal; BORDER-COLLAPSE: separate; orphans: 2; widows: =
2; webkit-border-horizontal-spacing: 0px; =
webkit-border-vertical-spacing: 0px; webkit-text-decorations-in-effect: =
none; webkit-text-size-adjust: auto; webkit-text-stroke-width: 0">
      <DIV lang=3DEN-US=20
      style=3D"WORD-WRAP: break-word; webkit-nbsp-mode: space; =
webkit-line-break: after-white-space"=20
      link=3D"blue" vlink=3D"blue">
      <DIV class=3DSection1>
      <DIV=20
      style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: 'Times =
New Roman'"><FONT=20
      face=3DArial color=3Dnavy size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Hi=20
      Thomas,<O:P></O:P></SPAN></FONT></DIV>
      <DIV=20
      style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: 'Times =
New Roman'"><FONT=20
      face=3DArial color=3Dnavy size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
      My understanding of the ID was that RSVP-TE can be used to =
&#8216;piggyback&#8217; CFM=20
      set-up, otherwise the scenario is: usage of RSVP-TE to set-up the =
LSP and=20
      NMS (meaning everything that is not control plane) to enable to =
CFM for=20
      the LSP.</SPAN></FONT></DIV></DIV></DIV></SPAN></BLOCKQUOTE>
    <DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT><FONT =
face=3DArial=20
    color=3D#0000ff size=3D2></FONT><BR =
class=3Dwebkit-block-placeholder></DIV><SPAN=20
    class=3DApple-tab-span style=3D"WHITE-SPACE: pre"></SPAN>As I =
understand it, the=20
    IEEE is working on set-up of CFM (and MEPs), as are some vendors I =
know.=20
    *)</DIV>
    <DIV>This to me seems like the right way to do this.</DIV>
    <DIV><SPAN class=3D993515301-05122007><FONT face=3DArial =
color=3D#0000ff=20
    size=3D2></FONT></SPAN>&nbsp;</DIV></BLOCKQUOTE>
  <DIV><SPAN class=3D993515301-05122007><FONT face=3DArial =
color=3D#0000ff size=3D2>IEEE=20
  specified CFM and MIBs to setup CFM.&nbsp;</FONT></SPAN></DIV>
  <DIV><SPAN class=3D993515301-05122007><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>Diego's summary is correct: one can use an NMS or&nbsp;a =
control plane=20
  to setup the data plane. In this case we propose to use&nbsp;GMPLS to =
setup=20
  the data plane: both forwarding + OAM.</FONT></SPAN><BR></DIV>
  <BLOCKQUOTE=20
  style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
    <BLOCKQUOTE type=3D"cite"><SPAN class=3DApple-style-span=20
      style=3D"WORD-SPACING: 0px; FONT: 13px Helvetica; TEXT-TRANSFORM: =
none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; =
LETTER-SPACING: normal; BORDER-COLLAPSE: separate; orphans: 2; widows: =
2; webkit-border-horizontal-spacing: 0px; =
webkit-border-vertical-spacing: 0px; webkit-text-decorations-in-effect: =
none; webkit-text-size-adjust: auto; webkit-text-stroke-width: 0">
      <DIV class=3DSection1 lang=3DEN-US=20
      style=3D"WORD-WRAP: break-word; webkit-nbsp-mode: space; =
webkit-line-break: after-white-space"=20
      link=3D"blue" vlink=3D"blue">
      <DIV=20
      style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: 'Times =
New Roman'"><FONT=20
      face=3DArial color=3Dnavy size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><O:P></O:P></SPAN></FONT></DIV>
      <DIV=20
      style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: 'Times =
New Roman'"><SPAN=20
      class=3DApple-style-span=20
      style=3D"FONT-SIZE: 13px; COLOR: rgb(20,79,174); =
webkit-text-stroke-width: -1">From=20
      your comment I see that you&#8217;re not happy with the fact the =
ID is so=20
      technology specific am I right?=20
&nbsp;</SPAN></DIV></DIV></SPAN></BLOCKQUOTE>
    <DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT><FONT =
face=3DArial=20
    color=3D#0000ff size=3D2></FONT><FONT face=3DArial color=3D#0000ff=20
    size=3D2></FONT><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT><FONT face=3DArial=20
    color=3D#0000ff size=3D2></FONT><FONT face=3DArial color=3D#0000ff=20
    size=3D2></FONT><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT><BR=20
    class=3Dwebkit-block-placeholder></DIV>
    <DIV><SPAN class=3DApple-tab-span style=3D"WHITE-SPACE: =
pre"></SPAN>Precisely;=20
    its gluing CFM to RSVP-TE/GMPLS as a transport.&nbsp;<BR=20
    class=3Dwebkit-block-placeholder></DIV><FONT face=3DArial =
color=3D#0000ff=20
    size=3D2></FONT><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT><FONT face=3DArial=20
    color=3D#0000ff size=3D2></FONT></BLOCKQUOTE>
  <DIV><SPAN class=3D993515301-05122007><FONT face=3DArial =
color=3D#0000ff size=3D2>I do=20
  not see your point with gluing. What do you mean by "as transport"? =
GMPLS is=20
  just controlling OAM, CFM is run solely in the data =
plane.</FONT></SPAN></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2></FONT><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT><FONT=20
  face=3DArial color=3D#0000ff size=3D2></FONT><BR></DIV>
  <BLOCKQUOTE=20
  style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
    <BLOCKQUOTE type=3D"cite"><SPAN class=3DApple-style-span=20
      style=3D"WORD-SPACING: 0px; FONT: 13px Helvetica; TEXT-TRANSFORM: =
none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; =
LETTER-SPACING: normal; BORDER-COLLAPSE: separate; orphans: 2; widows: =
2; webkit-border-horizontal-spacing: 0px; =
webkit-border-vertical-spacing: 0px; webkit-text-decorations-in-effect: =
none; webkit-text-size-adjust: auto; webkit-text-stroke-width: 0">
      <DIV class=3DSection1 lang=3DEN-US=20
      style=3D"WORD-WRAP: break-word; webkit-nbsp-mode: space; =
webkit-line-break: after-white-space"=20
      link=3D"blue" vlink=3D"blue">
      <DIV=20
      style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: 'Times =
New Roman'"><SPAN=20
      class=3DApple-style-span=20
      style=3D"FONT-SIZE: 13px; COLOR: rgb(20,79,174); =
webkit-text-stroke-width: -1">If=20
      yes do you agree with the fact that could be useful in general to =
use the=20
      same signaling &#8216;session&#8217; to set-up the LSP and to =
enable the=20
      CFM?</SPAN></DIV></DIV></SPAN></BLOCKQUOTE>
    <DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT><FONT =
face=3DArial=20
    color=3D#0000ff size=3D2></FONT><FONT face=3DArial color=3D#0000ff=20
    size=3D2></FONT><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT><FONT face=3DArial=20
    color=3D#0000ff size=3D2></FONT><FONT face=3DArial color=3D#0000ff=20
    size=3D2></FONT><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT><BR=20
    class=3Dwebkit-block-placeholder></DIV>
    <DIV><SPAN class=3DApple-tab-span style=3D"WHITE-SPACE: =
pre"></SPAN>No, I do not=20
    agree. &nbsp;Again, if CFM is to be set-up e2e, let the IEEE define =
this.=20
    Leave GMPLS to CCAMP.</DIV><FONT face=3DArial color=3D#0000ff=20
    size=3D2></FONT><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT><FONT face=3DArial=20
    color=3D#0000ff size=3D2></FONT><FONT face=3DArial color=3D#0000ff=20
  size=3D2></FONT></BLOCKQUOTE>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D993515301-05122007></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D993515301-05122007></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D993515301-05122007>Sorry, I cannot follow.</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT>&nbsp;</DIV>
  <BLOCKQUOTE=20
  style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
    <DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT>&nbsp;</DIV>
    <DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT>&nbsp;</DIV>
    <DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT><BR=20
    class=3Dwebkit-block-placeholder></DIV>
    <DIV><SPAN class=3DApple-tab-span style=3D"WHITE-SPACE: =
pre"></SPAN>--Tom</DIV>
    <DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT><FONT =
face=3DArial=20
    color=3D#0000ff size=3D2></FONT><FONT face=3DArial color=3D#0000ff=20
    size=3D2></FONT><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT><BR=20
    class=3Dwebkit-block-placeholder></DIV>
    <DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT><FONT =
face=3DArial=20
    color=3D#0000ff size=3D2></FONT><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT><BR=20
    class=3Dwebkit-block-placeholder></DIV>
    <DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT><FONT =
face=3DArial=20
    color=3D#0000ff size=3D2></FONT><FONT face=3DArial color=3D#0000ff=20
size=3D2></FONT><BR>
    <BLOCKQUOTE type=3D"cite"><SPAN class=3DApple-style-span=20
      style=3D"WORD-SPACING: 0px; FONT: 13px Helvetica; TEXT-TRANSFORM: =
none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; =
LETTER-SPACING: normal; BORDER-COLLAPSE: separate; orphans: 2; widows: =
2; webkit-border-horizontal-spacing: 0px; =
webkit-border-vertical-spacing: 0px; webkit-text-decorations-in-effect: =
none; webkit-text-size-adjust: auto; webkit-text-stroke-width: 0">
      <DIV lang=3DEN-US=20
      style=3D"WORD-WRAP: break-word; webkit-nbsp-mode: space; =
webkit-line-break: after-white-space"=20
      link=3D"blue" vlink=3D"blue">
      <DIV class=3DSection1>
      <DIV=20
      style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: 'Times =
New Roman'"><FONT=20
      face=3DArial color=3Dnavy size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><O:P>&nbsp;<SPAN=20
      class=3DApple-style-span=20
      style=3D"COLOR: rgb(20,79,174); webkit-text-stroke-width: -1">Best =

      Regards</SPAN></O:P></SPAN></FONT></DIV>
      <DIV=20
      style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: 'Times =
New Roman'"><FONT=20
      face=3DArial color=3Dnavy size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><BR>Diego<O:P></O:P></SPAN></FONT></DIV>
      <DIV=20
      style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: 'Times =
New Roman'"><FONT=20
      face=3DArial color=3Dnavy size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><O:P></O:P></SPAN></FONT></DIV>
      <DIV=20
      style=3D"PADDING-RIGHT: 0cm; PADDING-LEFT: 4pt; PADDING-BOTTOM: =
0cm; BORDER-LEFT: blue 1.5pt solid; BORDER-TOP-STYLE: none; PADDING-TOP: =
0cm; BORDER-RIGHT-STYLE: none; BORDER-BOTTOM-STYLE: none">
      <DIV>
      <DIV class=3DMsoNormal=20
      style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: 'Times =
New Roman'; TEXT-ALIGN: center"=20
      align=3Dcenter><FONT face=3D"Times New Roman" size=3D3><SPAN=20
      style=3D"FONT-SIZE: 12pt">
      <HR tabIndex=3D-1 align=3Dcenter width=3D"100%" SIZE=3D2>
      </SPAN></FONT></DIV>
      <DIV=20
      style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: 'Times =
New Roman'"><B><FONT=20
      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=20
      style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Tahoma"><SPAN=20
      class=3DApple-converted-space>&nbsp;</SPAN><A=20
      =
href=3D"mailto:[email-masked]">[email-masked]</A> =
[<A=20
      style=3D"COLOR: blue; TEXT-DECORATION: underline"=20
      =
href=3D"mailto:[email-masked]">mailto:[email-masked]<=
/A>]<SPAN=20
      class=3DApple-converted-space>&nbsp;</SPAN><B><SPAN=20
      style=3D"FONT-WEIGHT: bold">On Behalf Of<SPAN=20
      class=3DApple-converted-space>&nbsp;</SPAN></SPAN></B>Thomas=20
      Nadeau<BR><B><SPAN style=3D"FONT-WEIGHT: =
bold">Sent:</SPAN></B><SPAN=20
      class=3DApple-converted-space>&nbsp;</SPAN>marted=EC 4 dicembre =
2007=20
      11.30<BR><B><SPAN style=3D"FONT-WEIGHT: bold">To:</SPAN></B><SPAN=20
      class=3DApple-converted-space>&nbsp;</SPAN>Attila =
Takacs<BR><B><SPAN=20
      style=3D"FONT-WEIGHT: bold">Cc:</SPAN></B><SPAN=20
      class=3DApple-converted-space>&nbsp;</SPAN><A=20
      style=3D"COLOR: blue; TEXT-DECORATION: underline"=20
      href=3D"mailto:[email-masked]">[email-masked]</A>;<SPAN=20
      class=3DApple-converted-space>&nbsp;</SPAN><A=20
      style=3D"COLOR: blue; TEXT-DECORATION: underline"=20
      =
href=3D"mailto:[email-masked]">[email-masked]</A><BR>=
<B><SPAN=20
      style=3D"FONT-WEIGHT: bold">Subject:</SPAN></B><SPAN=20
      class=3DApple-converted-space>&nbsp;</SPAN>Re:=20
      =
draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt</SPAN></FONT><O:P></O:P></D=
IV></DIV>
      <DIV=20
      style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: 'Times =
New Roman'"><FONT=20
      face=3D"Times New Roman" size=3D3><SPAN=20
      style=3D"FONT-SIZE: 12pt"><O:P></O:P></SPAN></FONT></DIV>
      <DIV=20
      style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: 'Times =
New Roman'"><FONT=20
      face=3D"Times New Roman" size=3D3><SPAN=20
      style=3D"FONT-SIZE: 12pt"><O:P></O:P></SPAN></FONT></DIV>
      <DIV>
      <DIV>
      <DIV=20
      style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: 'Times =
New Roman'"><FONT=20
      face=3D"Times New Roman" size=3D3><SPAN style=3D"FONT-SIZE: =
12pt">On Dec 4,=20
      2007, at 1:51 PM, Attila Takacs=20
wrote:<O:P></O:P></SPAN></FONT></DIV></DIV>
      <DIV=20
      style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: 'Times =
New Roman'"><FONT=20
      face=3D"Times New Roman" size=3D3><SPAN=20
      style=3D"FONT-SIZE: 12pt"><BR><BR><O:P></O:P></SPAN></FONT></DIV>
      <DIV style=3D"WORD-WRAP: break-word">
      <DIV>
      <DIV=20
      style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: 'Times =
New Roman'"><FONT=20
      face=3DArial color=3Dblue size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Hi=20
      Thomas,</SPAN></FONT><O:P></O:P></DIV></DIV>
      <DIV>
      <DIV=20
      style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: 'Times =
New Roman'"><FONT=20
      face=3D"Times New Roman" size=3D3><SPAN=20
      style=3D"FONT-SIZE: 12pt"><O:P></O:P></SPAN></FONT></DIV></DIV>
      <DIV>
      <DIV=20
      style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: 'Times =
New Roman'"><FONT=20
      face=3DArial color=3Dblue size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Thank=20
      you&nbsp;for the comments!</SPAN></FONT><O:P></O:P></DIV></DIV>
      <DIV>
      <DIV=20
      style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: 'Times =
New Roman'"><FONT=20
      face=3DArial color=3Dblue size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Please =
see=20
      answers inline.</SPAN></FONT><O:P></O:P></DIV></DIV>
      <DIV>
      <DIV=20
      style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: 'Times =
New Roman'"><FONT=20
      face=3D"Times New Roman" size=3D3><SPAN=20
      style=3D"FONT-SIZE: 12pt"><O:P></O:P></SPAN></FONT></DIV></DIV>
      <DIV>
      <DIV=20
      style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: 'Times =
New Roman'"><FONT=20
      face=3DArial color=3Dblue size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Best=20
      regards,<BR>Attila</SPAN></FONT><O:P></O:P></DIV></DIV>
      <BLOCKQUOTE=20
      style=3D"PADDING-RIGHT: 0cm; PADDING-LEFT: 4pt; PADDING-BOTTOM: =
0cm; MARGIN: 5pt 0cm 5pt 3.75pt; BORDER-LEFT: blue 1.5pt solid; =
BORDER-TOP-STYLE: none; PADDING-TOP: 0cm; BORDER-RIGHT-STYLE: none; =
BORDER-BOTTOM-STYLE: none">
        <DIV=20
        style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: =
'Times New Roman'"><FONT=20
        face=3D"Times New Roman" size=3D3><SPAN=20
        style=3D"FONT-SIZE: 12pt"><O:P></O:P></SPAN></FONT></DIV>
        <DIV class=3DMsoNormal=20
        style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: =
'Times New Roman'; TEXT-ALIGN: center"=20
        align=3Dcenter><FONT face=3D"Times New Roman" size=3D3><SPAN=20
        style=3D"FONT-SIZE: 12pt">
        <HR tabIndex=3D-1 align=3Dcenter width=3D"100%" SIZE=3D2>
        </SPAN></FONT></DIV>
        <DIV=20
        style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: =
'Times New Roman'"><B><FONT=20
        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=20
        style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Tahoma"><SPAN=20
        class=3DApple-converted-space>&nbsp;</SPAN>Thomas Nadeau [<A=20
        style=3D"COLOR: blue; TEXT-DECORATION: underline"=20
        =
href=3D"mailto:[email-masked]">mailto:[email-masked]</A=
>]<SPAN=20
        class=3DApple-converted-space>&nbsp;</SPAN><BR><B><SPAN=20
        style=3D"FONT-WEIGHT: bold">Sent:</SPAN></B><SPAN=20
        class=3DApple-converted-space>&nbsp;</SPAN>Tuesday, December 04, =
2007 2:58=20
        PM<BR><B><SPAN style=3D"FONT-WEIGHT: bold">To:</SPAN></B><SPAN=20
        class=3DApple-converted-space>&nbsp;</SPAN><A=20
        style=3D"COLOR: blue; TEXT-DECORATION: underline"=20
        =
href=3D"mailto:[email-masked]">[email-masked]</A><BR><B><SPAN=20
        style=3D"FONT-WEIGHT: bold">Cc:</SPAN></B><SPAN=20
        class=3DApple-converted-space>&nbsp;</SPAN>Attila Takacs;<SPAN=20
        class=3DApple-converted-space>&nbsp;</SPAN><A=20
        style=3D"COLOR: blue; TEXT-DECORATION: underline"=20
        =
href=3D"mailto:[email-masked]">[email-masked]</A><BR>=
<B><SPAN=20
        style=3D"FONT-WEIGHT: bold">Subject:</SPAN></B><SPAN=20
        =
class=3DApple-converted-space>&nbsp;</SPAN>draft-takacs-ccamp-rsvp-te-eth=
-oam-ext-00.txt</SPAN></FONT><O:P></O:P></DIV>
        <DIV=20
        style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: =
'Times New Roman'"><FONT=20
        face=3D"Times New Roman" size=3D3><SPAN=20
        style=3D"FONT-SIZE: 12pt"><O:P></O:P></SPAN></FONT></DIV>
        <DIV>
        <DIV=20
        style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: =
'Times New Roman'"><FONT=20
        face=3D"Times New Roman" size=3D3><SPAN=20
        style=3D"FONT-SIZE: 12pt"><O:P></O:P></SPAN></FONT></DIV></DIV>
        <DIV>
        <DIV=20
        style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: =
'Times New Roman'"><FONT=20
        face=3D"Times New Roman" size=3D3><SPAN style=3D"FONT-SIZE: =
12pt">After=20
        reading this draft, I have some=20
        questions/comments.<O:P></O:P></SPAN></FONT></DIV></DIV>
        <DIV>
        <DIV=20
        style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: =
'Times New Roman'"><FONT=20
        face=3D"Times New Roman" size=3D3><SPAN=20
        style=3D"FONT-SIZE: 12pt"><O:P></O:P></SPAN></FONT></DIV></DIV>
        <DIV>
        <DIV=20
        style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: =
'Times New Roman'"><FONT=20
        face=3D"Times New Roman" size=3D3><SPAN style=3D"FONT-SIZE: =
12pt">1)=20
        Overall,&nbsp;I am concerned that the definition of a new TLV =
and these=20
        procedures represent&nbsp;<O:P></O:P></SPAN></FONT></DIV></DIV>
        <DIV>
        <DIV=20
        style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: =
'Times New Roman'"><FONT=20
        face=3D"Times New Roman" size=3D3><SPAN style=3D"FONT-SIZE: =
12pt">what amounts=20
        to a laying violation and ask that the ADs take a look at=20
        this<O:P></O:P></SPAN></FONT></DIV></DIV>
        <DIV>
        <DIV=20
        style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: =
'Times New Roman'"><FONT=20
        face=3D"Times New Roman" size=3D3><SPAN style=3D"FONT-SIZE: =
12pt">approach=20
        closely. This is similar to the now-rejected approach that was=20
        proposed<O:P></O:P></SPAN></FONT></DIV></DIV>
        <DIV>
        <DIV=20
        style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: =
'Times New Roman'"><FONT=20
        face=3D"Times New Roman" size=3D3><SPAN style=3D"FONT-SIZE: =
12pt">in the l2vpn=20
        WG about munging CFM + PWs. &nbsp;To my reading, this is=20
        essentially<O:P></O:P></SPAN></FONT></DIV></DIV>
        <DIV>
        <DIV=20
        style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: =
'Times New Roman'"><FONT=20
        face=3D"Times New Roman" size=3D3><SPAN style=3D"FONT-SIZE: =
12pt">the same=20
        thing. If you want to run CFM, run it natively over the ethernet =

        interfaces and<O:P></O:P></SPAN></FONT></DIV></DIV>
        <DIV>
        <DIV=20
        style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: =
'Times New Roman'"><FONT=20
        face=3D"Times New Roman" size=3D3><SPAN style=3D"FONT-SIZE: =
12pt">have no=20
        regard for the underlying topology (GMPLS, PWs, etc...) =
otherwise=20
        you&nbsp;<O:P></O:P></SPAN></FONT></DIV></DIV>
        <DIV>
        <DIV=20
        style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: =
'Times New Roman'"><FONT=20
        face=3D"Times New Roman" size=3D3><SPAN style=3D"FONT-SIZE: =
12pt">will be=20
        creating a mess for implementations and=20
        interoperability.&nbsp;</SPAN></FONT><FONT face=3DArial =
color=3Dblue=20
        size=3D2><SPAN=20
        style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
Arial">&nbsp;</SPAN></FONT><O:P></O:P></DIV></DIV></BLOCKQUOTE>
      <DIV>
      <DIV=20
      style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: 'Times =
New Roman'"><FONT=20
      face=3DArial color=3Dblue size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">The=20
      application&nbsp;of the draft is exactly for what you are calling =
out:=20
      when CFM is run natively over the Ethernet interfaces. The =
document=20
      focuses on GELS and Ethernet LSPs.&nbsp;That is,&nbsp;to establish =
CFM=20
      entities for GMPLS controlled Ethernet LSPs.&nbsp;Hence, I think =
there is=20
      no layer violation =
issue.</SPAN></FONT><O:P></O:P></DIV></DIV></DIV>
      <DIV>
      <DIV=20
      style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: 'Times =
New Roman'"><FONT=20
      face=3D"Times New Roman" size=3D3><SPAN=20
      style=3D"FONT-SIZE: 12pt"><O:P></O:P></SPAN></FONT></DIV></DIV>
      <DIV=20
      style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: 'Times =
New Roman'"><SPAN=20
      class=3Dapple-tab-span><FONT face=3D"Times New Roman" =
size=3D3><SPAN=20
      style=3D"FONT-SIZE: =
12pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<SPAN=20
      =
class=3DApple-converted-space>&nbsp;</SPAN></SPAN></FONT></SPAN>This=20
      solution specifically only works for GMPLS ethernet LSPs, right?=20
      &nbsp;<O:P></O:P></DIV></DIV>
      <DIV>
      <DIV=20
      style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: 'Times =
New Roman'"><FONT=20
      face=3D"Times New Roman" size=3D3><SPAN style=3D"FONT-SIZE: =
12pt">What do I do=20
      if I want to set up MPLS ethernet LSPs (i.e.: PWs)&nbsp;and do CFM =
over=20
      those? Oh,<O:P></O:P></SPAN></FONT></DIV></DIV>
      <DIV>
      <DIV=20
      style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: 'Times =
New Roman'"><FONT=20
      face=3D"Times New Roman" size=3D3><SPAN style=3D"FONT-SIZE: =
12pt">that is a=20
      different solution, right? &nbsp;Then what do I do if I want to =
run CFM=20
      over some new type of<O:P></O:P></SPAN></FONT></DIV></DIV>
      <DIV>
      <DIV=20
      style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: 'Times =
New Roman'"><FONT=20
      face=3D"Times New Roman" size=3D3><SPAN style=3D"FONT-SIZE: =
12pt">ethernet LSP=20
      in the future? More protocol hacks? &nbsp;The point is to use CFM =
over an=20
      ethernet interface<O:P></O:P></SPAN></FONT></DIV></DIV>
      <DIV>
      <DIV=20
      style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: 'Times =
New Roman'"><FONT=20
      face=3D"Times New Roman" size=3D3><SPAN style=3D"FONT-SIZE: =
12pt">without the=20
      underlying layers knowing. This is good networking architecture =
design,=20
      that simplifies<O:P></O:P></SPAN></FONT></DIV></DIV>
      <DIV>
      <DIV=20
      style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: 'Times =
New Roman'"><FONT=20
      face=3D"Times New Roman" size=3D3><SPAN=20
      style=3D"FONT-SIZE: 12pt">implementations and makes them more =
robust, as=20
      well as makes using them operationally=20
      much<O:P></O:P></SPAN></FONT></DIV></DIV>
      <DIV>
      <DIV=20
      style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: 'Times =
New Roman'"><FONT=20
      face=3D"Times New Roman" size=3D3><SPAN=20
      style=3D"FONT-SIZE: =
12pt">easier.&nbsp;<O:P></O:P></SPAN></FONT></DIV></DIV>
      <DIV>
      <BLOCKQUOTE style=3D"MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt" =
type=3D"cite">
        <DIV style=3D"WORD-WRAP: break-word">
        <BLOCKQUOTE=20
        style=3D"PADDING-RIGHT: 0cm; PADDING-LEFT: 4pt; PADDING-BOTTOM: =
0cm; MARGIN: 5pt 0cm 5pt 3.75pt; BORDER-LEFT: blue 1.5pt solid; =
BORDER-TOP-STYLE: none; PADDING-TOP: 0cm; BORDER-RIGHT-STYLE: none; =
BORDER-BOTTOM-STYLE: none">
          <DIV>
          <DIV=20
          style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: =
'Times New Roman'"><FONT=20
          face=3D"Times New Roman" size=3D3><SPAN=20
          style=3D"FONT-SIZE: 12pt">2)&nbsp;The introductory sections in =
this=20
          draft give a lot of discussion about fast fault detection.=20
          I<O:P></O:P></SPAN></FONT></DIV></DIV>
          <DIV>
          <DIV=20
          style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: =
'Times New Roman'"><FONT=20
          face=3D"Times New Roman" size=3D3><SPAN style=3D"FONT-SIZE: =
12pt">am puzzled=20
          by this given that GMPLS networks tend to run over quickly=20
          self-healing<O:P></O:P></SPAN></FONT></DIV></DIV>
          <DIV>
          <DIV=20
          style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: =
'Times New Roman'"><FONT=20
          face=3D"Times New Roman" size=3D3><SPAN style=3D"FONT-SIZE: =
12pt">optical=20
          infrastructures. Is it therefore&nbsp;truly&nbsp;necessary to =
motivate=20
          this work by<O:P></O:P></SPAN></FONT></DIV></DIV>
          <DIV>
          <DIV=20
          style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: =
'Times New Roman'"><FONT=20
          face=3D"Times New Roman" size=3D3><SPAN style=3D"FONT-SIZE: =
12pt">requiring=20
          fast CFMs?<O:P></O:P></SPAN></FONT></DIV></DIV></BLOCKQUOTE>
        <DIV>
        <DIV=20
        style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: =
'Times New Roman'"><FONT=20
        face=3DArial color=3Dblue size=3D2><SPAN=20
        style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">It is =
right=20
        that frequent CCMs are not required if the layers below Ethernet =
handle=20
        protection. However, the ID focuses on Ethernet LSPs where =
Ethernet=20
        is&nbsp;not just a single hop&nbsp;above a transport =
LSP.&nbsp;In this=20
        case&nbsp;Ethernet layer (for clarity GELS) may provide =
protection for=20
        Ethernet LSPs.&nbsp;In any case,&nbsp; the whole point of the ID =
is to=20
        allow for the appropriate configuration of CFM for Ethernet LSPs =
with=20
        GMPLS.</SPAN></FONT><O:P></O:P></DIV></DIV>
        <DIV>
        <DIV=20
        style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: =
'Times New Roman'"><FONT=20
        face=3D"Times New Roman" size=3D3><SPAN=20
        style=3D"FONT-SIZE: 12pt"><O:P></O:P></SPAN></FONT></DIV></DIV>
        <BLOCKQUOTE=20
        style=3D"PADDING-RIGHT: 0cm; PADDING-LEFT: 4pt; PADDING-BOTTOM: =
0cm; MARGIN: 5pt 0cm 5pt 3.75pt; BORDER-LEFT: blue 1.5pt solid; =
BORDER-TOP-STYLE: none; PADDING-TOP: 0cm; BORDER-RIGHT-STYLE: none; =
BORDER-BOTTOM-STYLE: none">
          <DIV>
          <DIV=20
          style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: =
'Times New Roman'"><FONT=20
          face=3D"Times New Roman" size=3D3><SPAN style=3D"FONT-SIZE: =
12pt">3) This=20
          document does not cover E-LMI. Why=20
          not?<O:P></O:P></SPAN></FONT></DIV></DIV></BLOCKQUOTE>
        <DIV>
        <DIV=20
        style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: =
'Times New Roman'"><FONT=20
        face=3DArial color=3Dblue size=3D2><SPAN=20
        style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">E-LMI =
is run=20
        over the MEF UNI. The&nbsp;ID focuses on Ethernet LSPs within a=20
        network.</SPAN></FONT><O:P></O:P></DIV></DIV>
        <DIV>
        <DIV=20
        style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: =
'Times New Roman'"><FONT=20
        face=3D"Times New Roman" size=3D3><SPAN=20
        style=3D"FONT-SIZE: 12pt"><O:P></O:P></SPAN></FONT></DIV></DIV>
        <DIV>
        <DIV=20
        style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: =
'Times New Roman'"><FONT=20
        face=3D"Times New Roman" size=3D3><SPAN=20
        style=3D"FONT-SIZE: 12pt"><O:P></O:P></SPAN></FONT></DIV></DIV>
        <BLOCKQUOTE=20
        style=3D"PADDING-RIGHT: 0cm; PADDING-LEFT: 4pt; PADDING-BOTTOM: =
0cm; MARGIN: 5pt 0cm 5pt 3.75pt; BORDER-LEFT: blue 1.5pt solid; =
BORDER-TOP-STYLE: none; PADDING-TOP: 0cm; BORDER-RIGHT-STYLE: none; =
BORDER-BOTTOM-STYLE: none">
          <DIV>
          <DIV=20
          style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: =
'Times New Roman'"><SPAN=20
          class=3Dapple-style-span><FONT face=3D"Times New Roman" =
size=3D1><SPAN=20
          style=3D"FONT-SIZE: 9pt">For the purposes of this document, we =
only=20
          discuss Ethernet =
OAM</SPAN></FONT></SPAN><O:P></O:P></DIV></DIV>
          <DIV>
          <DIV=20
          style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: =
'Times New Roman'"><FONT=20
          face=3DHelvetica size=3D1><SPAN=20
          style=3D"FONT-SIZE: 9pt; FONT-FAMILY: Helvetica">&nbsp;&nbsp; =
[IEEE-CFM]=20
          aspects that are relevant for the connectivity=20
          monitoring<O:P></O:P></SPAN></FONT></DIV></DIV>
          <DIV>
          <DIV=20
          style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: =
'Times New Roman'"><FONT=20
          face=3DHelvetica size=3D1><SPAN=20
          style=3D"FONT-SIZE: 9pt; FONT-FAMILY: Helvetica">&nbsp;&nbsp; =
of=20
          bidirectional point-to-point PBB-TE connections.=20
          &nbsp;<O:P></O:P></SPAN></FONT></DIV></DIV>
          <DIV>
          <DIV=20
          style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: =
'Times New Roman'"><FONT=20
          face=3DHelvetica size=3D1><SPAN=20
          style=3D"FONT-SIZE: 9pt; FONT-FAMILY: =
Helvetica"><O:P></O:P></SPAN></FONT></DIV></DIV>
          <DIV>
          <DIV=20
          style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: =
'Times New Roman'"><FONT=20
          face=3DHelvetica size=3D1><SPAN=20
          style=3D"FONT-SIZE: 9pt; FONT-FAMILY: Helvetica">4) Is this =
the right=20
          place to define this document or should this be done in=20
          GELS?<O:P></O:P></SPAN></FONT></DIV></DIV></BLOCKQUOTE>
        <DIV>
        <DIV=20
        style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: =
'Times New Roman'"><FONT=20
        face=3DArial color=3Dblue size=3D2><SPAN=20
        style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Well, =
GELS is=20
        done in CCAMP...this seems to be the right=20
        place.</SPAN></FONT><O:P></O:P></DIV></DIV>
        <BLOCKQUOTE=20
        style=3D"PADDING-RIGHT: 0cm; PADDING-LEFT: 4pt; PADDING-BOTTOM: =
0cm; MARGIN: 5pt 0cm 5pt 3.75pt; BORDER-LEFT: blue 1.5pt solid; =
BORDER-TOP-STYLE: none; PADDING-TOP: 0cm; BORDER-RIGHT-STYLE: none; =
BORDER-BOTTOM-STYLE: none">
          <DIV>
          <DIV=20
          style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: =
'Times New Roman'"><FONT=20
          face=3D"Times New Roman" size=3D3><SPAN=20
          style=3D"FONT-SIZE: =
12pt"><O:P></O:P></SPAN></FONT></DIV></DIV>
          <DIV>
          <DIV=20
          style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: =
'Times New Roman'"><FONT=20
          face=3DHelvetica size=3D1><SPAN=20
          style=3D"FONT-SIZE: 9pt; FONT-FAMILY: =
Helvetica"><O:P></O:P></SPAN></FONT></DIV></DIV>
          <DIV>
          <DIV=20
          style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: =
'Times New Roman'"><FONT=20
          face=3DHelvetica size=3D1><SPAN=20
          style=3D"FONT-SIZE: 9pt; FONT-FAMILY: Helvetica">5) &nbsp; In =
section 2=20
          you make the following =
statement:<O:P></O:P></SPAN></FONT></DIV></DIV>
          <DIV>
          <DIV=20
          style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: =
'Times New Roman'"><FONT=20
          face=3DHelvetica size=3D1><SPAN=20
          style=3D"FONT-SIZE: 9pt; FONT-FAMILY: =
Helvetica"><O:P></O:P></SPAN></FONT></DIV></DIV>
          <DIV>
          <DIV=20
          style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: =
'Times New Roman'"><FONT=20
          face=3DHelvetica size=3D1><SPAN=20
          style=3D"FONT-SIZE: 9pt; FONT-FAMILY: Helvetica">2.&nbsp; =
GMPLS RSVP-TE=20
          Extensions<O:P></O:P></SPAN></FONT></DIV></DIV>
          <DIV style=3D"MIN-HEIGHT: 14px">
          <DIV=20
          style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: =
'Times New Roman'"><FONT=20
          face=3DHelvetica size=3D1><SPAN=20
          style=3D"FONT-SIZE: 9pt; FONT-FAMILY: =
Helvetica"><O:P></O:P></SPAN></FONT></DIV></DIV>
          <DIV>
          <DIV=20
          style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: =
'Times New Roman'"><FONT=20
          face=3DHelvetica size=3D1><SPAN=20
          style=3D"FONT-SIZE: 9pt; FONT-FAMILY: Helvetica">&nbsp;<SPAN=20
          class=3Dapple-tab-span><SPAN=20
          class=3DApple-converted-space>&nbsp;</SPAN></SPAN>&nbsp; To =
simplify the=20
          configuration of connectivity monitoring, when=20
          an<O:P></O:P></SPAN></FONT></DIV></DIV>
          <DIV>
          <DIV=20
          style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: =
'Times New Roman'"><FONT=20
          face=3DHelvetica size=3D1><SPAN=20
          style=3D"FONT-SIZE: 9pt; FONT-FAMILY: Helvetica">&nbsp;&nbsp; =
Ethernet=20
          LSP is signalled the associated MEPs should be=20
          automatically<O:P></O:P></SPAN></FONT></DIV></DIV>
          <DIV>
          <DIV=20
          style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: =
'Times New Roman'"><FONT=20
          face=3DHelvetica size=3D1><SPAN=20
          style=3D"FONT-SIZE: 9pt; FONT-FAMILY: Helvetica">&nbsp;<SPAN=20
          class=3Dapple-tab-span><SPAN=20
          class=3DApple-converted-space>&nbsp;</SPAN></SPAN>&nbsp;=20
          established.&nbsp; Further more, GMPLS signalling should be =
able=20
          to<O:P></O:P></SPAN></FONT></DIV></DIV>
          <DIV>
          <DIV=20
          style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: =
'Times New Roman'"><FONT=20
          face=3DHelvetica size=3D1><SPAN=20
          style=3D"FONT-SIZE: 9pt; FONT-FAMILY: =
Helvetica">&nbsp;&nbsp;enable/disable=20
          connectivity monitoring of a particular Ethernet=20
          LSP.<O:P></O:P></SPAN></FONT></DIV></DIV>
          <DIV>
          <DIV=20
          style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: =
'Times New Roman'"><FONT=20
          face=3DHelvetica size=3D1><SPAN=20
          style=3D"FONT-SIZE: 9pt; FONT-FAMILY: =
Helvetica"><O:P></O:P></SPAN></FONT></DIV></DIV>
          <DIV>
          <DIV=20
          style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: =
'Times New Roman'"><FONT=20
          face=3DHelvetica size=3D1><SPAN=20
          style=3D"FONT-SIZE: 9pt; FONT-FAMILY: =
Helvetica"><O:P></O:P></SPAN></FONT></DIV></DIV>
          <DIV>
          <DIV=20
          style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: =
'Times New Roman'"><FONT=20
          face=3DHelvetica size=3D1><SPAN=20
          style=3D"FONT-SIZE: 9pt; FONT-FAMILY: Helvetica">To my point =
in #1=20
          above, you should use the native CFM functionality over the =
ethernet=20
          interface and signal<O:P></O:P></SPAN></FONT></DIV></DIV>
          <DIV>
          <DIV=20
          style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: =
'Times New Roman'"><FONT=20
          face=3DHelvetica size=3D1><SPAN=20
          style=3D"FONT-SIZE: 9pt; FONT-FAMILY: Helvetica">those =
capabilities to=20
          the bridges at both ends using the IEEE CFM signaling =
procedures (when=20
          and if they<O:P></O:P></SPAN></FONT></DIV></DIV>
          <DIV>
          <DIV=20
          style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: =
'Times New Roman'"><FONT=20
          face=3DHelvetica size=3D1><SPAN=20
          style=3D"FONT-SIZE: 9pt; FONT-FAMILY: Helvetica">are created). =
&nbsp;If=20
          you want to test the underlying GMPLS LSP(s), then you should =
use=20
          some<O:P></O:P></SPAN></FONT></DIV></DIV>
          <DIV>
          <DIV=20
          style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: =
'Times New Roman'"><FONT=20
          face=3DHelvetica size=3D1><SPAN=20
          style=3D"FONT-SIZE: 9pt; FONT-FAMILY: Helvetica">other =
mechanism defined=20
          for that layer such as the work stated =
in&nbsp;</SPAN></FONT><SPAN=20
          class=3Dapple-style-span><B><FONT face=3DHelvetica =
size=3D2><SPAN=20
          style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: =
Helvetica">draft-ali-ccamp-gmpls-LSP-ping-traceroute-00.txt</SPAN></FONT>=
</B></SPAN><FONT=20
          face=3DHelvetica size=3D1><SPAN=20
          style=3D"FONT-SIZE: 9pt; FONT-FAMILY: =
Helvetica"><O:P></O:P></SPAN></FONT></DIV></DIV></BLOCKQUOTE>
        <DIV>
        <DIV=20
        style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: =
'Times New Roman'"><FONT=20
        face=3DArial color=3Dblue size=3D2><SPAN=20
        style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">See =
the=20
        note&nbsp;to your point #1. There is no relation&nbsp;to the=20
        gmpls-LSP-ping draft.&nbsp;</SPAN></FONT><FONT face=3DHelvetica=20
        size=3D1><SPAN=20
        style=3D"FONT-SIZE: 9pt; FONT-FAMILY: =
Helvetica"><O:P></O:P></SPAN></FONT></DIV></DIV></DIV></BLOCKQUOTE>
      <DIV>
      <DIV=20
      style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: 'Times =
New Roman'"><FONT=20
      face=3D"Times New Roman" size=3D3><SPAN=20
      style=3D"FONT-SIZE: 12pt"><O:P></O:P></SPAN></FONT></DIV></DIV>
      <DIV=20
      style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: 'Times =
New Roman'"><SPAN=20
      class=3Dapple-tab-span><FONT face=3D"Times New Roman" =
size=3D3><SPAN=20
      style=3D"FONT-SIZE: =
12pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<SPAN=20
      =
class=3DApple-converted-space>&nbsp;</SPAN></SPAN></FONT></SPAN>The =
point I=20
      am making is that perhaps it should.<O:P></O:P></DIV></DIV>
      <DIV>
      <DIV=20
      style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: 'Times =
New Roman'"><FONT=20
      face=3D"Times New Roman" size=3D3><SPAN=20
      style=3D"FONT-SIZE: 12pt"><O:P></O:P></SPAN></FONT></DIV></DIV>
      <DIV>
      <DIV=20
      style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: 'Times =
New Roman'"><SPAN=20
      class=3Dapple-tab-span><FONT face=3D"Times New Roman" =
size=3D3><SPAN=20
      style=3D"FONT-SIZE: =
12pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<SPAN=20
      =
class=3DApple-converted-space>&nbsp;</SPAN></SPAN></FONT></SPAN>--Tom<O:P=
></O:P></DIV></DIV>
      <DIV>
      <DIV=20
      style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: 'Times =
New Roman'"><FONT=20
      face=3D"Times New Roman" size=3D3><SPAN=20
      style=3D"FONT-SIZE: 12pt"><O:P></O:P></SPAN></FONT></DIV></DIV>
      <DIV>
      <DIV=20
      style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: 'Times =
New Roman'"><FONT=20
      face=3D"Times New Roman" size=3D3><SPAN=20
      style=3D"FONT-SIZE: 12pt"><O:P></O:P></SPAN></FONT></DIV></DIV>
      <DIV>
      <BLOCKQUOTE style=3D"MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt" =
type=3D"cite">
        <DIV style=3D"WORD-WRAP: break-word">
        <DIV>
        <DIV=20
        style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: =
'Times New Roman'"><FONT=20
        face=3DHelvetica size=3D1><SPAN=20
        style=3D"FONT-SIZE: 9pt; FONT-FAMILY: =
Helvetica"><O:P></O:P></SPAN></FONT></DIV></DIV>
        <DIV>
        <DIV=20
        style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: =
'Times New Roman'"><FONT=20
        face=3DHelvetica size=3D1><SPAN=20
        style=3D"FONT-SIZE: 9pt; FONT-FAMILY: =
Helvetica"><O:P></O:P></SPAN></FONT></DIV></DIV>
        <DIV>
        <DIV=20
        style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: =
'Times New Roman'"><FONT=20
        face=3DHelvetica size=3D1><SPAN=20
        style=3D"FONT-SIZE: 9pt; FONT-FAMILY: =
Helvetica"><O:P></O:P></SPAN></FONT></DIV></DIV></DIV></BLOCKQUOTE></DIV>=

      <DIV=20
      style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: 'Times =
New Roman'"><FONT=20
      face=3D"Times New Roman" size=3D3><SPAN=20
      style=3D"FONT-SIZE: =
12pt"><O:P></O:P></SPAN></FONT></DIV></DIV></DIV></DIV></SPAN></BLOCKQUOT=
E></DIV><BR></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C8370C.22930EF6--

Delivery-date: Wed, 05 Dec 2007 02:04:43 +0000
Content-class: urn:content-classes:message
Subject: RE: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt
Date: Wed, 5 Dec 2007 03:03:26 +0100
From: "Attila Takacs" <[email-masked]>
To: "Thomas Nadeau" <[email-masked]>, "Diego Caviglia" <[email-masked]>
Cc: <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C836E3.05B15F17
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Tom,
please see inline.
Best regards,
Attila

________________________________

	From: Thomas Nadeau [mailto:[email-masked]]=20
	Sent: Wednesday, December 05, 2007 2:19 AM
	To: Diego Caviglia
	Cc: Attila Takacs; [email-masked]; [email-masked]
	Subject: Re: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt
=09
=09
=09
=09
	On Dec 4, 2007, at 7:33 PM, Diego Caviglia wrote:

	=09
		Hi Thomas,
		                 My understanding of the ID was that RSVP-TE can be =
used to 'piggyback' CFM set-up, otherwise the scenario is: usage of =
RSVP-TE to set-up the LSP and NMS (meaning everything that is not =
control plane) to enable to CFM for the LSP.

=09
=09
	As I understand it, the IEEE is working on set-up of CFM (and MEPs), as =
are some vendors I know. *)
	This to me seems like the right way to do this.
	=20

IEEE specified CFM and MIBs to setup CFM.=20
Diego's summary is correct: one can use an NMS or a control plane to =
setup the data plane. In this case we propose to use GMPLS to setup the =
data plane: both forwarding + OAM.

	=09
	=09
		From your comment I see that you're not happy with the fact the ID is =
so technology specific am I right? =20

=09
=09
	Precisely; its gluing CFM to RSVP-TE/GMPLS as a transport.=20
=09
=09

I do not see your point with gluing. What do you mean by "as transport"? =
GMPLS is just controlling OAM, CFM is run solely in the data plane.
=20

	=09
		If yes do you agree with the fact that could be useful in general to =
use the same signaling 'session' to set-up the LSP and to enable the =
CFM?

=09
=09
	No, I do not agree.  Again, if CFM is to be set-up e2e, let the IEEE =
define this. Leave GMPLS to CCAMP.
=09

=20
=20
Sorry, I cannot follow.
=20
=20

	=20
	=20
=09
=09
	--Tom
=09
=09
=09
=09
=09
=09

	=09
		 Best Regards
	=09
		Diego
	=09
	=09
________________________________

		From: [email-masked] [mailto:[email-masked]] On =
Behalf Of Thomas Nadeau
		Sent: marted=EC 4 dicembre 2007 11.30
		To: Attila Takacs
		Cc: [email-masked]; [email-masked]
		Subject: Re: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt
	=09
	=09
		On Dec 4, 2007, at 1:51 PM, Attila Takacs wrote:
	=09
	=09
	=09
		Hi Thomas,
	=09
		Thank you for the comments!
		Please see answers inline.
	=09
		Best regards,
		Attila

		=09
		=09
________________________________

			From: Thomas Nadeau [mailto:[email-masked]]=20
			Sent: Tuesday, December 04, 2007 2:58 PM
			To: [email-masked]
			Cc: Attila Takacs; [email-masked]
			Subject: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt
		=09
		=09
			After reading this draft, I have some questions/comments.
		=09
			1) Overall, I am concerned that the definition of a new TLV and these =
procedures represent=20
			what amounts to a laying violation and ask that the ADs take a look =
at this
			approach closely. This is similar to the now-rejected approach that =
was proposed
			in the l2vpn WG about munging CFM + PWs.  To my reading, this is =
essentially
			the same thing. If you want to run CFM, run it natively over the =
ethernet interfaces and
			have no regard for the underlying topology (GMPLS, PWs, etc...) =
otherwise you=20
			will be creating a mess for implementations and interoperability. =20

		The application of the draft is exactly for what you are calling out: =
when CFM is run natively over the Ethernet interfaces. The document =
focuses on GELS and Ethernet LSPs. That is, to establish CFM entities =
for GMPLS controlled Ethernet LSPs. Hence, I think there is no layer =
violation issue.
	=09
		          This solution specifically only works for GMPLS ethernet =
LSPs, right? =20
		What do I do if I want to set up MPLS ethernet LSPs (i.e.: PWs) and do =
CFM over those? Oh,
		that is a different solution, right?  Then what do I do if I want to =
run CFM over some new type of
		ethernet LSP in the future? More protocol hacks?  The point is to use =
CFM over an ethernet interface
		without the underlying layers knowing. This is good networking =
architecture design, that simplifies
		implementations and makes them more robust, as well as makes using =
them operationally much
		easier.=20

				2) The introductory sections in this draft give a lot of discussion =
about fast fault detection. I
				am puzzled by this given that GMPLS networks tend to run over =
quickly self-healing
				optical infrastructures. Is it therefore truly necessary to motivate =
this work by
				requiring fast CFMs?

			It is right that frequent CCMs are not required if the layers below =
Ethernet handle protection. However, the ID focuses on Ethernet LSPs =
where Ethernet is not just a single hop above a transport LSP. In this =
case Ethernet layer (for clarity GELS) may provide protection for =
Ethernet LSPs. In any case,  the whole point of the ID is to allow for =
the appropriate configuration of CFM for Ethernet LSPs with GMPLS.
		=09

				3) This document does not cover E-LMI. Why not?

			E-LMI is run over the MEF UNI. The ID focuses on Ethernet LSPs within =
a network.
		=09
		=09

				For the purposes of this document, we only discuss Ethernet OAM
				   [IEEE-CFM] aspects that are relevant for the connectivity =
monitoring
				   of bidirectional point-to-point PBB-TE connections. =20
			=09
				4) Is this the right place to define this document or should this be =
done in GELS?

			Well, GELS is done in CCAMP...this seems to be the right place.

			=09
			=09
				5)   In section 2 you make the following statement:
			=09
				2.  GMPLS RSVP-TE Extensions
			=09
				    To simplify the configuration of connectivity monitoring, when =
an
				   Ethernet LSP is signalled the associated MEPs should be =
automatically
				    established.  Further more, GMPLS signalling should be able to
				  enable/disable connectivity monitoring of a particular Ethernet =
LSP.
			=09
			=09
				To my point in #1 above, you should use the native CFM functionality =
over the ethernet interface and signal
				those capabilities to the bridges at both ends using the IEEE CFM =
signaling procedures (when and if they
				are created).  If you want to test the underlying GMPLS LSP(s), then =
you should use some
				other mechanism defined for that layer such as the work stated in =
draft-ali-ccamp-gmpls-LSP-ping-traceroute-00.txt

			See the note to your point #1. There is no relation to the =
gmpls-LSP-ping draft.=20

	=09
		          The point I am making is that perhaps it should.
	=09
		          --Tom
	=09
	=09

		=09
		=09
		=09

	=09

------_=_NextPart_001_01C836E3.05B15F17
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>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1589" name=3DGENERATOR></HEAD>
<BODY=20
style=3D"WORD-WRAP: break-word; webkit-nbsp-mode: space; =
webkit-line-break: after-white-space">
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D993515301-05122007>Hi=20
Tom,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D993515301-05122007>please=20
see inline.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D993515301-05122007>Best=20
regards,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D993515301-05122007>Attila</SPAN></FONT></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> Thomas Nadeau=20
  [mailto:[email-masked]] <BR><B>Sent:</B> Wednesday, December =
05, 2007=20
  2:19 AM<BR><B>To:</B> Diego Caviglia<BR><B>Cc:</B> Attila Takacs;=20
  [email-masked]; [email-masked]<BR><B>Subject:</B> Re:=20
  draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt<BR></FONT><BR></DIV>
  <DIV></DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2></FONT><BR>
  <DIV>
  <DIV>On Dec 4, 2007, at 7:33 PM, Diego Caviglia wrote:</DIV><BR=20
  class=3DApple-interchange-newline>
  <BLOCKQUOTE type=3D"cite"><SPAN class=3DApple-style-span=20
    style=3D"WORD-SPACING: 0px; FONT: 13px Helvetica; TEXT-TRANSFORM: =
none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; =
LETTER-SPACING: normal; BORDER-COLLAPSE: separate; orphans: 2; widows: =
2; webkit-border-horizontal-spacing: 0px; =
webkit-border-vertical-spacing: 0px; webkit-text-decorations-in-effect: =
none; webkit-text-size-adjust: auto; webkit-text-stroke-width: 0">
    <DIV lang=3DEN-US=20
    style=3D"WORD-WRAP: break-word; webkit-nbsp-mode: space; =
webkit-line-break: after-white-space"=20
    vlink=3D"blue" link=3D"blue">
    <DIV class=3DSection1>
    <DIV=20
    style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: 'Times =
New Roman'"><FONT=20
    face=3DArial color=3Dnavy size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Hi=20
    Thomas,<O:P></O:P></SPAN></FONT></DIV>
    <DIV=20
    style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: 'Times =
New Roman'"><FONT=20
    face=3DArial color=3Dnavy size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    My understanding of the ID was that RSVP-TE can be used to =
=91piggyback=92 CFM=20
    set-up, otherwise the scenario is: usage of RSVP-TE to set-up the =
LSP and=20
    NMS (meaning everything that is not control plane) to enable to CFM =
for the=20
    LSP.</SPAN></FONT></DIV></DIV></DIV></SPAN></BLOCKQUOTE>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2></FONT><BR =
class=3Dwebkit-block-placeholder></DIV><SPAN=20
  class=3DApple-tab-span style=3D"WHITE-SPACE: pre"></SPAN>As I =
understand it, the=20
  IEEE is working on set-up of CFM (and MEPs), as are some vendors I =
know.=20
  *)</DIV>
  <DIV>This to me seems like the right way to do this.</DIV>
  <DIV><SPAN class=3D993515301-05122007><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>&nbsp;</FONT></SPAN></DIV></BLOCKQUOTE>
<DIV><SPAN class=3D993515301-05122007><FONT face=3DArial color=3D#0000ff =
size=3D2>IEEE=20
specified CFM and MIBs to setup CFM.&nbsp;</FONT></SPAN></DIV>
<DIV><SPAN class=3D993515301-05122007><FONT face=3DArial color=3D#0000ff =

size=3D2>Diego's summary is correct: one can use an NMS or&nbsp;a =
control plane to=20
setup the data plane. In this case we propose to use&nbsp;GMPLS to setup =
the=20
data plane: both forwarding + OAM.</FONT></SPAN><BR></DIV>
<BLOCKQUOTE=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <BLOCKQUOTE type=3D"cite"><SPAN class=3DApple-style-span=20
    style=3D"WORD-SPACING: 0px; FONT: 13px Helvetica; TEXT-TRANSFORM: =
none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; =
LETTER-SPACING: normal; BORDER-COLLAPSE: separate; orphans: 2; widows: =
2; webkit-border-horizontal-spacing: 0px; =
webkit-border-vertical-spacing: 0px; webkit-text-decorations-in-effect: =
none; webkit-text-size-adjust: auto; webkit-text-stroke-width: 0">
    <DIV class=3DSection1 lang=3DEN-US=20
    style=3D"WORD-WRAP: break-word; webkit-nbsp-mode: space; =
webkit-line-break: after-white-space"=20
    vlink=3D"blue" link=3D"blue">
    <DIV=20
    style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: 'Times =
New Roman'"><FONT=20
    face=3DArial color=3Dnavy size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><O:P></O:P></SPAN></FONT></DIV>
    <DIV=20
    style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: 'Times =
New Roman'"><SPAN=20
    class=3DApple-style-span=20
    style=3D"FONT-SIZE: 13px; COLOR: rgb(20,79,174); =
webkit-text-stroke-width: -1">From=20
    your comment I see that you=92re not happy with the fact the ID is =
so=20
    technology specific am I right? =
&nbsp;</SPAN></DIV></DIV></SPAN></BLOCKQUOTE>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2></FONT><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT><FONT=20
  face=3DArial color=3D#0000ff size=3D2></FONT><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT><FONT face=3DArial=20
  color=3D#0000ff size=3D2></FONT><BR =
class=3Dwebkit-block-placeholder></DIV>
  <DIV><SPAN class=3DApple-tab-span style=3D"WHITE-SPACE: =
pre"></SPAN>Precisely; its=20
  gluing CFM to RSVP-TE/GMPLS as a transport.&nbsp;<BR=20
  class=3Dwebkit-block-placeholder></DIV><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT><FONT face=3DArial=20
  color=3D#0000ff size=3D2></FONT></BLOCKQUOTE>
<DIV><SPAN class=3D993515301-05122007><FONT face=3DArial color=3D#0000ff =
size=3D2>I do=20
not see your point with gluing. What do you mean by "as transport"? =
GMPLS is=20
just controlling OAM, CFM is run solely in the data =
plane.</FONT></SPAN></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT><FONT =
face=3DArial color=3D#0000ff=20
size=3D2></FONT><FONT face=3DArial color=3D#0000ff size=3D2></FONT><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT><BR></DIV>
<BLOCKQUOTE=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <BLOCKQUOTE type=3D"cite"><SPAN class=3DApple-style-span=20
    style=3D"WORD-SPACING: 0px; FONT: 13px Helvetica; TEXT-TRANSFORM: =
none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; =
LETTER-SPACING: normal; BORDER-COLLAPSE: separate; orphans: 2; widows: =
2; webkit-border-horizontal-spacing: 0px; =
webkit-border-vertical-spacing: 0px; webkit-text-decorations-in-effect: =
none; webkit-text-size-adjust: auto; webkit-text-stroke-width: 0">
    <DIV class=3DSection1 lang=3DEN-US=20
    style=3D"WORD-WRAP: break-word; webkit-nbsp-mode: space; =
webkit-line-break: after-white-space"=20
    vlink=3D"blue" link=3D"blue">
    <DIV=20
    style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: 'Times =
New Roman'"><SPAN=20
    class=3DApple-style-span=20
    style=3D"FONT-SIZE: 13px; COLOR: rgb(20,79,174); =
webkit-text-stroke-width: -1">If=20
    yes do you agree with the fact that could be useful in general to =
use the=20
    same signaling =91session=92 to set-up the LSP and to enable the=20
    CFM?</SPAN></DIV></DIV></SPAN></BLOCKQUOTE>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2></FONT><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT><FONT=20
  face=3DArial color=3D#0000ff size=3D2></FONT><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT><FONT face=3DArial=20
  color=3D#0000ff size=3D2></FONT><BR =
class=3Dwebkit-block-placeholder></DIV>
  <DIV><SPAN class=3DApple-tab-span style=3D"WHITE-SPACE: =
pre"></SPAN>No, I do not=20
  agree. &nbsp;Again, if CFM is to be set-up e2e, let the IEEE define =
this.=20
  Leave GMPLS to CCAMP.</DIV><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT><FONT=20
  face=3DArial color=3D#0000ff size=3D2></FONT><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT></BLOCKQUOTE>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D993515301-05122007></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D993515301-05122007></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D993515301-05122007>Sorry,=20
I cannot follow.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT>&nbsp;</DIV>
<BLOCKQUOTE=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT><BR=20
  class=3Dwebkit-block-placeholder></DIV>
  <DIV><SPAN class=3DApple-tab-span style=3D"WHITE-SPACE: =
pre"></SPAN>--Tom</DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2></FONT><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT><FONT=20
  face=3DArial color=3D#0000ff size=3D2></FONT><BR=20
  class=3Dwebkit-block-placeholder></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2></FONT><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT><BR=20
  class=3Dwebkit-block-placeholder></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2></FONT><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT><BR>
  <BLOCKQUOTE type=3D"cite"><SPAN class=3DApple-style-span=20
    style=3D"WORD-SPACING: 0px; FONT: 13px Helvetica; TEXT-TRANSFORM: =
none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; =
LETTER-SPACING: normal; BORDER-COLLAPSE: separate; orphans: 2; widows: =
2; webkit-border-horizontal-spacing: 0px; =
webkit-border-vertical-spacing: 0px; webkit-text-decorations-in-effect: =
none; webkit-text-size-adjust: auto; webkit-text-stroke-width: 0">
    <DIV lang=3DEN-US=20
    style=3D"WORD-WRAP: break-word; webkit-nbsp-mode: space; =
webkit-line-break: after-white-space"=20
    vlink=3D"blue" link=3D"blue">
    <DIV class=3DSection1>
    <DIV=20
    style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: 'Times =
New Roman'"><FONT=20
    face=3DArial color=3Dnavy size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><O:P>&nbsp;<SPAN=20
    class=3DApple-style-span=20
    style=3D"COLOR: rgb(20,79,174); webkit-text-stroke-width: -1">Best=20
    Regards</SPAN></O:P></SPAN></FONT></DIV>
    <DIV=20
    style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: 'Times =
New Roman'"><FONT=20
    face=3DArial color=3Dnavy size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><BR>Diego<O:P></O:P></SPAN></FONT></DIV>
    <DIV=20
    style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: 'Times =
New Roman'"><FONT=20
    face=3DArial color=3Dnavy size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><O:P></O:P></SPAN></FONT></DIV>
    <DIV=20
    style=3D"PADDING-RIGHT: 0cm; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0cm; =
BORDER-LEFT: blue 1.5pt solid; BORDER-TOP-STYLE: none; PADDING-TOP: 0cm; =
BORDER-RIGHT-STYLE: none; BORDER-BOTTOM-STYLE: none">
    <DIV>
    <DIV class=3DMsoNormal=20
    style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: 'Times =
New Roman'; TEXT-ALIGN: center"=20
    align=3Dcenter><FONT face=3D"Times New Roman" size=3D3><SPAN=20
    style=3D"FONT-SIZE: 12pt">
    <HR tabIndex=3D-1 align=3Dcenter width=3D"100%" SIZE=3D2>
    </SPAN></FONT></DIV>
    <DIV=20
    style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: 'Times =
New Roman'"><B><FONT=20
    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"><SPAN=20
    class=3DApple-converted-space>&nbsp;</SPAN><A=20
    =
href=3D"mailto:[email-masked]">[email-masked]</A> =
[<A=20
    style=3D"COLOR: blue; TEXT-DECORATION: underline"=20
    =
href=3D"mailto:[email-masked]">mailto:[email-masked]<=
/A>]<SPAN=20
    class=3DApple-converted-space>&nbsp;</SPAN><B><SPAN=20
    style=3D"FONT-WEIGHT: bold">On Behalf Of<SPAN=20
    class=3DApple-converted-space>&nbsp;</SPAN></SPAN></B>Thomas=20
    Nadeau<BR><B><SPAN style=3D"FONT-WEIGHT: bold">Sent:</SPAN></B><SPAN =

    class=3DApple-converted-space>&nbsp;</SPAN>marted=EC 4 dicembre 2007 =

    11.30<BR><B><SPAN style=3D"FONT-WEIGHT: bold">To:</SPAN></B><SPAN=20
    class=3DApple-converted-space>&nbsp;</SPAN>Attila Takacs<BR><B><SPAN =

    style=3D"FONT-WEIGHT: bold">Cc:</SPAN></B><SPAN=20
    class=3DApple-converted-space>&nbsp;</SPAN><A=20
    style=3D"COLOR: blue; TEXT-DECORATION: underline"=20
    href=3D"mailto:[email-masked]">[email-masked]</A>;<SPAN=20
    class=3DApple-converted-space>&nbsp;</SPAN><A=20
    style=3D"COLOR: blue; TEXT-DECORATION: underline"=20
    =
href=3D"mailto:[email-masked]">[email-masked]</A><BR>=
<B><SPAN=20
    style=3D"FONT-WEIGHT: bold">Subject:</SPAN></B><SPAN=20
    class=3DApple-converted-space>&nbsp;</SPAN>Re:=20
    =
draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt</SPAN></FONT><O:P></O:P></D=
IV></DIV>
    <DIV=20
    style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: 'Times =
New Roman'"><FONT=20
    face=3D"Times New Roman" size=3D3><SPAN=20
    style=3D"FONT-SIZE: 12pt"><O:P></O:P></SPAN></FONT></DIV>
    <DIV=20
    style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: 'Times =
New Roman'"><FONT=20
    face=3D"Times New Roman" size=3D3><SPAN=20
    style=3D"FONT-SIZE: 12pt"><O:P></O:P></SPAN></FONT></DIV>
    <DIV>
    <DIV>
    <DIV=20
    style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: 'Times =
New Roman'"><FONT=20
    face=3D"Times New Roman" size=3D3><SPAN style=3D"FONT-SIZE: 12pt">On =
Dec 4, 2007,=20
    at 1:51 PM, Attila Takacs =
wrote:<O:P></O:P></SPAN></FONT></DIV></DIV>
    <DIV=20
    style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: 'Times =
New Roman'"><FONT=20
    face=3D"Times New Roman" size=3D3><SPAN=20
    style=3D"FONT-SIZE: 12pt"><BR><BR><O:P></O:P></SPAN></FONT></DIV>
    <DIV style=3D"WORD-WRAP: break-word">
    <DIV>
    <DIV=20
    style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: 'Times =
New Roman'"><FONT=20
    face=3DArial color=3Dblue size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Hi=20
    Thomas,</SPAN></FONT><O:P></O:P></DIV></DIV>
    <DIV>
    <DIV=20
    style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: 'Times =
New Roman'"><FONT=20
    face=3D"Times New Roman" size=3D3><SPAN=20
    style=3D"FONT-SIZE: 12pt"><O:P></O:P></SPAN></FONT></DIV></DIV>
    <DIV>
    <DIV=20
    style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: 'Times =
New Roman'"><FONT=20
    face=3DArial color=3Dblue size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Thank =
you&nbsp;for=20
    the comments!</SPAN></FONT><O:P></O:P></DIV></DIV>
    <DIV>
    <DIV=20
    style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: 'Times =
New Roman'"><FONT=20
    face=3DArial color=3Dblue size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Please =
see answers=20
    inline.</SPAN></FONT><O:P></O:P></DIV></DIV>
    <DIV>
    <DIV=20
    style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: 'Times =
New Roman'"><FONT=20
    face=3D"Times New Roman" size=3D3><SPAN=20
    style=3D"FONT-SIZE: 12pt"><O:P></O:P></SPAN></FONT></DIV></DIV>
    <DIV>
    <DIV=20
    style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: 'Times =
New Roman'"><FONT=20
    face=3DArial color=3Dblue size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Best=20
    regards,<BR>Attila</SPAN></FONT><O:P></O:P></DIV></DIV>
    <BLOCKQUOTE=20
    style=3D"PADDING-RIGHT: 0cm; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0cm; =
MARGIN: 5pt 0cm 5pt 3.75pt; BORDER-LEFT: blue 1.5pt solid; =
BORDER-TOP-STYLE: none; PADDING-TOP: 0cm; BORDER-RIGHT-STYLE: none; =
BORDER-BOTTOM-STYLE: none">
      <DIV=20
      style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: 'Times =
New Roman'"><FONT=20
      face=3D"Times New Roman" size=3D3><SPAN=20
      style=3D"FONT-SIZE: 12pt"><O:P></O:P></SPAN></FONT></DIV>
      <DIV class=3DMsoNormal=20
      style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: 'Times =
New Roman'; TEXT-ALIGN: center"=20
      align=3Dcenter><FONT face=3D"Times New Roman" size=3D3><SPAN=20
      style=3D"FONT-SIZE: 12pt">
      <HR tabIndex=3D-1 align=3Dcenter width=3D"100%" SIZE=3D2>
      </SPAN></FONT></DIV>
      <DIV=20
      style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: 'Times =
New Roman'"><B><FONT=20
      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=20
      style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Tahoma"><SPAN=20
      class=3DApple-converted-space>&nbsp;</SPAN>Thomas Nadeau [<A=20
      style=3D"COLOR: blue; TEXT-DECORATION: underline"=20
      =
href=3D"mailto:[email-masked]">mailto:[email-masked]</A=
>]<SPAN=20
      class=3DApple-converted-space>&nbsp;</SPAN><BR><B><SPAN=20
      style=3D"FONT-WEIGHT: bold">Sent:</SPAN></B><SPAN=20
      class=3DApple-converted-space>&nbsp;</SPAN>Tuesday, December 04, =
2007 2:58=20
      PM<BR><B><SPAN style=3D"FONT-WEIGHT: bold">To:</SPAN></B><SPAN=20
      class=3DApple-converted-space>&nbsp;</SPAN><A=20
      style=3D"COLOR: blue; TEXT-DECORATION: underline"=20
      =
href=3D"mailto:[email-masked]">[email-masked]</A><BR><B><SPAN=20
      style=3D"FONT-WEIGHT: bold">Cc:</SPAN></B><SPAN=20
      class=3DApple-converted-space>&nbsp;</SPAN>Attila Takacs;<SPAN=20
      class=3DApple-converted-space>&nbsp;</SPAN><A=20
      style=3D"COLOR: blue; TEXT-DECORATION: underline"=20
      =
href=3D"mailto:[email-masked]">[email-masked]</A><BR>=
<B><SPAN=20
      style=3D"FONT-WEIGHT: bold">Subject:</SPAN></B><SPAN=20
      =
class=3DApple-converted-space>&nbsp;</SPAN>draft-takacs-ccamp-rsvp-te-eth=
-oam-ext-00.txt</SPAN></FONT><O:P></O:P></DIV>
      <DIV=20
      style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: 'Times =
New Roman'"><FONT=20
      face=3D"Times New Roman" size=3D3><SPAN=20
      style=3D"FONT-SIZE: 12pt"><O:P></O:P></SPAN></FONT></DIV>
      <DIV>
      <DIV=20
      style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: 'Times =
New Roman'"><FONT=20
      face=3D"Times New Roman" size=3D3><SPAN=20
      style=3D"FONT-SIZE: 12pt"><O:P></O:P></SPAN></FONT></DIV></DIV>
      <DIV>
      <DIV=20
      style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: 'Times =
New Roman'"><FONT=20
      face=3D"Times New Roman" size=3D3><SPAN style=3D"FONT-SIZE: =
12pt">After reading=20
      this draft, I have some=20
      questions/comments.<O:P></O:P></SPAN></FONT></DIV></DIV>
      <DIV>
      <DIV=20
      style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: 'Times =
New Roman'"><FONT=20
      face=3D"Times New Roman" size=3D3><SPAN=20
      style=3D"FONT-SIZE: 12pt"><O:P></O:P></SPAN></FONT></DIV></DIV>
      <DIV>
      <DIV=20
      style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: 'Times =
New Roman'"><FONT=20
      face=3D"Times New Roman" size=3D3><SPAN style=3D"FONT-SIZE: =
12pt">1)=20
      Overall,&nbsp;I am concerned that the definition of a new TLV and =
these=20
      procedures represent&nbsp;<O:P></O:P></SPAN></FONT></DIV></DIV>
      <DIV>
      <DIV=20
      style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: 'Times =
New Roman'"><FONT=20
      face=3D"Times New Roman" size=3D3><SPAN style=3D"FONT-SIZE: =
12pt">what amounts=20
      to a laying violation and ask that the ADs take a look at=20
      this<O:P></O:P></SPAN></FONT></DIV></DIV>
      <DIV>
      <DIV=20
      style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: 'Times =
New Roman'"><FONT=20
      face=3D"Times New Roman" size=3D3><SPAN style=3D"FONT-SIZE: =
12pt">approach=20
      closely. This is similar to the now-rejected approach that was=20
      proposed<O:P></O:P></SPAN></FONT></DIV></DIV>
      <DIV>
      <DIV=20
      style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: 'Times =
New Roman'"><FONT=20
      face=3D"Times New Roman" size=3D3><SPAN style=3D"FONT-SIZE: =
12pt">in the l2vpn=20
      WG about munging CFM + PWs. &nbsp;To my reading, this is=20
      essentially<O:P></O:P></SPAN></FONT></DIV></DIV>
      <DIV>
      <DIV=20
      style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: 'Times =
New Roman'"><FONT=20
      face=3D"Times New Roman" size=3D3><SPAN style=3D"FONT-SIZE: =
12pt">the same=20
      thing. If you want to run CFM, run it natively over the ethernet=20
      interfaces and<O:P></O:P></SPAN></FONT></DIV></DIV>
      <DIV>
      <DIV=20
      style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: 'Times =
New Roman'"><FONT=20
      face=3D"Times New Roman" size=3D3><SPAN style=3D"FONT-SIZE: =
12pt">have no regard=20
      for the underlying topology (GMPLS, PWs, etc...) otherwise=20
      you&nbsp;<O:P></O:P></SPAN></FONT></DIV></DIV>
      <DIV>
      <DIV=20
      style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: 'Times =
New Roman'"><FONT=20
      face=3D"Times New Roman" size=3D3><SPAN style=3D"FONT-SIZE: =
12pt">will be=20
      creating a mess for implementations and=20
      interoperability.&nbsp;</SPAN></FONT><FONT face=3DArial =
color=3Dblue=20
      size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
Arial">&nbsp;</SPAN></FONT><O:P></O:P></DIV></DIV></BLOCKQUOTE>
    <DIV>
    <DIV=20
    style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: 'Times =
New Roman'"><FONT=20
    face=3DArial color=3Dblue size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">The=20
    application&nbsp;of the draft is exactly for what you are calling =
out: when=20
    CFM is run natively over the Ethernet interfaces. The document =
focuses on=20
    GELS and Ethernet LSPs.&nbsp;That is,&nbsp;to establish CFM entities =
for=20
    GMPLS controlled Ethernet LSPs.&nbsp;Hence, I think there is no =
layer=20
    violation issue.</SPAN></FONT><O:P></O:P></DIV></DIV></DIV>
    <DIV>
    <DIV=20
    style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: 'Times =
New Roman'"><FONT=20
    face=3D"Times New Roman" size=3D3><SPAN=20
    style=3D"FONT-SIZE: 12pt"><O:P></O:P></SPAN></FONT></DIV></DIV>
    <DIV=20
    style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: 'Times =
New Roman'"><SPAN=20
    class=3Dapple-tab-span><FONT face=3D"Times New Roman" size=3D3><SPAN =

    style=3D"FONT-SIZE: =
12pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<SPAN=20
    class=3DApple-converted-space>&nbsp;</SPAN></SPAN></FONT></SPAN>This =
solution=20
    specifically only works for GMPLS ethernet LSPs, right?=20
    &nbsp;<O:P></O:P></DIV></DIV>
    <DIV>
    <DIV=20
    style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: 'Times =
New Roman'"><FONT=20
    face=3D"Times New Roman" size=3D3><SPAN style=3D"FONT-SIZE: =
12pt">What do I do if=20
    I want to set up MPLS ethernet LSPs (i.e.: PWs)&nbsp;and do CFM over =
those?=20
    Oh,<O:P></O:P></SPAN></FONT></DIV></DIV>
    <DIV>
    <DIV=20
    style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: 'Times =
New Roman'"><FONT=20
    face=3D"Times New Roman" size=3D3><SPAN style=3D"FONT-SIZE: =
12pt">that is a=20
    different solution, right? &nbsp;Then what do I do if I want to run =
CFM over=20
    some new type of<O:P></O:P></SPAN></FONT></DIV></DIV>
    <DIV>
    <DIV=20
    style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: 'Times =
New Roman'"><FONT=20
    face=3D"Times New Roman" size=3D3><SPAN style=3D"FONT-SIZE: =
12pt">ethernet LSP in=20
    the future? More protocol hacks? &nbsp;The point is to use CFM over =
an=20
    ethernet interface<O:P></O:P></SPAN></FONT></DIV></DIV>
    <DIV>
    <DIV=20
    style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: 'Times =
New Roman'"><FONT=20
    face=3D"Times New Roman" size=3D3><SPAN style=3D"FONT-SIZE: =
12pt">without the=20
    underlying layers knowing. This is good networking architecture =
design, that=20
    simplifies<O:P></O:P></SPAN></FONT></DIV></DIV>
    <DIV>
    <DIV=20
    style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: 'Times =
New Roman'"><FONT=20
    face=3D"Times New Roman" size=3D3><SPAN style=3D"FONT-SIZE: =
12pt">implementations=20
    and makes them more robust, as well as makes using them =
operationally=20
    much<O:P></O:P></SPAN></FONT></DIV></DIV>
    <DIV>
    <DIV=20
    style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: 'Times =
New Roman'"><FONT=20
    face=3D"Times New Roman" size=3D3><SPAN=20
    style=3D"FONT-SIZE: =
12pt">easier.&nbsp;<O:P></O:P></SPAN></FONT></DIV></DIV>
    <DIV>
    <BLOCKQUOTE style=3D"MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt" =
type=3D"cite">
      <DIV style=3D"WORD-WRAP: break-word">
      <BLOCKQUOTE=20
      style=3D"PADDING-RIGHT: 0cm; PADDING-LEFT: 4pt; PADDING-BOTTOM: =
0cm; MARGIN: 5pt 0cm 5pt 3.75pt; BORDER-LEFT: blue 1.5pt solid; =
BORDER-TOP-STYLE: none; PADDING-TOP: 0cm; BORDER-RIGHT-STYLE: none; =
BORDER-BOTTOM-STYLE: none">
        <DIV>
        <DIV=20
        style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: =
'Times New Roman'"><FONT=20
        face=3D"Times New Roman" size=3D3><SPAN style=3D"FONT-SIZE: =
12pt">2)&nbsp;The=20
        introductory sections in this draft give a lot of discussion =
about fast=20
        fault detection. I<O:P></O:P></SPAN></FONT></DIV></DIV>
        <DIV>
        <DIV=20
        style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: =
'Times New Roman'"><FONT=20
        face=3D"Times New Roman" size=3D3><SPAN style=3D"FONT-SIZE: =
12pt">am puzzled=20
        by this given that GMPLS networks tend to run over quickly=20
        self-healing<O:P></O:P></SPAN></FONT></DIV></DIV>
        <DIV>
        <DIV=20
        style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: =
'Times New Roman'"><FONT=20
        face=3D"Times New Roman" size=3D3><SPAN style=3D"FONT-SIZE: =
12pt">optical=20
        infrastructures. Is it therefore&nbsp;truly&nbsp;necessary to =
motivate=20
        this work by<O:P></O:P></SPAN></FONT></DIV></DIV>
        <DIV>
        <DIV=20
        style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: =
'Times New Roman'"><FONT=20
        face=3D"Times New Roman" size=3D3><SPAN style=3D"FONT-SIZE: =
12pt">requiring=20
        fast CFMs?<O:P></O:P></SPAN></FONT></DIV></DIV></BLOCKQUOTE>
      <DIV>
      <DIV=20
      style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: 'Times =
New Roman'"><FONT=20
      face=3DArial color=3Dblue size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">It is =
right that=20
      frequent CCMs are not required if the layers below Ethernet handle =

      protection. However, the ID focuses on Ethernet LSPs where =
Ethernet=20
      is&nbsp;not just a single hop&nbsp;above a transport LSP.&nbsp;In =
this=20
      case&nbsp;Ethernet layer (for clarity GELS) may provide protection =
for=20
      Ethernet LSPs.&nbsp;In any case,&nbsp; the whole point of the ID =
is to=20
      allow for the appropriate configuration of CFM for Ethernet LSPs =
with=20
      GMPLS.</SPAN></FONT><O:P></O:P></DIV></DIV>
      <DIV>
      <DIV=20
      style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: 'Times =
New Roman'"><FONT=20
      face=3D"Times New Roman" size=3D3><SPAN=20
      style=3D"FONT-SIZE: 12pt"><O:P></O:P></SPAN></FONT></DIV></DIV>
      <BLOCKQUOTE=20
      style=3D"PADDING-RIGHT: 0cm; PADDING-LEFT: 4pt; PADDING-BOTTOM: =
0cm; MARGIN: 5pt 0cm 5pt 3.75pt; BORDER-LEFT: blue 1.5pt solid; =
BORDER-TOP-STYLE: none; PADDING-TOP: 0cm; BORDER-RIGHT-STYLE: none; =
BORDER-BOTTOM-STYLE: none">
        <DIV>
        <DIV=20
        style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: =
'Times New Roman'"><FONT=20
        face=3D"Times New Roman" size=3D3><SPAN style=3D"FONT-SIZE: =
12pt">3) This=20
        document does not cover E-LMI. Why=20
        not?<O:P></O:P></SPAN></FONT></DIV></DIV></BLOCKQUOTE>
      <DIV>
      <DIV=20
      style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: 'Times =
New Roman'"><FONT=20
      face=3DArial color=3Dblue size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">E-LMI =
is run over=20
      the MEF UNI. The&nbsp;ID focuses on Ethernet LSPs within a=20
      network.</SPAN></FONT><O:P></O:P></DIV></DIV>
      <DIV>
      <DIV=20
      style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: 'Times =
New Roman'"><FONT=20
      face=3D"Times New Roman" size=3D3><SPAN=20
      style=3D"FONT-SIZE: 12pt"><O:P></O:P></SPAN></FONT></DIV></DIV>
      <DIV>
      <DIV=20
      style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: 'Times =
New Roman'"><FONT=20
      face=3D"Times New Roman" size=3D3><SPAN=20
      style=3D"FONT-SIZE: 12pt"><O:P></O:P></SPAN></FONT></DIV></DIV>
      <BLOCKQUOTE=20
      style=3D"PADDING-RIGHT: 0cm; PADDING-LEFT: 4pt; PADDING-BOTTOM: =
0cm; MARGIN: 5pt 0cm 5pt 3.75pt; BORDER-LEFT: blue 1.5pt solid; =
BORDER-TOP-STYLE: none; PADDING-TOP: 0cm; BORDER-RIGHT-STYLE: none; =
BORDER-BOTTOM-STYLE: none">
        <DIV>
        <DIV=20
        style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: =
'Times New Roman'"><SPAN=20
        class=3Dapple-style-span><FONT face=3D"Times New Roman" =
size=3D1><SPAN=20
        style=3D"FONT-SIZE: 9pt">For the purposes of this document, we =
only=20
        discuss Ethernet OAM</SPAN></FONT></SPAN><O:P></O:P></DIV></DIV>
        <DIV>
        <DIV=20
        style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: =
'Times New Roman'"><FONT=20
        face=3DHelvetica size=3D1><SPAN=20
        style=3D"FONT-SIZE: 9pt; FONT-FAMILY: Helvetica">&nbsp;&nbsp; =
[IEEE-CFM]=20
        aspects that are relevant for the connectivity=20
        monitoring<O:P></O:P></SPAN></FONT></DIV></DIV>
        <DIV>
        <DIV=20
        style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: =
'Times New Roman'"><FONT=20
        face=3DHelvetica size=3D1><SPAN=20
        style=3D"FONT-SIZE: 9pt; FONT-FAMILY: Helvetica">&nbsp;&nbsp; of =

        bidirectional point-to-point PBB-TE connections.=20
        &nbsp;<O:P></O:P></SPAN></FONT></DIV></DIV>
        <DIV>
        <DIV=20
        style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: =
'Times New Roman'"><FONT=20
        face=3DHelvetica size=3D1><SPAN=20
        style=3D"FONT-SIZE: 9pt; FONT-FAMILY: =
Helvetica"><O:P></O:P></SPAN></FONT></DIV></DIV>
        <DIV>
        <DIV=20
        style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: =
'Times New Roman'"><FONT=20
        face=3DHelvetica size=3D1><SPAN=20
        style=3D"FONT-SIZE: 9pt; FONT-FAMILY: Helvetica">4) Is this the =
right=20
        place to define this document or should this be done in=20
        GELS?<O:P></O:P></SPAN></FONT></DIV></DIV></BLOCKQUOTE>
      <DIV>
      <DIV=20
      style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: 'Times =
New Roman'"><FONT=20
      face=3DArial color=3Dblue size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Well, =
GELS is=20
      done in CCAMP...this seems to be the right=20
      place.</SPAN></FONT><O:P></O:P></DIV></DIV>
      <BLOCKQUOTE=20
      style=3D"PADDING-RIGHT: 0cm; PADDING-LEFT: 4pt; PADDING-BOTTOM: =
0cm; MARGIN: 5pt 0cm 5pt 3.75pt; BORDER-LEFT: blue 1.5pt solid; =
BORDER-TOP-STYLE: none; PADDING-TOP: 0cm; BORDER-RIGHT-STYLE: none; =
BORDER-BOTTOM-STYLE: none">
        <DIV>
        <DIV=20
        style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: =
'Times New Roman'"><FONT=20
        face=3D"Times New Roman" size=3D3><SPAN=20
        style=3D"FONT-SIZE: 12pt"><O:P></O:P></SPAN></FONT></DIV></DIV>
        <DIV>
        <DIV=20
        style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: =
'Times New Roman'"><FONT=20
        face=3DHelvetica size=3D1><SPAN=20
        style=3D"FONT-SIZE: 9pt; FONT-FAMILY: =
Helvetica"><O:P></O:P></SPAN></FONT></DIV></DIV>
        <DIV>
        <DIV=20
        style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: =
'Times New Roman'"><FONT=20
        face=3DHelvetica size=3D1><SPAN=20
        style=3D"FONT-SIZE: 9pt; FONT-FAMILY: Helvetica">5) &nbsp; In =
section 2=20
        you make the following =
statement:<O:P></O:P></SPAN></FONT></DIV></DIV>
        <DIV>
        <DIV=20
        style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: =
'Times New Roman'"><FONT=20
        face=3DHelvetica size=3D1><SPAN=20
        style=3D"FONT-SIZE: 9pt; FONT-FAMILY: =
Helvetica"><O:P></O:P></SPAN></FONT></DIV></DIV>
        <DIV>
        <DIV=20
        style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: =
'Times New Roman'"><FONT=20
        face=3DHelvetica size=3D1><SPAN=20
        style=3D"FONT-SIZE: 9pt; FONT-FAMILY: Helvetica">2.&nbsp; GMPLS =
RSVP-TE=20
        Extensions<O:P></O:P></SPAN></FONT></DIV></DIV>
        <DIV style=3D"MIN-HEIGHT: 14px">
        <DIV=20
        style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: =
'Times New Roman'"><FONT=20
        face=3DHelvetica size=3D1><SPAN=20
        style=3D"FONT-SIZE: 9pt; FONT-FAMILY: =
Helvetica"><O:P></O:P></SPAN></FONT></DIV></DIV>
        <DIV>
        <DIV=20
        style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: =
'Times New Roman'"><FONT=20
        face=3DHelvetica size=3D1><SPAN=20
        style=3D"FONT-SIZE: 9pt; FONT-FAMILY: Helvetica">&nbsp;<SPAN=20
        class=3Dapple-tab-span><SPAN=20
        class=3DApple-converted-space>&nbsp;</SPAN></SPAN>&nbsp; To =
simplify the=20
        configuration of connectivity monitoring, when=20
        an<O:P></O:P></SPAN></FONT></DIV></DIV>
        <DIV>
        <DIV=20
        style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: =
'Times New Roman'"><FONT=20
        face=3DHelvetica size=3D1><SPAN=20
        style=3D"FONT-SIZE: 9pt; FONT-FAMILY: Helvetica">&nbsp;&nbsp; =
Ethernet LSP=20
        is signalled the associated MEPs should be=20
        automatically<O:P></O:P></SPAN></FONT></DIV></DIV>
        <DIV>
        <DIV=20
        style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: =
'Times New Roman'"><FONT=20
        face=3DHelvetica size=3D1><SPAN=20
        style=3D"FONT-SIZE: 9pt; FONT-FAMILY: Helvetica">&nbsp;<SPAN=20
        class=3Dapple-tab-span><SPAN=20
        class=3DApple-converted-space>&nbsp;</SPAN></SPAN>&nbsp;=20
        established.&nbsp; Further more, GMPLS signalling should be able =

        to<O:P></O:P></SPAN></FONT></DIV></DIV>
        <DIV>
        <DIV=20
        style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: =
'Times New Roman'"><FONT=20
        face=3DHelvetica size=3D1><SPAN=20
        style=3D"FONT-SIZE: 9pt; FONT-FAMILY: =
Helvetica">&nbsp;&nbsp;enable/disable=20
        connectivity monitoring of a particular Ethernet=20
        LSP.<O:P></O:P></SPAN></FONT></DIV></DIV>
        <DIV>
        <DIV=20
        style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: =
'Times New Roman'"><FONT=20
        face=3DHelvetica size=3D1><SPAN=20
        style=3D"FONT-SIZE: 9pt; FONT-FAMILY: =
Helvetica"><O:P></O:P></SPAN></FONT></DIV></DIV>
        <DIV>
        <DIV=20
        style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: =
'Times New Roman'"><FONT=20
        face=3DHelvetica size=3D1><SPAN=20
        style=3D"FONT-SIZE: 9pt; FONT-FAMILY: =
Helvetica"><O:P></O:P></SPAN></FONT></DIV></DIV>
        <DIV>
        <DIV=20
        style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: =
'Times New Roman'"><FONT=20
        face=3DHelvetica size=3D1><SPAN=20
        style=3D"FONT-SIZE: 9pt; FONT-FAMILY: Helvetica">To my point in =
#1 above,=20
        you should use the native CFM functionality over the ethernet =
interface=20
        and signal<O:P></O:P></SPAN></FONT></DIV></DIV>
        <DIV>
        <DIV=20
        style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: =
'Times New Roman'"><FONT=20
        face=3DHelvetica size=3D1><SPAN=20
        style=3D"FONT-SIZE: 9pt; FONT-FAMILY: Helvetica">those =
capabilities to the=20
        bridges at both ends using the IEEE CFM signaling procedures =
(when and=20
        if they<O:P></O:P></SPAN></FONT></DIV></DIV>
        <DIV>
        <DIV=20
        style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: =
'Times New Roman'"><FONT=20
        face=3DHelvetica size=3D1><SPAN=20
        style=3D"FONT-SIZE: 9pt; FONT-FAMILY: Helvetica">are created). =
&nbsp;If=20
        you want to test the underlying GMPLS LSP(s), then you should =
use=20
        some<O:P></O:P></SPAN></FONT></DIV></DIV>
        <DIV>
        <DIV=20
        style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: =
'Times New Roman'"><FONT=20
        face=3DHelvetica size=3D1><SPAN=20
        style=3D"FONT-SIZE: 9pt; FONT-FAMILY: Helvetica">other mechanism =
defined=20
        for that layer such as the work stated =
in&nbsp;</SPAN></FONT><SPAN=20
        class=3Dapple-style-span><B><FONT face=3DHelvetica =
size=3D2><SPAN=20
        style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: =
Helvetica">draft-ali-ccamp-gmpls-LSP-ping-traceroute-00.txt</SPAN></FONT>=
</B></SPAN><FONT=20
        face=3DHelvetica size=3D1><SPAN=20
        style=3D"FONT-SIZE: 9pt; FONT-FAMILY: =
Helvetica"><O:P></O:P></SPAN></FONT></DIV></DIV></BLOCKQUOTE>
      <DIV>
      <DIV=20
      style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: 'Times =
New Roman'"><FONT=20
      face=3DArial color=3Dblue size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">See the =

      note&nbsp;to your point #1. There is no relation&nbsp;to the=20
      gmpls-LSP-ping draft.&nbsp;</SPAN></FONT><FONT face=3DHelvetica =
size=3D1><SPAN=20
      style=3D"FONT-SIZE: 9pt; FONT-FAMILY: =
Helvetica"><O:P></O:P></SPAN></FONT></DIV></DIV></DIV></BLOCKQUOTE>
    <DIV>
    <DIV=20
    style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: 'Times =
New Roman'"><FONT=20
    face=3D"Times New Roman" size=3D3><SPAN=20
    style=3D"FONT-SIZE: 12pt"><O:P></O:P></SPAN></FONT></DIV></DIV>
    <DIV=20
    style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: 'Times =
New Roman'"><SPAN=20
    class=3Dapple-tab-span><FONT face=3D"Times New Roman" size=3D3><SPAN =

    style=3D"FONT-SIZE: =
12pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<SPAN=20
    class=3DApple-converted-space>&nbsp;</SPAN></SPAN></FONT></SPAN>The =
point I am=20
    making is that perhaps it should.<O:P></O:P></DIV></DIV>
    <DIV>
    <DIV=20
    style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: 'Times =
New Roman'"><FONT=20
    face=3D"Times New Roman" size=3D3><SPAN=20
    style=3D"FONT-SIZE: 12pt"><O:P></O:P></SPAN></FONT></DIV></DIV>
    <DIV>
    <DIV=20
    style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: 'Times =
New Roman'"><SPAN=20
    class=3Dapple-tab-span><FONT face=3D"Times New Roman" size=3D3><SPAN =

    style=3D"FONT-SIZE: =
12pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<SPAN=20
    =
class=3DApple-converted-space>&nbsp;</SPAN></SPAN></FONT></SPAN>--Tom<O:P=
></O:P></DIV></DIV>
    <DIV>
    <DIV=20
    style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: 'Times =
New Roman'"><FONT=20
    face=3D"Times New Roman" size=3D3><SPAN=20
    style=3D"FONT-SIZE: 12pt"><O:P></O:P></SPAN></FONT></DIV></DIV>
    <DIV>
    <DIV=20
    style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: 'Times =
New Roman'"><FONT=20
    face=3D"Times New Roman" size=3D3><SPAN=20
    style=3D"FONT-SIZE: 12pt"><O:P></O:P></SPAN></FONT></DIV></DIV>
    <DIV>
    <BLOCKQUOTE style=3D"MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt" =
type=3D"cite">
      <DIV style=3D"WORD-WRAP: break-word">
      <DIV>
      <DIV=20
      style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: 'Times =
New Roman'"><FONT=20
      face=3DHelvetica size=3D1><SPAN=20
      style=3D"FONT-SIZE: 9pt; FONT-FAMILY: =
Helvetica"><O:P></O:P></SPAN></FONT></DIV></DIV>
      <DIV>
      <DIV=20
      style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: 'Times =
New Roman'"><FONT=20
      face=3DHelvetica size=3D1><SPAN=20
      style=3D"FONT-SIZE: 9pt; FONT-FAMILY: =
Helvetica"><O:P></O:P></SPAN></FONT></DIV></DIV>
      <DIV>
      <DIV=20
      style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: 'Times =
New Roman'"><FONT=20
      face=3DHelvetica size=3D1><SPAN=20
      style=3D"FONT-SIZE: 9pt; FONT-FAMILY: =
Helvetica"><O:P></O:P></SPAN></FONT></DIV></DIV></DIV></BLOCKQUOTE></DIV>=

    <DIV=20
    style=3D"FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: 'Times =
New Roman'"><FONT=20
    face=3D"Times New Roman" size=3D3><SPAN=20
    style=3D"FONT-SIZE: =
12pt"><O:P></O:P></SPAN></FONT></DIV></DIV></DIV></DIV></SPAN></BLOCKQUOT=
E></DIV><BR></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C836E3.05B15F17--

Delivery-date: Wed, 05 Dec 2007 01:20:45 +0000
Cc: "Attila Takacs" <[email-masked]>, <[email-masked]>, <[email-masked]>
From: Thomas Nadeau <[email-masked]>
To: "Diego Caviglia" <[email-masked]>
Subject: Re: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt
Date: Tue, 4 Dec 2007 20:19:03 -0500

--Apple-Mail-28--532988434
Content-Type: text/plain;
	charset=WINDOWS-1252;
	format=flowed;
	delsp=yes
Content-Transfer-Encoding: quoted-printable

On Dec 4, 2007, at 7:33 PM, Diego Caviglia wrote:

> Hi Thomas,
>                  My understanding of the ID was that RSVP-TE can be =20=

> used to =91piggyback=92 CFM set-up, otherwise the scenario is: usage =
of =20
> RSVP-TE to set-up the LSP and NMS (meaning everything that is not =20
> control plane) to enable to CFM for the LSP.

	As I understand it, the IEEE is working on set-up of CFM (and =
MEPs), =20
as are some vendors I know. *)
This to me seems like the right way to do this.

> =46rom your comment I see that you=92re not happy with the fact the ID =
=20
> is so technology specific am I right?

	Precisely; its gluing CFM to RSVP-TE/GMPLS as a transport.

> If yes do you agree with the fact that could be useful in general to =20=

> use the same signaling =91session=92 to set-up the LSP and to enable =
the =20
> CFM?

	No, I do not agree.  Again, if CFM is to be set-up e2e, let the =
IEEE =20
define this. Leave GMPLS to CCAMP.

	--Tom

>  Best Regards
>
> Diego
>
> From: [email-masked] [mailto:[email-masked]] On =20=

> Behalf Of Thomas Nadeau
> Sent: marted=EC 4 dicembre 2007 11.30
> To: Attila Takacs
> Cc: [email-masked]; [email-masked]
> Subject: Re: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt
>
>
> On Dec 4, 2007, at 1:51 PM, Attila Takacs wrote:
>
>
> Hi Thomas,
>
> Thank you for the comments!
> Please see answers inline.
>
> Best regards,
> Attila
>
> From: Thomas Nadeau [mailto:[email-masked]]
> Sent: Tuesday, December 04, 2007 2:58 PM
> To: [email-masked]
> Cc: Attila Takacs; [email-masked]
> Subject: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt
>
>
> After reading this draft, I have some questions/comments.
>
> 1) Overall, I am concerned that the definition of a new TLV and =20
> these procedures represent
> what amounts to a laying violation and ask that the ADs take a look =20=

> at this
> approach closely. This is similar to the now-rejected approach that =20=

> was proposed
> in the l2vpn WG about munging CFM + PWs.  To my reading, this is =20
> essentially
> the same thing. If you want to run CFM, run it natively over the =20
> ethernet interfaces and
> have no regard for the underlying topology (GMPLS, PWs, etc...) =20
> otherwise you
> will be creating a mess for implementations and interoperability.
> The application of the draft is exactly for what you are calling =20
> out: when CFM is run natively over the Ethernet interfaces. The =20
> document focuses on GELS and Ethernet LSPs. That is, to establish =20
> CFM entities for GMPLS controlled Ethernet LSPs. Hence, I think =20
> there is no layer violation issue.
>
>           This solution specifically only works for GMPLS ethernet =20
> LSPs, right?
> What do I do if I want to set up MPLS ethernet LSPs (i.e.: PWs) and =20=

> do CFM over those? Oh,
> that is a different solution, right?  Then what do I do if I want to =20=

> run CFM over some new type of
> ethernet LSP in the future? More protocol hacks?  The point is to =20
> use CFM over an ethernet interface
> without the underlying layers knowing. This is good networking =20
> architecture design, that simplifies
> implementations and makes them more robust, as well as makes using =20
> them operationally much
> easier.
>> 2) The introductory sections in this draft give a lot of discussion =20=

>> about fast fault detection. I
>> am puzzled by this given that GMPLS networks tend to run over =20
>> quickly self-healing
>> optical infrastructures. Is it therefore truly necessary to =20
>> motivate this work by
>> requiring fast CFMs?
>> It is right that frequent CCMs are not required if the layers below =20=

>> Ethernet handle protection. However, the ID focuses on Ethernet =20
>> LSPs where Ethernet is not just a single hop above a transport LSP. =20=

>> In this case Ethernet layer (for clarity GELS) may provide =20
>> protection for Ethernet LSPs. In any case,  the whole point of the =20=

>> ID is to allow for the appropriate configuration of CFM for =20
>> Ethernet LSPs with GMPLS.
>>
>> 3) This document does not cover E-LMI. Why not?
>> E-LMI is run over the MEF UNI. The ID focuses on Ethernet LSPs =20
>> within a network.
>>
>>
>> For the purposes of this document, we only discuss Ethernet OAM
>>    [IEEE-CFM] aspects that are relevant for the connectivity =20
>> monitoring
>>    of bidirectional point-to-point PBB-TE connections.
>>
>> 4) Is this the right place to define this document or should this =20
>> be done in GELS?
>> Well, GELS is done in CCAMP...this seems to be the right place.
>>
>>
>> 5)   In section 2 you make the following statement:
>>
>> 2.  GMPLS RSVP-TE Extensions
>>
>>     To simplify the configuration of connectivity monitoring, when an
>>    Ethernet LSP is signalled the associated MEPs should be =20
>> automatically
>>     established.  Further more, GMPLS signalling should be able to
>>   enable/disable connectivity monitoring of a particular Ethernet =20
>> LSP.
>>
>>
>> To my point in #1 above, you should use the native CFM =20
>> functionality over the ethernet interface and signal
>> those capabilities to the bridges at both ends using the IEEE CFM =20
>> signaling procedures (when and if they
>> are created).  If you want to test the underlying GMPLS LSP(s), =20
>> then you should use some
>> other mechanism defined for that layer such as the work stated in =20
>> draft-ali-ccamp-gmpls-LSP-ping-traceroute-00.txt
>> See the note to your point #1. There is no relation to the gmpls-=20
>> LSP-ping draft.
>
>           The point I am making is that perhaps it should.
>
>           --Tom
>
>
>>
>>
>>
>
>

--Apple-Mail-28--532988434
Content-Type: text/html;
	charset=WINDOWS-1252
Content-Transfer-Encoding: quoted-printable

<html><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; "><br><div><div>On Dec 4, 2007, =
at 7:33 PM, Diego Caviglia wrote:</div><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><span =
class=3D"Apple-style-span" style=3D"border-collapse: separate; color: =
rgb(0, 0, 0); font-family: Helvetica; font-size: 13px; font-style: =
normal; font-variant: normal; font-weight: normal; letter-spacing: =
normal; line-height: normal; orphans: 2; text-align: auto; text-indent: =
0px; text-transform: none; white-space: normal; widows: 2; word-spacing: =
0px; -webkit-border-horizontal-spacing: 0px; =
-webkit-border-vertical-spacing: 0px; =
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0; "><div lang=3D"EN-US" link=3D"blue" =
vlink=3D"blue" style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; "><div class=3D"Section1"><div =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman'; "><font size=3D"2" color=3D"navy" face=3D"Arial"><span =
style=3D"font-size: 10pt; font-family: Arial; color: navy; ">Hi =
Thomas,<o:p></o:p></span></font></div><div style=3D"margin-top: 0cm; =
margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman'; "><font size=3D"2" color=3D"navy" =
face=3D"Arial"><span style=3D"font-size: 10pt; font-family: Arial; =
color: navy; =
">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp; My understanding of the ID was that RSVP-TE can =
be used to =91piggyback=92 CFM set-up, otherwise the scenario is: usage =
of RSVP-TE to set-up the LSP and NMS (meaning everything that is not =
control plane) to enable to CFM for the =
LSP.</span></font></div></div></div></span></blockquote><div><br =
class=3D"webkit-block-placeholder"></div><span class=3D"Apple-tab-span" =
style=3D"white-space:pre">	</span>As I understand it, the IEEE is =
working on set-up of CFM (and MEPs), as are some vendors I know. =
*)</div><div>This to me seems like the right way to do =
this.</div><div><br><blockquote type=3D"cite"><span =
class=3D"Apple-style-span" style=3D"border-collapse: separate; color: =
rgb(0, 0, 0); font-family: Helvetica; font-size: 13px; font-style: =
normal; font-variant: normal; font-weight: normal; letter-spacing: =
normal; line-height: normal; orphans: 2; text-align: auto; text-indent: =
0px; text-transform: none; white-space: normal; widows: 2; word-spacing: =
0px; -webkit-border-horizontal-spacing: 0px; =
-webkit-border-vertical-spacing: 0px; =
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0; "><div lang=3D"EN-US" link=3D"blue" =
vlink=3D"blue" style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; "><div class=3D"Section1"><div =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman'; "><font size=3D"2" color=3D"navy" face=3D"Arial"><span =
style=3D"font-size: 10pt; font-family: Arial; color: navy; =
"><o:p></o:p></span></font></div><div style=3D"margin-top: 0cm; =
margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman'; "><span class=3D"Apple-style-span" =
style=3D"color: rgb(20, 79, 174); font-size: 13px; =
-webkit-text-stroke-width: -1; ">=46rom your comment I see that you=92re =
not happy with the fact the ID is so technology specific am I right? =
&nbsp;</span></div></div></div></span></blockquote><div><br =
class=3D"webkit-block-placeholder"></div><div><span =
class=3D"Apple-tab-span" style=3D"white-space:pre">	=
</span>Precisely; its gluing CFM to RSVP-TE/GMPLS as a =
transport.&nbsp;<br =
class=3D"webkit-block-placeholder"></div><br><blockquote =
type=3D"cite"><span class=3D"Apple-style-span" style=3D"border-collapse: =
separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 13px; =
font-style: normal; font-variant: normal; font-weight: normal; =
letter-spacing: normal; line-height: normal; orphans: 2; text-align: =
auto; text-indent: 0px; text-transform: none; white-space: normal; =
widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; =
-webkit-border-vertical-spacing: 0px; =
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0; "><div lang=3D"EN-US" link=3D"blue" =
vlink=3D"blue" style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; "><div class=3D"Section1"><div =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman'; "><span class=3D"Apple-style-span" style=3D"color: rgb(20, 79, =
174); font-size: 13px; -webkit-text-stroke-width: -1; ">If yes do you =
agree with the fact that could be useful in general to use the same =
signaling =91session=92 to set-up the LSP and to enable the =
CFM?</span></div></div></div></span></blockquote><div><br =
class=3D"webkit-block-placeholder"></div><span class=3D"Apple-tab-span" =
style=3D"white-space:pre">	</span>No, I do not agree. &nbsp;Again, =
if CFM is to be set-up e2e, let the IEEE define this. Leave GMPLS to =
CCAMP.</div><div><br class=3D"webkit-block-placeholder"></div><div><span =
class=3D"Apple-tab-span" style=3D"white-space:pre">	=
</span>--Tom</div><div><br =
class=3D"webkit-block-placeholder"></div><div><br =
class=3D"webkit-block-placeholder"></div><div><br><blockquote =
type=3D"cite"><span class=3D"Apple-style-span" style=3D"border-collapse: =
separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 13px; =
font-style: normal; font-variant: normal; font-weight: normal; =
letter-spacing: normal; line-height: normal; orphans: 2; text-align: =
auto; text-indent: 0px; text-transform: none; white-space: normal; =
widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; =
-webkit-border-vertical-spacing: 0px; =
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0; "><div lang=3D"EN-US" link=3D"blue" =
vlink=3D"blue" style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; "><div class=3D"Section1"><div =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman'; "><font size=3D"2" color=3D"navy" face=3D"Arial"><span =
style=3D"font-size: 10pt; font-family: Arial; color: navy; =
"><o:p>&nbsp;<span class=3D"Apple-style-span" style=3D"color: rgb(20, =
79, 174); -webkit-text-stroke-width: -1; ">Best =
Regards</span></o:p></span></font></div><div style=3D"margin-top: 0cm; =
margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman'; "><font size=3D"2" color=3D"navy" =
face=3D"Arial"><span style=3D"font-size: 10pt; font-family: Arial; =
color: navy; "><br>Diego<o:p></o:p></span></font></div><div =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman'; "><font size=3D"2" color=3D"navy" face=3D"Arial"><span =
style=3D"font-size: 10pt; font-family: Arial; color: navy; =
"><o:p>&nbsp;</o:p></span></font></div><div style=3D"border-top-style: =
none; border-right-style: none; border-bottom-style: none; border-width: =
initial; border-color: initial; border-left-style: solid; =
border-left-color: blue; border-left-width: 1.5pt; padding-top: 0cm; =
padding-right: 0cm; padding-bottom: 0cm; padding-left: 4pt; "><div><div =
class=3D"MsoNormal" align=3D"center" style=3D"text-align: center; =
margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; margin-bottom: =
0.0001pt; font-size: 12pt; font-family: 'Times New Roman'; "><font =
size=3D"3" face=3D"Times New Roman"><span style=3D"font-size: 12pt; =
"><hr size=3D"2" width=3D"100%" align=3D"center" =
tabindex=3D"-1"></span></font></div><div style=3D"margin-top: 0cm; =
margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman'; "><b><font size=3D"2" =
face=3D"Tahoma"><span style=3D"font-size: 10pt; font-family: Tahoma; =
font-weight: bold; ">From:</span></font></b><font size=3D"2" =
face=3D"Tahoma"><span style=3D"font-size: 10pt; font-family: Tahoma; =
"><span class=3D"Apple-converted-space">&nbsp;</span><a =
href=3D"mailto:[email-masked]">[email-masked]</a> =
[<a href=3D"mailto:[email-masked]" style=3D"color: blue; =
text-decoration: underline; ">mailto:[email-masked]</a>]<span =
class=3D"Apple-converted-space">&nbsp;</span><b><span =
style=3D"font-weight: bold; ">On Behalf Of<span =
class=3D"Apple-converted-space">&nbsp;</span></span></b>Thomas =
Nadeau<br><b><span style=3D"font-weight: bold; ">Sent:</span></b><span =
class=3D"Apple-converted-space">&nbsp;</span>marted=EC 4 dicembre 2007 =
11.30<br><b><span style=3D"font-weight: bold; ">To:</span></b><span =
class=3D"Apple-converted-space">&nbsp;</span>Attila Takacs<br><b><span =
style=3D"font-weight: bold; ">Cc:</span></b><span =
class=3D"Apple-converted-space">&nbsp;</span><a =
href=3D"mailto:[email-masked]" style=3D"color: blue; =
text-decoration: underline; ">[email-masked]</a>;<span =
class=3D"Apple-converted-space">&nbsp;</span><a =
href=3D"mailto:[email-masked]" style=3D"color: blue; =
text-decoration: underline; ">[email-masked]</a><br><b><span =
style=3D"font-weight: bold; ">Subject:</span></b><span =
class=3D"Apple-converted-space">&nbsp;</span>Re: =
draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt</span></font><o:p></o:p></di=
v></div><div style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: =
0cm; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman'; "><font size=3D"3" face=3D"Times New Roman"><span =
style=3D"font-size: 12pt; "><o:p>&nbsp;</o:p></span></font></div><div =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman'; "><font size=3D"3" face=3D"Times New Roman"><span =
style=3D"font-size: 12pt; =
"><o:p>&nbsp;</o:p></span></font></div><div><div><div style=3D"margin-top:=
 0cm; margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; =
font-size: 12pt; font-family: 'Times New Roman'; "><font size=3D"3" =
face=3D"Times New Roman"><span style=3D"font-size: 12pt; ">On Dec 4, =
2007, at 1:51 PM, Attila Takacs =
wrote:<o:p></o:p></span></font></div></div><div style=3D"margin-top: =
0cm; margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; =
font-size: 12pt; font-family: 'Times New Roman'; "><font size=3D"3" =
face=3D"Times New Roman"><span style=3D"font-size: 12pt; =
"><br><br><o:p></o:p></span></font></div><div style=3D"word-wrap: =
break-word; "><div><div style=3D"margin-top: 0cm; margin-right: 0cm; =
margin-left: 0cm; margin-bottom: 0.0001pt; font-size: 12pt; font-family: =
'Times New Roman'; "><font size=3D"2" color=3D"blue" face=3D"Arial"><span =
style=3D"font-size: 10pt; font-family: Arial; color: blue; ">Hi =
Thomas,</span></font><o:p></o:p></div></div><div><div style=3D"margin-top:=
 0cm; margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; =
font-size: 12pt; font-family: 'Times New Roman'; "><font size=3D"3" =
face=3D"Times New Roman"><span style=3D"font-size: 12pt; =
">&nbsp;<o:p></o:p></span></font></div></div><div><div =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman'; "><font size=3D"2" color=3D"blue" face=3D"Arial"><span =
style=3D"font-size: 10pt; font-family: Arial; color: blue; ">Thank =
you&nbsp;for the comments!</span></font><o:p></o:p></div></div><div><div =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman'; "><font size=3D"2" color=3D"blue" face=3D"Arial"><span =
style=3D"font-size: 10pt; font-family: Arial; color: blue; ">Please see =
answers inline.</span></font><o:p></o:p></div></div><div><div =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman'; "><font size=3D"3" face=3D"Times New Roman"><span =
style=3D"font-size: 12pt; =
">&nbsp;<o:p></o:p></span></font></div></div><div><div =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman'; "><font size=3D"2" color=3D"blue" face=3D"Arial"><span =
style=3D"font-size: 10pt; font-family: Arial; color: blue; ">Best =
regards,<br>Attila</span></font><o:p></o:p></div></div><blockquote =
style=3D"border-top-style: none; border-right-style: none; =
border-bottom-style: none; border-width: initial; border-color: initial; =
border-left-style: solid; border-left-color: blue; border-left-width: =
1.5pt; padding-top: 0cm; padding-right: 0cm; padding-bottom: 0cm; =
padding-left: 4pt; margin-left: 3.75pt; margin-top: 5pt; margin-right: =
0cm; margin-bottom: 5pt; "><div style=3D"margin-top: 0cm; margin-right: =
0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: 12pt; =
font-family: 'Times New Roman'; "><font size=3D"3" face=3D"Times New =
Roman"><span style=3D"font-size: 12pt; =
"><o:p>&nbsp;</o:p></span></font></div><div class=3D"MsoNormal" =
align=3D"center" style=3D"text-align: center; margin-top: 0cm; =
margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman'; "><font size=3D"3" face=3D"Times =
New Roman"><span style=3D"font-size: 12pt; "><hr size=3D"2" width=3D"100%"=
 align=3D"center" tabindex=3D"-1"></span></font></div><div =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman'; "><b><font size=3D"2" face=3D"Tahoma"><span style=3D"font-size: =
10pt; font-family: Tahoma; font-weight: bold; =
">From:</span></font></b><font size=3D"2" face=3D"Tahoma"><span =
style=3D"font-size: 10pt; font-family: Tahoma; "><span =
class=3D"Apple-converted-space">&nbsp;</span>Thomas Nadeau [<a =
href=3D"mailto:[email-masked]" style=3D"color: blue; =
text-decoration: underline; ">mailto:[email-masked]</a>]<span =
class=3D"Apple-converted-space">&nbsp;</span><br><b><span =
style=3D"font-weight: bold; ">Sent:</span></b><span =
class=3D"Apple-converted-space">&nbsp;</span>Tuesday, December 04, 2007 =
2:58 PM<br><b><span style=3D"font-weight: bold; ">To:</span></b><span =
class=3D"Apple-converted-space">&nbsp;</span><a =
href=3D"mailto:[email-masked]" style=3D"color: blue; =
text-decoration: underline; ">[email-masked]</a><br><b><span =
style=3D"font-weight: bold; ">Cc:</span></b><span =
class=3D"Apple-converted-space">&nbsp;</span>Attila Takacs;<span =
class=3D"Apple-converted-space">&nbsp;</span><a =
href=3D"mailto:[email-masked]" style=3D"color: blue; =
text-decoration: underline; ">[email-masked]</a><br><b><span =
style=3D"font-weight: bold; ">Subject:</span></b><span =
class=3D"Apple-converted-space">&nbsp;</span>draft-takacs-ccamp-rsvp-te-et=
h-oam-ext-00.txt</span></font><o:p></o:p></div><div style=3D"margin-top: =
0cm; margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; =
font-size: 12pt; font-family: 'Times New Roman'; "><font size=3D"3" =
face=3D"Times New Roman"><span style=3D"font-size: 12pt; =
"><o:p>&nbsp;</o:p></span></font></div><div><div style=3D"margin-top: =
0cm; margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; =
font-size: 12pt; font-family: 'Times New Roman'; "><font size=3D"3" =
face=3D"Times New Roman"><span style=3D"font-size: 12pt; =
"><o:p>&nbsp;</o:p></span></font></div></div><div><div =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman'; "><font size=3D"3" face=3D"Times New Roman"><span =
style=3D"font-size: 12pt; ">After reading this draft, I have some =
questions/comments.<o:p></o:p></span></font></div></div><div><div =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman'; "><font size=3D"3" face=3D"Times New Roman"><span =
style=3D"font-size: 12pt; =
"><o:p>&nbsp;</o:p></span></font></div></div><div><div =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman'; "><font size=3D"3" face=3D"Times New Roman"><span =
style=3D"font-size: 12pt; ">1) Overall,&nbsp;I am concerned that the =
definition of a new TLV and these procedures =
represent&nbsp;<o:p></o:p></span></font></div></div><div><div =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman'; "><font size=3D"3" face=3D"Times New Roman"><span =
style=3D"font-size: 12pt; ">what amounts to a laying violation and ask =
that the ADs take a look at =
this<o:p></o:p></span></font></div></div><div><div style=3D"margin-top: =
0cm; margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; =
font-size: 12pt; font-family: 'Times New Roman'; "><font size=3D"3" =
face=3D"Times New Roman"><span style=3D"font-size: 12pt; ">approach =
closely. This is similar to the now-rejected approach that was =
proposed<o:p></o:p></span></font></div></div><div><div =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman'; "><font size=3D"3" face=3D"Times New Roman"><span =
style=3D"font-size: 12pt; ">in the l2vpn WG about munging CFM + PWs. =
&nbsp;To my reading, this is =
essentially<o:p></o:p></span></font></div></div><div><div =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman'; "><font size=3D"3" face=3D"Times New Roman"><span =
style=3D"font-size: 12pt; ">the same thing. If you want to run CFM, run =
it natively over the ethernet interfaces =
and<o:p></o:p></span></font></div></div><div><div style=3D"margin-top: =
0cm; margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; =
font-size: 12pt; font-family: 'Times New Roman'; "><font size=3D"3" =
face=3D"Times New Roman"><span style=3D"font-size: 12pt; ">have no =
regard for the underlying topology (GMPLS, PWs, etc...) otherwise =
you&nbsp;<o:p></o:p></span></font></div></div><div><div =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman'; "><font size=3D"3" face=3D"Times New Roman"><span =
style=3D"font-size: 12pt; ">will be creating a mess for implementations =
and interoperability.&nbsp;</span></font><font size=3D"2" color=3D"blue" =
face=3D"Arial"><span style=3D"font-size: 10pt; font-family: Arial; =
color: blue; =
">&nbsp;</span></font><o:p></o:p></div></div></blockquote><div><div =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman'; "><font size=3D"2" color=3D"blue" face=3D"Arial"><span =
style=3D"font-size: 10pt; font-family: Arial; color: blue; ">The =
application&nbsp;of the draft is exactly for what you are calling out: =
when CFM is run natively over the Ethernet interfaces. The document =
focuses on GELS and Ethernet LSPs.&nbsp;That is,&nbsp;to establish CFM =
entities for GMPLS controlled Ethernet LSPs.&nbsp;Hence, I think there =
is no layer violation =
issue.</span></font><o:p></o:p></div></div></div><div><div =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman'; "><font size=3D"3" face=3D"Times New Roman"><span =
style=3D"font-size: 12pt; =
"><o:p>&nbsp;</o:p></span></font></div></div><div style=3D"margin-top: =
0cm; margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; =
font-size: 12pt; font-family: 'Times New Roman'; "><span =
class=3D"apple-tab-span"><font size=3D"3" face=3D"Times New Roman"><span =
style=3D"font-size: 12pt; =
">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span =
class=3D"Apple-converted-space">&nbsp;</span></span></font></span>This =
solution specifically only works for GMPLS ethernet LSPs, right? =
&nbsp;<o:p></o:p></div></div><div><div style=3D"margin-top: 0cm; =
margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman'; "><font size=3D"3" face=3D"Times =
New Roman"><span style=3D"font-size: 12pt; ">What do I do if I want to =
set up MPLS ethernet LSPs (i.e.: PWs)&nbsp;and do CFM over those? =
Oh,<o:p></o:p></span></font></div></div><div><div style=3D"margin-top: =
0cm; margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; =
font-size: 12pt; font-family: 'Times New Roman'; "><font size=3D"3" =
face=3D"Times New Roman"><span style=3D"font-size: 12pt; ">that is a =
different solution, right? &nbsp;Then what do I do if I want to run CFM =
over some new type of<o:p></o:p></span></font></div></div><div><div =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman'; "><font size=3D"3" face=3D"Times New Roman"><span =
style=3D"font-size: 12pt; ">ethernet LSP in the future? More protocol =
hacks? &nbsp;The point is to use CFM over an ethernet =
interface<o:p></o:p></span></font></div></div><div><div =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman'; "><font size=3D"3" face=3D"Times New Roman"><span =
style=3D"font-size: 12pt; ">without the underlying layers knowing. This =
is good networking architecture design, that =
simplifies<o:p></o:p></span></font></div></div><div><div =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman'; "><font size=3D"3" face=3D"Times New Roman"><span =
style=3D"font-size: 12pt; ">implementations and makes them more robust, =
as well as makes using them operationally =
much<o:p></o:p></span></font></div></div><div><div style=3D"margin-top: =
0cm; margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; =
font-size: 12pt; font-family: 'Times New Roman'; "><font size=3D"3" =
face=3D"Times New Roman"><span style=3D"font-size: 12pt; =
">easier.&nbsp;<o:p></o:p></span></font></div></div><div><blockquote =
type=3D"cite" style=3D"margin-top: 5pt; margin-bottom: 5pt; "><div =
style=3D"word-wrap: break-word; "><blockquote style=3D"border-top-style: =
none; border-right-style: none; border-bottom-style: none; border-width: =
initial; border-color: initial; border-left-style: solid; =
border-left-color: blue; border-left-width: 1.5pt; padding-top: 0cm; =
padding-right: 0cm; padding-bottom: 0cm; padding-left: 4pt; margin-left: =
3.75pt; margin-top: 5pt; margin-right: 0cm; margin-bottom: 5pt; =
"><div><div style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: =
0cm; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman'; "><font size=3D"3" face=3D"Times New Roman"><span =
style=3D"font-size: 12pt; ">2)&nbsp;The introductory sections in this =
draft give a lot of discussion about fast fault detection. =
I<o:p></o:p></span></font></div></div><div><div style=3D"margin-top: =
0cm; margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; =
font-size: 12pt; font-family: 'Times New Roman'; "><font size=3D"3" =
face=3D"Times New Roman"><span style=3D"font-size: 12pt; ">am puzzled by =
this given that GMPLS networks tend to run over quickly =
self-healing<o:p></o:p></span></font></div></div><div><div =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman'; "><font size=3D"3" face=3D"Times New Roman"><span =
style=3D"font-size: 12pt; ">optical infrastructures. Is it =
therefore&nbsp;truly&nbsp;necessary to motivate this work =
by<o:p></o:p></span></font></div></div><div><div style=3D"margin-top: =
0cm; margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; =
font-size: 12pt; font-family: 'Times New Roman'; "><font size=3D"3" =
face=3D"Times New Roman"><span style=3D"font-size: 12pt; ">requiring =
fast CFMs?<o:p></o:p></span></font></div></div></blockquote><div><div =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman'; "><font size=3D"2" color=3D"blue" face=3D"Arial"><span =
style=3D"font-size: 10pt; font-family: Arial; color: blue; ">It is right =
that frequent CCMs are not required if the layers below Ethernet handle =
protection. However, the ID focuses on Ethernet LSPs where Ethernet =
is&nbsp;not just a single hop&nbsp;above a transport LSP.&nbsp;In this =
case&nbsp;Ethernet layer (for clarity GELS) may provide protection for =
Ethernet LSPs.&nbsp;In any case,&nbsp; the whole point of the ID is to =
allow for the appropriate configuration of CFM for Ethernet LSPs with =
GMPLS.</span></font><o:p></o:p></div></div><div><div style=3D"margin-top: =
0cm; margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; =
font-size: 12pt; font-family: 'Times New Roman'; "><font size=3D"3" =
face=3D"Times New Roman"><span style=3D"font-size: 12pt; =
"><o:p>&nbsp;</o:p></span></font></div></div><blockquote =
style=3D"border-top-style: none; border-right-style: none; =
border-bottom-style: none; border-width: initial; border-color: initial; =
border-left-style: solid; border-left-color: blue; border-left-width: =
1.5pt; padding-top: 0cm; padding-right: 0cm; padding-bottom: 0cm; =
padding-left: 4pt; margin-left: 3.75pt; margin-top: 5pt; margin-right: =
0cm; margin-bottom: 5pt; "><div><div style=3D"margin-top: 0cm; =
margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman'; "><font size=3D"3" face=3D"Times =
New Roman"><span style=3D"font-size: 12pt; ">3) This document does not =
cover E-LMI. Why =
not?<o:p></o:p></span></font></div></div></blockquote><div><div =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman'; "><font size=3D"2" color=3D"blue" face=3D"Arial"><span =
style=3D"font-size: 10pt; font-family: Arial; color: blue; ">E-LMI is =
run over the MEF UNI. The&nbsp;ID focuses on Ethernet LSPs within a =
network.</span></font><o:p></o:p></div></div><div><div =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman'; "><font size=3D"3" face=3D"Times New Roman"><span =
style=3D"font-size: 12pt; =
">&nbsp;<o:p></o:p></span></font></div></div><div><div =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman'; "><font size=3D"3" face=3D"Times New Roman"><span =
style=3D"font-size: 12pt; =
"><o:p>&nbsp;</o:p></span></font></div></div><blockquote =
style=3D"border-top-style: none; border-right-style: none; =
border-bottom-style: none; border-width: initial; border-color: initial; =
border-left-style: solid; border-left-color: blue; border-left-width: =
1.5pt; padding-top: 0cm; padding-right: 0cm; padding-bottom: 0cm; =
padding-left: 4pt; margin-left: 3.75pt; margin-top: 5pt; margin-right: =
0cm; margin-bottom: 5pt; "><div><div style=3D"margin-top: 0cm; =
margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman'; "><span =
class=3D"apple-style-span"><font size=3D"1" face=3D"Times New =
Roman"><span style=3D"font-size: 9pt; ">For the purposes of this =
document, we only discuss Ethernet =
OAM</span></font></span><o:p></o:p></div></div><div><div =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman'; "><font size=3D"1" face=3D"Helvetica"><span style=3D"font-size: =
9pt; font-family: Helvetica; ">&nbsp;&nbsp; [IEEE-CFM] aspects that are =
relevant for the connectivity =
monitoring<o:p></o:p></span></font></div></div><div><div =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman'; "><font size=3D"1" face=3D"Helvetica"><span style=3D"font-size: =
9pt; font-family: Helvetica; ">&nbsp;&nbsp; of bidirectional =
point-to-point PBB-TE connections. =
&nbsp;<o:p></o:p></span></font></div></div><div><div style=3D"margin-top: =
0cm; margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; =
font-size: 12pt; font-family: 'Times New Roman'; "><font size=3D"1" =
face=3D"Helvetica"><span style=3D"font-size: 9pt; font-family: =
Helvetica; "><o:p>&nbsp;</o:p></span></font></div></div><div><div =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman'; "><font size=3D"1" face=3D"Helvetica"><span style=3D"font-size: =
9pt; font-family: Helvetica; ">4) Is this the right place to define this =
document or should this be done in =
GELS?<o:p></o:p></span></font></div></div></blockquote><div><div =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman'; "><font size=3D"2" color=3D"blue" face=3D"Arial"><span =
style=3D"font-size: 10pt; font-family: Arial; color: blue; ">Well, GELS =
is done in CCAMP...this seems to be the right =
place.</span></font><o:p></o:p></div></div><blockquote =
style=3D"border-top-style: none; border-right-style: none; =
border-bottom-style: none; border-width: initial; border-color: initial; =
border-left-style: solid; border-left-color: blue; border-left-width: =
1.5pt; padding-top: 0cm; padding-right: 0cm; padding-bottom: 0cm; =
padding-left: 4pt; margin-left: 3.75pt; margin-top: 5pt; margin-right: =
0cm; margin-bottom: 5pt; "><div><div style=3D"margin-top: 0cm; =
margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman'; "><font size=3D"3" face=3D"Times =
New Roman"><span style=3D"font-size: 12pt; =
">&nbsp;<o:p></o:p></span></font></div></div><div><div =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman'; "><font size=3D"1" face=3D"Helvetica"><span style=3D"font-size: =
9pt; font-family: Helvetica; =
"><o:p>&nbsp;</o:p></span></font></div></div><div><div =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman'; "><font size=3D"1" face=3D"Helvetica"><span style=3D"font-size: =
9pt; font-family: Helvetica; ">5) &nbsp; In section 2 you make the =
following statement:<o:p></o:p></span></font></div></div><div><div =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman'; "><font size=3D"1" face=3D"Helvetica"><span style=3D"font-size: =
9pt; font-family: Helvetica; =
"><o:p>&nbsp;</o:p></span></font></div></div><div><div =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman'; "><font size=3D"1" face=3D"Helvetica"><span style=3D"font-size: =
9pt; font-family: Helvetica; ">2.&nbsp; GMPLS RSVP-TE =
Extensions<o:p></o:p></span></font></div></div><div style=3D"min-height: =
14px; "><div style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: =
0cm; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman'; "><font size=3D"1" face=3D"Helvetica"><span style=3D"font-size: =
9pt; font-family: Helvetica; =
"><o:p>&nbsp;</o:p></span></font></div></div><div><div =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman'; "><font size=3D"1" face=3D"Helvetica"><span style=3D"font-size: =
9pt; font-family: Helvetica; ">&nbsp;<span class=3D"apple-tab-span"><span =
class=3D"Apple-converted-space">&nbsp;</span></span>&nbsp; To simplify =
the configuration of connectivity monitoring, when =
an<o:p></o:p></span></font></div></div><div><div style=3D"margin-top: =
0cm; margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; =
font-size: 12pt; font-family: 'Times New Roman'; "><font size=3D"1" =
face=3D"Helvetica"><span style=3D"font-size: 9pt; font-family: =
Helvetica; ">&nbsp;&nbsp; Ethernet LSP is signalled the associated MEPs =
should be automatically<o:p></o:p></span></font></div></div><div><div =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman'; "><font size=3D"1" face=3D"Helvetica"><span style=3D"font-size: =
9pt; font-family: Helvetica; ">&nbsp;<span class=3D"apple-tab-span"><span =
class=3D"Apple-converted-space">&nbsp;</span></span>&nbsp; =
established.&nbsp; Further more, GMPLS signalling should be able =
to<o:p></o:p></span></font></div></div><div><div style=3D"margin-top: =
0cm; margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; =
font-size: 12pt; font-family: 'Times New Roman'; "><font size=3D"1" =
face=3D"Helvetica"><span style=3D"font-size: 9pt; font-family: =
Helvetica; ">&nbsp;&nbsp;enable/disable connectivity monitoring of a =
particular Ethernet LSP.<o:p></o:p></span></font></div></div><div><div =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman'; "><font size=3D"1" face=3D"Helvetica"><span style=3D"font-size: =
9pt; font-family: Helvetica; =
"><o:p>&nbsp;</o:p></span></font></div></div><div><div =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman'; "><font size=3D"1" face=3D"Helvetica"><span style=3D"font-size: =
9pt; font-family: Helvetica; =
"><o:p>&nbsp;</o:p></span></font></div></div><div><div =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman'; "><font size=3D"1" face=3D"Helvetica"><span style=3D"font-size: =
9pt; font-family: Helvetica; ">To my point in #1 above, you should use =
the native CFM functionality over the ethernet interface and =
signal<o:p></o:p></span></font></div></div><div><div style=3D"margin-top: =
0cm; margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; =
font-size: 12pt; font-family: 'Times New Roman'; "><font size=3D"1" =
face=3D"Helvetica"><span style=3D"font-size: 9pt; font-family: =
Helvetica; ">those capabilities to the bridges at both ends using the =
IEEE CFM signaling procedures (when and if =
they<o:p></o:p></span></font></div></div><div><div style=3D"margin-top: =
0cm; margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; =
font-size: 12pt; font-family: 'Times New Roman'; "><font size=3D"1" =
face=3D"Helvetica"><span style=3D"font-size: 9pt; font-family: =
Helvetica; ">are created). &nbsp;If you want to test the underlying =
GMPLS LSP(s), then you should use =
some<o:p></o:p></span></font></div></div><div><div style=3D"margin-top: =
0cm; margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; =
font-size: 12pt; font-family: 'Times New Roman'; "><font size=3D"1" =
face=3D"Helvetica"><span style=3D"font-size: 9pt; font-family: =
Helvetica; ">other mechanism defined for that layer such as the work =
stated in&nbsp;</span></font><span class=3D"apple-style-span"><b><font =
size=3D"2" face=3D"Helvetica"><span style=3D"font-size: 10pt; =
font-family: Helvetica; font-weight: bold; =
">draft-ali-ccamp-gmpls-LSP-ping-traceroute-00.txt</span></font></b></span=
><font size=3D"1" face=3D"Helvetica"><span style=3D"font-size: 9pt; =
font-family: Helvetica; =
"><o:p></o:p></span></font></div></div></blockquote><div><div =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman'; "><font size=3D"2" color=3D"blue" face=3D"Arial"><span =
style=3D"font-size: 10pt; font-family: Arial; color: blue; ">See the =
note&nbsp;to your point #1. There is no relation&nbsp;to the =
gmpls-LSP-ping draft.&nbsp;</span></font><font size=3D"1" =
face=3D"Helvetica"><span style=3D"font-size: 9pt; font-family: =
Helvetica; =
"><o:p></o:p></span></font></div></div></div></blockquote><div><div =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman'; "><font size=3D"3" face=3D"Times New Roman"><span =
style=3D"font-size: 12pt; =
"><o:p>&nbsp;</o:p></span></font></div></div><div style=3D"margin-top: =
0cm; margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; =
font-size: 12pt; font-family: 'Times New Roman'; "><span =
class=3D"apple-tab-span"><font size=3D"3" face=3D"Times New Roman"><span =
style=3D"font-size: 12pt; =
">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span =
class=3D"Apple-converted-space">&nbsp;</span></span></font></span>The =
point I am making is that perhaps it =
should.<o:p></o:p></div></div><div><div style=3D"margin-top: 0cm; =
margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman'; "><font size=3D"3" face=3D"Times =
New Roman"><span style=3D"font-size: 12pt; =
"><o:p>&nbsp;</o:p></span></font></div></div><div><div =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman'; "><span class=3D"apple-tab-span"><font size=3D"3" face=3D"Times =
New Roman"><span style=3D"font-size: 12pt; =
">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span =
class=3D"Apple-converted-space">&nbsp;</span></span></font></span>--Tom<o:=
p></o:p></div></div><div><div style=3D"margin-top: 0cm; margin-right: =
0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: 12pt; =
font-family: 'Times New Roman'; "><font size=3D"3" face=3D"Times New =
Roman"><span style=3D"font-size: 12pt; =
"><o:p>&nbsp;</o:p></span></font></div></div><div><div =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman'; "><font size=3D"3" face=3D"Times New Roman"><span =
style=3D"font-size: 12pt; =
"><o:p>&nbsp;</o:p></span></font></div></div><div><blockquote =
type=3D"cite" style=3D"margin-top: 5pt; margin-bottom: 5pt; "><div =
style=3D"word-wrap: break-word; "><div><div style=3D"margin-top: 0cm; =
margin-right: 0cm; margin-left: 0cm; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman'; "><font size=3D"1" =
face=3D"Helvetica"><span style=3D"font-size: 9pt; font-family: =
Helvetica; "><o:p>&nbsp;</o:p></span></font></div></div><div><div =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman'; "><font size=3D"1" face=3D"Helvetica"><span style=3D"font-size: =
9pt; font-family: Helvetica; =
">&nbsp;<o:p></o:p></span></font></div></div><div><div =
style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman'; "><font size=3D"1" face=3D"Helvetica"><span style=3D"font-size: =
9pt; font-family: Helvetica; =
">&nbsp;<o:p></o:p></span></font></div></div></div></blockquote></div><div=
 style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman'; "><font size=3D"3" face=3D"Times New Roman"><span =
style=3D"font-size: 12pt; =
"><o:p>&nbsp;</o:p></span></font></div></div></div></div></span></blockquo=
te></div><br></body></html>=

--Apple-Mail-28--532988434--

Delivery-date: Wed, 05 Dec 2007 00:36:25 +0000
Content-class: urn:content-classes:message
Subject: RE: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt
Date: Wed, 5 Dec 2007 01:33:41 +0100
From: "Diego Caviglia" <[email-masked]>
To: "Thomas Nadeau" <[email-masked]>, "Attila Takacs" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C836D6.7D4FEF53
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Thomas,

                 My understanding of the ID was that RSVP-TE can be used =
to 'piggyback' CFM set-up, otherwise the scenario is: usage of RSVP-TE =
to set-up the LSP and NMS (meaning everything that is not control plane) =
to enable to CFM for the LSP.

=20

>From your comment I see that you're not happy with the fact the ID is so =
technology specific am I right?  If yes do you agree with the fact that =
could be useful in general to use the same signaling 'session' to set-up =
the LSP and to enable the CFM?

=20

Best Regards

Diego

=20

________________________________

From: [email-masked] [mailto:[email-masked]] On =
Behalf Of Thomas Nadeau
Sent: marted=EC 4 dicembre 2007 11.30
To: Attila Takacs
Cc: [email-masked]; [email-masked]
Subject: Re: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt

=20

=20

On Dec 4, 2007, at 1:51 PM, Attila Takacs wrote:

Hi Thomas,

=20

Thank you for the comments!

Please see answers inline.

=20

Best regards,
Attila

	=20

=09
________________________________

	From: Thomas Nadeau [mailto:[email-masked]]=20
	Sent: Tuesday, December 04, 2007 2:58 PM
	To: [email-masked]
	Cc: Attila Takacs; [email-masked]
	Subject: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt

	=20

	=20

	After reading this draft, I have some questions/comments.

	=20

	1) Overall, I am concerned that the definition of a new TLV and these =
procedures represent=20

	what amounts to a laying violation and ask that the ADs take a look at =
this

	approach closely. This is similar to the now-rejected approach that was =
proposed

	in the l2vpn WG about munging CFM + PWs.  To my reading, this is =
essentially

	the same thing. If you want to run CFM, run it natively over the =
ethernet interfaces and

	have no regard for the underlying topology (GMPLS, PWs, etc...) =
otherwise you=20

	will be creating a mess for implementations and interoperability. =20

The application of the draft is exactly for what you are calling out: =
when CFM is run natively over the Ethernet interfaces. The document =
focuses on GELS and Ethernet LSPs. That is, to establish CFM entities =
for GMPLS controlled Ethernet LSPs. Hence, I think there is no layer =
violation issue.

=20

          This solution specifically only works for GMPLS ethernet LSPs, =
right? =20

What do I do if I want to set up MPLS ethernet LSPs (i.e.: PWs) and do =
CFM over those? Oh,

that is a different solution, right?  Then what do I do if I want to run =
CFM over some new type of

ethernet LSP in the future? More protocol hacks?  The point is to use =
CFM over an ethernet interface

without the underlying layers knowing. This is good networking =
architecture design, that simplifies

implementations and makes them more robust, as well as makes using them =
operationally much

easier.=20

		2) The introductory sections in this draft give a lot of discussion =
about fast fault detection. I

		am puzzled by this given that GMPLS networks tend to run over quickly =
self-healing

		optical infrastructures. Is it therefore truly necessary to motivate =
this work by

		requiring fast CFMs?

	It is right that frequent CCMs are not required if the layers below =
Ethernet handle protection. However, the ID focuses on Ethernet LSPs =
where Ethernet is not just a single hop above a transport LSP. In this =
case Ethernet layer (for clarity GELS) may provide protection for =
Ethernet LSPs. In any case,  the whole point of the ID is to allow for =
the appropriate configuration of CFM for Ethernet LSPs with GMPLS.

	=20

		3) This document does not cover E-LMI. Why not?

	E-LMI is run over the MEF UNI. The ID focuses on Ethernet LSPs within a =
network.

	=20

	=20

		For the purposes of this document, we only discuss Ethernet OAM

		   [IEEE-CFM] aspects that are relevant for the connectivity =
monitoring

		   of bidirectional point-to-point PBB-TE connections. =20

		=20

		4) Is this the right place to define this document or should this be =
done in GELS?

	Well, GELS is done in CCAMP...this seems to be the right place.

		=20

		=20

		5)   In section 2 you make the following statement:

		=20

		2.  GMPLS RSVP-TE Extensions

		=20

		    To simplify the configuration of connectivity monitoring, when an

		   Ethernet LSP is signalled the associated MEPs should be =
automatically

		    established.  Further more, GMPLS signalling should be able to

		  enable/disable connectivity monitoring of a particular Ethernet LSP.

		=20

		=20

		To my point in #1 above, you should use the native CFM functionality =
over the ethernet interface and signal

		those capabilities to the bridges at both ends using the IEEE CFM =
signaling procedures (when and if they

		are created).  If you want to test the underlying GMPLS LSP(s), then =
you should use some

		other mechanism defined for that layer such as the work stated in =
draft-ali-ccamp-gmpls-LSP-ping-traceroute-00.txt

	See the note to your point #1. There is no relation to the =
gmpls-LSP-ping draft.=20

=20

          The point I am making is that perhaps it should.

=20

          --Tom

=20

=20

	=20

	=20

	=20

=20

------_=_NextPart_001_01C836D6.7D4FEF53
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<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]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Helvetica;
	panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	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.EmailStyle19
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dblue style=3D'word-wrap: =
break-word;-webkit-nbsp-mode: space;
-webkit-line-break: after-white-space'>

<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 =
Thomas,<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'>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 My understanding of the
ID was that RSVP-TE can be used to &#8216;piggyback&#8217; CFM set-up,
otherwise the scenario is: usage of RSVP-TE to set-up the LSP and NMS =
(meaning everything
that is not control plane) to enable to CFM for the =
LSP.<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'>From your comment I see that =
you&#8217;re
not happy with the fact the ID is so technology specific am I right? =
=A0If yes do
you agree with the fact that could be useful in general to use the same =
signaling
&#8216;session&#8217; to set-up the LSP and to enable the =
CFM?<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'>Best =
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'><br>
Diego<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 style=3D'border:none;border-left:solid blue 1.5pt;padding:0cm 0cm =
0cm 4.0pt'>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=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-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>Thomas Nadeau<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> marted=EC 4 =
dicembre 2007
11.30<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Attila Takacs<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> [email-masked];
[email-masked]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> Re:
draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt</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=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>On Dec 4, 2007, at 1:51 PM, Attila Takacs =
wrote:<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'><br>
<br>
<o:p></o:p></span></font></p>

<div style=3D'WORD-WRAP: break-word;webkit-nbsp-mode: =
space;webkit-line-break: after-white-space'>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Hi =
Thomas,</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'>Thank you&nbsp;for the =
comments!</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'>Please see answers =
inline.</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'>Best regards,<br>
Attila</span></font><o:p></o:p></p>

</div>

<blockquote style=3D'border:none;border-left:solid blue =
1.5pt;padding:0cm 0cm 0cm 4.0pt;
margin-left:3.75pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt'=

<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 =
size=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:</spa=
n></font></b><font
size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma'> Thomas
Nadeau [<a =
href=3D"mailto:[email-masked]">mailto:[email-masked]</a=
>]
<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Tuesday, December =
04, 2007
2:58 PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> <a
href=3D"mailto:[email-masked]">[email-masked]</a><br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> Attila Takacs; <a
href=3D"mailto:[email-masked]">[email-masked]</a><br>=

<b><span style=3D'font-weight:bold'>Subject:</span></b>
draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt</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>

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

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>After reading this draft, I have some =
questions/comments.<o:p></o:p></span></font></p>

</div>

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

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>1) Overall,&nbsp;I am concerned that the definition of a new TLV =
and
these procedures represent&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>what amounts to a laying violation and ask that the ADs take a =
look at
this<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>approach closely. This is similar to the now-rejected approach =
that was
proposed<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>in the l2vpn WG about munging CFM + PWs. &nbsp;To my reading, =
this is essentially<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>the same thing. If you want to run CFM, run it natively over the
ethernet interfaces and<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>have no regard for the underlying topology (GMPLS, PWs, etc...)
otherwise you&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>will be creating a mess for implementations and =
interoperability.&nbsp;</span></font><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>

</div>

</blockquote>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>The application&nbsp;of the draft =
is
exactly for what you are calling out: when CFM is run natively over the
Ethernet interfaces. The document focuses on GELS and Ethernet =
LSPs.&nbsp;That
is,&nbsp;to establish CFM entities for GMPLS controlled Ethernet =
LSPs.&nbsp;Hence,
I think there is no layer violation issue.</span></font><o:p></o:p></p>

</div>

</div>

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

<p class=3DMsoNormal><span class=3Dapple-tab-span><font size=3D3
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt'>=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
</span></font></span>This
solution specifically only works for GMPLS ethernet LSPs, right? =
&nbsp;<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'>What do I do if I want to set up MPLS ethernet LSPs (i.e.:
PWs)&nbsp;and do CFM over those? Oh,<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>that is a different solution, right? &nbsp;Then what do I do if =
I want
to run CFM over some new type of<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>ethernet LSP in the future? More protocol hacks? &nbsp;The point =
is to
use CFM over an ethernet interface<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>without the underlying layers knowing. This is good networking
architecture design, that simplifies<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>implementations and makes them more robust, as well as makes =
using them
operationally much<o:p></o:p></span></font></p>

</div>

<div>

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

</div>

<div>

<blockquote style=3D'margin-top:5.0pt;margin-bottom:5.0pt' type=3Dcite>

<div style=3D'WORD-WRAP: break-word;webkit-nbsp-mode: =
space;webkit-line-break: after-white-space'>

<blockquote style=3D'border:none;border-left:solid blue =
1.5pt;padding:0cm 0cm 0cm 4.0pt;
margin-left:3.75pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt'=

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>2)&nbsp;The introductory sections in this draft give a lot of
discussion about fast fault detection. I<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>am puzzled by this given that GMPLS networks tend to run over =
quickly
self-healing<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>optical infrastructures. Is it =
therefore&nbsp;truly&nbsp;necessary to
motivate this work by<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>requiring fast CFMs?<o:p></o:p></span></font></p>

</div>

</blockquote>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>It is right that frequent CCMs are =
not
required if the layers below Ethernet handle protection. However, the ID
focuses on Ethernet LSPs where Ethernet is&nbsp;not just a single
hop&nbsp;above a transport LSP.&nbsp;In this case&nbsp;Ethernet layer =
(for
clarity GELS) may provide protection for Ethernet LSPs.&nbsp;In any =
case,&nbsp;
the whole point of the ID is to allow for the appropriate configuration =
of CFM
for Ethernet LSPs with GMPLS.</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'><o:p>&nbsp;</o:p></span></font></p>

</div>

<blockquote style=3D'border:none;border-left:solid blue =
1.5pt;padding:0cm 0cm 0cm 4.0pt;
margin-left:3.75pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt'=

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>3) This document does not cover E-LMI. Why =
not?<o:p></o:p></span></font></p>

</div>

</blockquote>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>E-LMI is run over the MEF UNI. =
The&nbsp;ID
focuses on Ethernet LSPs within a network.</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=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

</div>

<blockquote style=3D'border:none;border-left:solid blue =
1.5pt;padding:0cm 0cm 0cm 4.0pt;
margin-left:3.75pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt'=

<div>

<p class=3DMsoNormal><span class=3Dapple-style-span><font size=3D1
face=3D"Times New Roman"><span style=3D'font-size:9.0pt'>For the =
purposes of this
document, we only discuss Ethernet =
OAM</span></font></span><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D1 face=3DHelvetica><span =
style=3D'font-size:9.0pt;
font-family:Helvetica'>&nbsp;&nbsp; [IEEE-CFM] aspects that are relevant =
for
the connectivity monitoring<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D1 face=3DHelvetica><span =
style=3D'font-size:9.0pt;
font-family:Helvetica'>&nbsp;&nbsp; of bidirectional point-to-point =
PBB-TE
connections. &nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D1 face=3DHelvetica><span =
style=3D'font-size:9.0pt;
font-family:Helvetica'><o:p>&nbsp;</o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D1 face=3DHelvetica><span =
style=3D'font-size:9.0pt;
font-family:Helvetica'>4) Is this the right place to define this =
document or
should this be done in GELS?<o:p></o:p></span></font></p>

</div>

</blockquote>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Well, GELS is done in CCAMP...this =
seems
to be the right place.</span></font><o:p></o:p></p>

</div>

<blockquote style=3D'border:none;border-left:solid blue =
1.5pt;padding:0cm 0cm 0cm 4.0pt;
margin-left:3.75pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt'=

<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=3D1 face=3DHelvetica><span =
style=3D'font-size:9.0pt;
font-family:Helvetica'><o:p>&nbsp;</o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D1 face=3DHelvetica><span =
style=3D'font-size:9.0pt;
font-family:Helvetica'>5) &nbsp; In section 2 you make the following =
statement:<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D1 face=3DHelvetica><span =
style=3D'font-size:9.0pt;
font-family:Helvetica'><o:p>&nbsp;</o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D1 face=3DHelvetica><span =
style=3D'font-size:9.0pt;
font-family:Helvetica'>2.&nbsp; GMPLS RSVP-TE =
Extensions<o:p></o:p></span></font></p>

</div>

<div style=3D'MIN-HEIGHT: 14px'>

<p class=3DMsoNormal><font size=3D1 face=3DHelvetica><span =
style=3D'font-size:9.0pt;
font-family:Helvetica'><o:p>&nbsp;</o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D1 face=3DHelvetica><span =
style=3D'font-size:9.0pt;
font-family:Helvetica'>&nbsp;<span class=3Dapple-tab-span> </span>&nbsp; =
To
simplify the configuration of connectivity monitoring, when =
an<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D1 face=3DHelvetica><span =
style=3D'font-size:9.0pt;
font-family:Helvetica'>&nbsp;&nbsp; Ethernet LSP is signalled the =
associated
MEPs should be automatically<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D1 face=3DHelvetica><span =
style=3D'font-size:9.0pt;
font-family:Helvetica'>&nbsp;<span class=3Dapple-tab-span> </span>&nbsp;
established.&nbsp; Further more, GMPLS signalling should be able =
to<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D1 face=3DHelvetica><span =
style=3D'font-size:9.0pt;
font-family:Helvetica'>&nbsp;&nbsp;enable/disable connectivity =
monitoring of a
particular Ethernet LSP.<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D1 face=3DHelvetica><span =
style=3D'font-size:9.0pt;
font-family:Helvetica'><o:p>&nbsp;</o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D1 face=3DHelvetica><span =
style=3D'font-size:9.0pt;
font-family:Helvetica'><o:p>&nbsp;</o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D1 face=3DHelvetica><span =
style=3D'font-size:9.0pt;
font-family:Helvetica'>To my point in #1 above, you should use the =
native CFM
functionality over the ethernet interface and =
signal<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D1 face=3DHelvetica><span =
style=3D'font-size:9.0pt;
font-family:Helvetica'>those capabilities to the bridges at both ends =
using the
IEEE CFM signaling procedures (when and if =
they<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D1 face=3DHelvetica><span =
style=3D'font-size:9.0pt;
font-family:Helvetica'>are created). &nbsp;If you want to test the =
underlying
GMPLS LSP(s), then you should use some<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D1 face=3DHelvetica><span =
style=3D'font-size:9.0pt;
font-family:Helvetica'>other mechanism defined for that layer such as =
the work
stated in&nbsp;</span></font><span class=3Dapple-style-span><b><font =
size=3D2
face=3DHelvetica><span =
style=3D'font-size:10.0pt;font-family:Helvetica;font-weight:
bold'>draft-ali-ccamp-gmpls-LSP-ping-traceroute-00.txt</span></font></b><=
/span><font
size=3D1 face=3DHelvetica><span =
style=3D'font-size:9.0pt;font-family:Helvetica'><o:p></o:p></span></font>=
</p>

</div>

</blockquote>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>See the note&nbsp;to your point #1. =
There
is no relation&nbsp;to the gmpls-LSP-ping =
draft.&nbsp;</span></font><font
size=3D1 face=3DHelvetica><span =
style=3D'font-size:9.0pt;font-family:Helvetica'><o:p></o:p></span></font>=
</p>

</div>

</div>

</blockquote>

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

<p class=3DMsoNormal><span class=3Dapple-tab-span><font size=3D3
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt'>=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
</span></font></span>The
point I am making is that perhaps it should.<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'><o:p>&nbsp;</o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><span class=3Dapple-tab-span><font size=3D3
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt'>=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
</span></font></span>--Tom<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'><o:p>&nbsp;</o:p></span></font></p>

</div>

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

<div>

<blockquote style=3D'margin-top:5.0pt;margin-bottom:5.0pt' type=3Dcite>

<div style=3D'WORD-WRAP: break-word;webkit-nbsp-mode: =
space;webkit-line-break: after-white-space'>

<div>

<p class=3DMsoNormal><font size=3D1 face=3DHelvetica><span =
style=3D'font-size:9.0pt;
font-family:Helvetica'><o:p>&nbsp;</o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D1 face=3DHelvetica><span =
style=3D'font-size:9.0pt;
font-family:Helvetica'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D1 face=3DHelvetica><span =
style=3D'font-size:9.0pt;
font-family:Helvetica'>&nbsp;<o:p></o:p></span></font></p>

</div>

</div>

</blockquote>

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

</div>

</body>

</html>

------_=_NextPart_001_01C836D6.7D4FEF53--

Delivery-date: Tue, 04 Dec 2007 19:30:24 +0000
Cc: <[email-masked]>, <[email-masked]>
From: Thomas Nadeau <[email-masked]>
To: "Attila Takacs" <[email-masked]>
Subject: Re: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt
Date: Tue, 4 Dec 2007 14:30:00 -0500

--Apple-Mail-25--553931354
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed;
	delsp=yes
Content-Transfer-Encoding: 7bit

On Dec 4, 2007, at 1:51 PM, Attila Takacs wrote:

> Hi Thomas,
>
> Thank you for the comments!
> Please see answers inline.
>
> Best regards,
> Attila
>
> From: Thomas Nadeau [mailto:[email-masked]]
> Sent: Tuesday, December 04, 2007 2:58 PM
> To: [email-masked]
> Cc: Attila Takacs; [email-masked]
> Subject: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt
>
>
>
> After reading this draft, I have some questions/comments.
>
> 1) Overall, I am concerned that the definition of a new TLV and  
> these procedures represent
> what amounts to a laying violation and ask that the ADs take a look  
> at this
> approach closely. This is similar to the now-rejected approach that  
> was proposed
> in the l2vpn WG about munging CFM + PWs.  To my reading, this is  
> essentially
> the same thing. If you want to run CFM, run it natively over the  
> ethernet interfaces and
> have no regard for the underlying topology (GMPLS, PWs, etc...)  
> otherwise you
> will be creating a mess for implementations and interoperability.
> The application of the draft is exactly for what you are calling  
> out: when CFM is run natively over the Ethernet interfaces. The  
> document focuses on GELS and Ethernet LSPs. That is, to establish  
> CFM entities for GMPLS controlled Ethernet LSPs. Hence, I think  
> there is no layer violation issue.

	This solution specifically only works for GMPLS ethernet LSPs, right?
What do I do if I want to set up MPLS ethernet LSPs (i.e.: PWs) and do  
CFM over those? Oh,
that is a different solution, right?  Then what do I do if I want to  
run CFM over some new type of
ethernet LSP in the future? More protocol hacks?  The point is to use  
CFM over an ethernet interface
without the underlying layers knowing. This is good networking  
architecture design, that simplifies
implementations and makes them more robust, as well as makes using  
them operationally much
easier.
> 2) The introductory sections in this draft give a lot of discussion  
> about fast fault detection. I
> am puzzled by this given that GMPLS networks tend to run over  
> quickly self-healing
> optical infrastructures. Is it therefore truly necessary to motivate  
> this work by
> requiring fast CFMs?
> It is right that frequent CCMs are not required if the layers below  
> Ethernet handle protection. However, the ID focuses on Ethernet LSPs  
> where Ethernet is not just a single hop above a transport LSP. In  
> this case Ethernet layer (for clarity GELS) may provide protection  
> for Ethernet LSPs. In any case,  the whole point of the ID is to  
> allow for the appropriate configuration of CFM for Ethernet LSPs  
> with GMPLS.
>
> 3) This document does not cover E-LMI. Why not?
> E-LMI is run over the MEF UNI. The ID focuses on Ethernet LSPs  
> within a network.
>
>
> For the purposes of this document, we only discuss Ethernet OAM
>    [IEEE-CFM] aspects that are relevant for the connectivity  
> monitoring
>    of bidirectional point-to-point PBB-TE connections.
>
> 4) Is this the right place to define this document or should this be  
> done in GELS?
> Well, GELS is done in CCAMP...this seems to be the right place.
>
>
> 5)   In section 2 you make the following statement:
>
> 2.  GMPLS RSVP-TE Extensions
>
>     To simplify the configuration of connectivity monitoring, when an
>    Ethernet LSP is signalled the associated MEPs should be  
> automatically
>     established.  Further more, GMPLS signalling should be able to
>   enable/disable connectivity monitoring of a particular Ethernet LSP.
>
>
> To my point in #1 above, you should use the native CFM functionality  
> over the ethernet interface and signal
> those capabilities to the bridges at both ends using the IEEE CFM  
> signaling procedures (when and if they
> are created).  If you want to test the underlying GMPLS LSP(s), then  
> you should use some
> other mechanism defined for that layer such as the work stated in  
> draft-ali-ccamp-gmpls-LSP-ping-traceroute-00.txt
> See the note to your point #1. There is no relation to the gmpls-LSP- 
> ping draft.

	The point I am making is that perhaps it should.

	--Tom

--Apple-Mail-25--553931354
Content-Type: text/html;
	charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

<html><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; "><br><div><div>On Dec 4, 2007, =
at 1:51 PM, Attila Takacs wrote:</div><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite"> <div =
style=3D"WORD-WRAP: break-word; webkit-nbsp-mode: space; =
webkit-line-break: after-white-space"> <div><span =
class=3D"382281718-04122007"><font face=3D"Arial" color=3D"#0000ff" =
size=3D"2">Hi Thomas,</font></span></div> <div><span =
class=3D"382281718-04122007"><font face=3D"Arial" color=3D"#0000ff" =
size=3D"2"></font></span>&nbsp;</div> <div><span =
class=3D"382281718-04122007"><font face=3D"Arial" color=3D"#0000ff" =
size=3D"2">Thank you&nbsp;for the comments!</font></span></div> =
<div><span class=3D"382281718-04122007"><font face=3D"Arial" =
color=3D"#0000ff" size=3D"2">Please see answers =
inline.</font></span></div> <div><span class=3D"382281718-04122007"><font =
face=3D"Arial" color=3D"#0000ff" size=3D"2"></font></span>&nbsp;</div> =
<div><span class=3D"382281718-04122007"><font face=3D"Arial" =
color=3D"#0000ff" size=3D"2">Best =
regards,<br>Attila</font></span></div><br> <blockquote dir=3D"ltr" =
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">  <div class=3D"OutlookMessageHeader" =
lang=3D"en-us" dir=3D"ltr" align=3D"left">  <hr tabindex=3D"-1">  <font =
face=3D"Tahoma" size=3D"2"><b>From:</b> Thomas Nadeau   [<a =
href=3D"mailto:[email-masked]">mailto:[email-masked]</a>=
] <br><b>Sent:</b> Tuesday, December 04, 2007   2:58 PM<br><b>To:</b> <a =
href=3D"mailto:[email-masked]">[email-masked]</a><br><b>Cc:</b> =
Attila Takacs;   <a =
href=3D"mailto:[email-masked]">[email-masked]</a><br><=
b>Subject:</b>   =
draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt<br></font><br></div>  =
<div></div><font face=3D"Arial" color=3D"#0000ff" size=3D"2"></font><font =
face=3D"Arial" color=3D"#0000ff" size=3D"2"></font><font face=3D"Arial" =
color=3D"#0000ff" size=3D"2"></font><font face=3D"Arial" color=3D"#0000ff"=
 size=3D"2"></font><font face=3D"Arial" color=3D"#0000ff" =
size=3D"2"></font><br>  <div><font face=3D"Arial" color=3D"#0000ff" =
size=3D"2"></font><font face=3D"Arial" color=3D"#0000ff" =
size=3D"2"></font><font face=3D"Arial" color=3D"#0000ff" =
size=3D"2"></font><font face=3D"Arial" color=3D"#0000ff" =
size=3D"2"></font><br class=3D"webkit-block-placeholder"></div>  =
<div><span class=3D"Apple-tab-span" style=3D"WHITE-SPACE: =
pre"></span>After reading   this draft, I have some =
questions/comments.<br class=3D"webkit-block-placeholder"></div>  =
<div><font face=3D"Arial" color=3D"#0000ff" size=3D"2"></font><font =
face=3D"Arial" color=3D"#0000ff" size=3D"2"></font><font face=3D"Arial" =
color=3D"#0000ff" size=3D"2"></font><font face=3D"Arial" color=3D"#0000ff"=
 size=3D"2"></font><br class=3D"webkit-block-placeholder"></div>  =
<div><span class=3D"Apple-tab-span" style=3D"WHITE-SPACE: pre"></span>1) =
  Overall,&nbsp;I am concerned that the definition of a new TLV and =
these   procedures represent&nbsp;</div>  <div><span =
class=3D"Apple-tab-span" style=3D"WHITE-SPACE: pre"></span>what amounts  =
 to a laying violation and ask that the ADs take a look at this<br =
class=3D"webkit-block-placeholder"></div>  <div><span =
class=3D"Apple-tab-span" style=3D"WHITE-SPACE: pre"></span>approach   =
closely. This is similar to the now-rejected approach that was =
proposed<br class=3D"webkit-block-placeholder"></div>  <div><span =
class=3D"Apple-tab-span" style=3D"WHITE-SPACE: pre"></span>in the l2vpn  =
 WG about munging CFM + PWs. &nbsp;To my reading, this is essentially<br =
class=3D"webkit-block-placeholder"></div>  <div><span =
class=3D"Apple-tab-span" style=3D"WHITE-SPACE: pre"></span>the same   =
thing. If you want to run CFM, run it natively over the ethernet =
interfaces   and</div>  <div><span class=3D"Apple-tab-span" =
style=3D"WHITE-SPACE: pre"></span>have no regard   for the underlying =
topology (GMPLS, PWs, etc...) otherwise you&nbsp;<br =
class=3D"webkit-block-placeholder"></div>  <div><span =
class=3D"Apple-tab-span" style=3D"WHITE-SPACE: pre"></span>will be   =
creating a mess for implementations and interoperability.&nbsp;<span =
class=3D"382281718-04122007"><font face=3D"Arial" color=3D"#0000ff" =
size=3D"2">&nbsp;</font></span></div></blockquote> <div dir=3D"ltr"><span =
class=3D"382281718-04122007"></span><font face=3D"Arial"><font =
color=3D"#0000ff"><font size=3D"2">T<span class=3D"382281718-04122007">he =
application&nbsp;of the draft is exactly for what you are calling out: =
when CFM is run natively over the Ethernet interfaces. The document =
focuses on GELS and Ethernet LSPs.&nbsp;That is,&nbsp;to establish CFM =
entities for GMPLS controlled Ethernet LSPs.&nbsp;Hence, =
</span></font></font></font><font face=3D"Arial"><font =
color=3D"#0000ff"><font size=3D"2"><span class=3D"382281718-04122007">I =
think there is no layer violation =
issue.</span></font></font></font></div></div></blockquote><div><br =
class=3D"webkit-block-placeholder"></div><span class=3D"Apple-tab-span" =
style=3D"white-space:pre">	</span>This solution specifically only =
works for GMPLS ethernet LSPs, right? &nbsp;</div><div>What do I do if I =
want to set up MPLS ethernet LSPs (i.e.: PWs)&nbsp;and do CFM over =
those? Oh,</div><div>that is a different solution, right? &nbsp;Then =
what do I do if I want to run CFM over some new type =
of</div><div>ethernet LSP in the future? More protocol hacks? &nbsp;The =
point is to use CFM over an ethernet interface</div><div>without the =
underlying layers knowing. This is good networking architecture design, =
that simplifies</div><div>implementations and makes them more robust, as =
well as makes using them operationally =
much</div><div>easier.&nbsp;</div><div><blockquote type=3D"cite"><div =
style=3D"WORD-WRAP: break-word; webkit-nbsp-mode: space; =
webkit-line-break: after-white-space"> <div dir=3D"ltr"><font =
face=3D"Arial" color=3D"#0000ff" size=3D"2"></font></div><blockquote =
dir=3D"ltr" style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: =
#0000ff 2px solid; MARGIN-RIGHT: 0px"><div>2)&nbsp;The   introductory =
sections in this draft give a lot of discussion about fast fault   =
detection. I<br class=3D"webkit-block-placeholder"></div>  <div><span =
class=3D"Apple-tab-span" style=3D"WHITE-SPACE: pre"></span>am puzzled by =
  this given that GMPLS networks tend to run over quickly =
self-healing<br class=3D"webkit-block-placeholder"></div>  <div><span =
class=3D"Apple-tab-span" style=3D"WHITE-SPACE: pre"></span>optical   =
infrastructures. Is it therefore&nbsp;truly&nbsp;necessary to motivate =
this   work by<br class=3D"webkit-block-placeholder"></div>  <div><span =
class=3D"Apple-tab-span" style=3D"WHITE-SPACE: pre"></span>requiring =
fast   CFMs?<br class=3D"webkit-block-placeholder"></div></blockquote> =
<div><span class=3D"382281718-04122007"><font face=3D"Arial" =
color=3D"#0000ff" size=3D"2">It is right that frequent CCMs are not =
required if the layers below Ethernet handle protection. However, the ID =
focuses on Ethernet LSPs where Ethernet is&nbsp;not just a single =
hop&nbsp;above a transport LSP.&nbsp;In this case&nbsp;Ethernet layer =
(for clarity GELS) may provide protection for Ethernet LSPs.&nbsp;In any =
case,&nbsp; the whole point of the ID is to allow for the appropriate =
configuration of CFM for Ethernet LSPs with GMPLS.</font></span></div> =
<div dir=3D"ltr"><font face=3D"Arial" color=3D"#0000ff" =
size=3D"2"></font><font face=3D"Arial" color=3D"#0000ff" =
size=3D"2"></font><font face=3D"Arial" color=3D"#0000ff" =
size=3D"2"></font><font face=3D"Arial" color=3D"#0000ff" =
size=3D"2"></font><font face=3D"Arial" color=3D"#0000ff" =
size=3D"2"></font><font face=3D"Arial" color=3D"#0000ff" =
size=3D"2"></font><font face=3D"Arial" color=3D"#0000ff" =
size=3D"2"></font><font face=3D"Arial" color=3D"#0000ff" =
size=3D"2"></font><font face=3D"Arial" color=3D"#0000ff" =
size=3D"2"></font><br></div> <blockquote dir=3D"ltr" =
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">  <div><span class=3D"Apple-tab-span" =
style=3D"WHITE-SPACE: pre"></span>3) This   document does not cover =
E-LMI. Why not?<br class=3D"webkit-block-placeholder"></div><font =
face=3D"Arial" color=3D"#0000ff" size=3D"2"></font><font face=3D"Arial" =
color=3D"#0000ff" size=3D"2"></font><font face=3D"Arial" color=3D"#0000ff"=
 size=3D"2"></font><font face=3D"Arial" color=3D"#0000ff" =
size=3D"2"></font></blockquote> <div><span =
class=3D"382281718-04122007"><font face=3D"Arial" color=3D"#0000ff" =
size=3D"2">E-LMI is run over the MEF UNI. The&nbsp;ID focuses on =
Ethernet LSPs within a network.</font></span></div> <div><font =
face=3D"Arial" color=3D"#0000ff" size=3D"2"></font>&nbsp;</div> <div =
dir=3D"ltr"><font face=3D"Arial" color=3D"#0000ff" size=3D"2"></font><font=
 face=3D"Arial" color=3D"#0000ff" size=3D"2"></font><font face=3D"Arial" =
color=3D"#0000ff" size=3D"2"></font><font face=3D"Arial" color=3D"#0000ff"=
 size=3D"2"></font><br class=3D"webkit-block-placeholder"></div> =
<blockquote dir=3D"ltr" style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">  <div><span =
class=3D"Apple-tab-span" style=3D"WHITE-SPACE: pre"></span><span =
class=3D"Apple-style-span" style=3D"FONT-SIZE: 12px">For the purposes of =
this   document, we only discuss Ethernet OAM</span></div>  <div =
style=3D"MARGIN: 0px; FONT: 12px Helvetica"><span class=3D"Apple-tab-span"=
 style=3D"WHITE-SPACE: pre"></span>&nbsp;&nbsp; [IEEE-CFM] aspects that =
are   relevant for the connectivity monitoring</div>  <div =
style=3D"MARGIN: 0px; FONT: 12px Helvetica"><span class=3D"Apple-tab-span"=
 style=3D"WHITE-SPACE: pre"></span>&nbsp;&nbsp; of bidirectional =
point-to-point   PBB-TE connections. &nbsp;</div>  <div style=3D"MARGIN: =
0px; FONT: 12px Helvetica"><font face=3D"Arial" color=3D"#0000ff" =
size=3D"2"></font><font face=3D"Arial" color=3D"#0000ff" =
size=3D"2"></font><font face=3D"Arial" color=3D"#0000ff" =
size=3D"2"></font><font face=3D"Arial" color=3D"#0000ff" =
size=3D"2"></font><font face=3D"Arial" color=3D"#0000ff" =
size=3D"2"></font><font face=3D"Arial" color=3D"#0000ff" =
size=3D"2"></font><font face=3D"Arial" color=3D"#0000ff" =
size=3D"2"></font><br class=3D"webkit-block-placeholder"></div>  <div =
style=3D"MARGIN: 0px; FONT: 12px Helvetica"><span class=3D"Apple-tab-span"=
 style=3D"WHITE-SPACE: pre"></span>4) Is this the right place to define =
this   document or should this be done in GELS?<br =
class=3D"webkit-block-placeholder"></div><font face=3D"Arial" =
color=3D"#0000ff" size=3D"2"></font><font face=3D"Arial" color=3D"#0000ff"=
 size=3D"2"></font><font face=3D"Arial" color=3D"#0000ff" =
size=3D"2"></font><font face=3D"Arial" color=3D"#0000ff" =
size=3D"2"></font><font face=3D"Arial" color=3D"#0000ff" =
size=3D"2"></font></blockquote> <div dir=3D"ltr"><span =
class=3D"382281718-04122007"><font face=3D"Arial" color=3D"#0000ff" =
size=3D"2">Well, GELS is done in CCAMP...this seems to be the right =
place.</font></span></div> <blockquote dir=3D"ltr" style=3D"PADDING-LEFT: =
5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: =
0px">  <div><font face=3D"Arial" color=3D"#0000ff" =
size=3D"2"></font>&nbsp;</div>  <div style=3D"MARGIN: 0px; FONT: 12px =
Helvetica"><font face=3D"Arial" color=3D"#0000ff" size=3D"2"></font><font =
face=3D"Arial" color=3D"#0000ff" size=3D"2"></font><font face=3D"Arial" =
color=3D"#0000ff" size=3D"2"></font><font face=3D"Arial" color=3D"#0000ff"=
 size=3D"2"></font><br class=3D"webkit-block-placeholder"></div>  <div =
style=3D"MARGIN: 0px; FONT: 12px Helvetica"><span class=3D"Apple-tab-span"=
 style=3D"WHITE-SPACE: pre"></span>5) &nbsp; In section 2 you make the =
following   statement:</div>  <div style=3D"MARGIN: 0px; FONT: 12px =
Helvetica"><font face=3D"Arial" color=3D"#0000ff" size=3D"2"></font><font =
face=3D"Arial" color=3D"#0000ff" size=3D"2"></font><font face=3D"Arial" =
color=3D"#0000ff" size=3D"2"></font><font face=3D"Arial" color=3D"#0000ff"=
 size=3D"2"></font><font face=3D"Arial" color=3D"#0000ff" =
size=3D"2"></font><font face=3D"Arial" color=3D"#0000ff" =
size=3D"2"></font><br class=3D"webkit-block-placeholder"></div>  <div =
style=3D"MARGIN: 0px; FONT: 12px Helvetica"><span class=3D"Apple-tab-span"=
 style=3D"WHITE-SPACE: pre"></span>2.&nbsp; GMPLS RSVP-TE =
Extensions</div>  <div style=3D"MIN-HEIGHT: 14px; MARGIN: 0px; FONT: =
12px Helvetica"><font face=3D"Arial" color=3D"#0000ff" =
size=3D"2"></font><font face=3D"Arial" color=3D"#0000ff" =
size=3D"2"></font><font face=3D"Arial" color=3D"#0000ff" =
size=3D"2"></font><font face=3D"Arial" color=3D"#0000ff" =
size=3D"2"></font><br></div>  <div style=3D"MARGIN: 0px; FONT: 12px =
Helvetica"><span class=3D"Apple-tab-span" style=3D"WHITE-SPACE: =
pre"></span>&nbsp;<span class=3D"Apple-tab-span" style=3D"WHITE-SPACE: =
pre"> </span>&nbsp; To simplify the configuration of   connectivity =
monitoring, when an</div>  <div style=3D"MARGIN: 0px; FONT: 12px =
Helvetica"><span class=3D"Apple-tab-span" style=3D"WHITE-SPACE: =
pre"></span>&nbsp;&nbsp; Ethernet LSP is signalled the   associated MEPs =
should be automatically</div>  <div style=3D"MARGIN: 0px; FONT: 12px =
Helvetica"><span class=3D"Apple-tab-span" style=3D"WHITE-SPACE: =
pre"></span>&nbsp;<span class=3D"Apple-tab-span" style=3D"WHITE-SPACE: =
pre"> </span>&nbsp; established.&nbsp; Further more, GMPLS   signalling =
should be able to</div>  <div style=3D"MARGIN: 0px; FONT: 12px =
Helvetica"><span class=3D"Apple-tab-span" style=3D"WHITE-SPACE: =
pre"></span>&nbsp;&nbsp;enable/disable connectivity   monitoring of a =
particular Ethernet LSP.</div>  <div style=3D"MARGIN: 0px; FONT: 12px =
Helvetica"><font face=3D"Arial" color=3D"#0000ff" size=3D"2"></font><font =
face=3D"Arial" color=3D"#0000ff" size=3D"2"></font><font face=3D"Arial" =
color=3D"#0000ff" size=3D"2"></font><font face=3D"Arial" color=3D"#0000ff"=
 size=3D"2"></font><br class=3D"webkit-block-placeholder"></div>  <div =
style=3D"MARGIN: 0px; FONT: 12px Helvetica"><font face=3D"Arial" =
color=3D"#0000ff" size=3D"2"></font><font face=3D"Arial" color=3D"#0000ff"=
 size=3D"2"></font><font face=3D"Arial" color=3D"#0000ff" =
size=3D"2"></font><font face=3D"Arial" color=3D"#0000ff" =
size=3D"2"></font><br class=3D"webkit-block-placeholder"></div>  <div =
style=3D"MARGIN: 0px; FONT: 12px Helvetica"><span class=3D"Apple-tab-span"=
 style=3D"WHITE-SPACE: pre"></span>To my point in #1 above, you should =
use the   native CFM functionality over the ethernet interface and =
signal</div>  <div style=3D"MARGIN: 0px; FONT: 12px Helvetica"><span =
class=3D"Apple-tab-span" style=3D"WHITE-SPACE: pre"></span>those =
capabilities to the bridges at both ends   using the IEEE CFM signaling =
procedures (when and if they<br class=3D"webkit-block-placeholder"></div> =
 <div style=3D"MARGIN: 0px; FONT: 12px Helvetica"><span =
class=3D"Apple-tab-span" style=3D"WHITE-SPACE: pre"></span>are created). =
&nbsp;If you want to test the   underlying GMPLS LSP(s), then you should =
use some</div>  <div style=3D"MARGIN: 0px; FONT: 12px Helvetica"><span =
class=3D"Apple-tab-span" style=3D"WHITE-SPACE: pre"></span>other =
mechanism defined for that layer such as   the work stated in&nbsp;<span =
class=3D"Apple-style-span" style=3D"FONT-WEIGHT: bold; FONT-SIZE: =
13px">draft-ali-ccamp-gmpls-LSP-ping-traceroute-00.txt</span></div></block=
quote> <div dir=3D"ltr" style=3D"MARGIN: 0px; FONT: 12px =
Helvetica"><font face=3D"Arial"><font color=3D"#0000ff"><font =
size=3D"2"><span class=3D"382281718-04122007">See the note&nbsp;to your =
point #1. There is no relation&nbsp;to the gmpls-LSP-ping =
draft.</span><span =
class=3D"382281718-04122007">&nbsp;</span></font></font></font></div></div=
></blockquote><div><br class=3D"webkit-block-placeholder"></div><span =
class=3D"Apple-tab-span" style=3D"white-space:pre">	</span>The point =
I am making is that perhaps it should.</div><div><br =
class=3D"webkit-block-placeholder"></div><div><span =
class=3D"Apple-tab-span" style=3D"white-space:pre">	</span>--Tom<br =
class=3D"webkit-block-placeholder"></div><div><br =
class=3D"webkit-block-placeholder"></div><div><br =
class=3D"webkit-block-placeholder"></div><div><blockquote =
type=3D"cite"><div style=3D"WORD-WRAP: break-word; webkit-nbsp-mode: =
space; webkit-line-break: after-white-space"><div dir=3D"ltr" =
style=3D"MARGIN: 0px; FONT: 12px Helvetica"><br></div> <div dir=3D"ltr" =
style=3D"MARGIN: 0px; FONT: 12px Helvetica"><font face=3D"Arial" =
color=3D"#0000ff" size=3D"2"></font>&nbsp;</div> <div dir=3D"ltr" =
style=3D"MARGIN: 0px; FONT: 12px Helvetica"><font face=3D"Arial" =
color=3D"#0000ff" =
size=3D"2"></font>&nbsp;</div></div></blockquote></div><br></body></html>=

--Apple-Mail-25--553931354--

Delivery-date: Tue, 04 Dec 2007 19:29:57 +0000
Cc: [email-masked], [email-masked], [email-masked]
From: Thomas Nadeau <[email-masked]>
To: Loa Andersson <[email-masked]>
Subject: Re: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt
Date: Tue, 4 Dec 2007 14:28:54 -0500

On Dec 4, 2007, at 2:26 PM, Loa Andersson wrote:

> Tom,
>
> Thomas Nadeau wrote:
>>
>>
>>    After reading this draft, I have some questions/comments.
>>
>>    1) Overall, I am concerned that the definition of a new TLV and
>> these procedures represent
>>        what amounts to a laying violation
>
> did mean to say layering violation ???

	Yep. Typing too fast! *)

	--Tom

>
>
> /Loa
>
> and ask that the ADs take a
>> look at this
>>        approach closely. This is similar to the now-rejected approach
>> that was proposed
>>        in the l2vpn WG about munging CFM + PWs.  To my reading,  
>> this is
>> essentially
>>        the same thing. If you want to run CFM, run it natively over  
>> the
>> ethernet interfaces and
>>        have no regard for the underlying topology (GMPLS, PWs,  
>> etc...)
>> otherwise you
>>        will be creating a mess for implementations and  
>> interoperability.
>>
>>    2) The introductory sections in this draft give a lot of  
>> discussion
>> about fast fault detection. I
>>        am puzzled by this given that GMPLS networks tend to run over
>> quickly self-healing
>>        optical infrastructures. Is it therefore truly necessary to
>> motivate this work by
>>        requiring fast CFMs?
>>
>>    3) This document does not cover E-LMI. Why not?
>>
>>        For the purposes of this document, we only discuss Ethernet  
>> OAM
>>           [IEEE-CFM] aspects that are relevant for the connectivity
>> monitoring
>>           of bidirectional point-to-point PBB-TE connections.
>>
>>    4) Is this the right place to define this document or should  
>> this be
>> done in GELS?
>>
>>    5)   In section 2 you make the following statement:
>>
>>        2.  GMPLS RSVP-TE Extensions
>>
>>           To simplify the configuration of connectivity monitoring,
>> when an
>>           Ethernet LSP is signalled the associated MEPs should be
>> automatically
>>           established.  Further more, GMPLS signalling should be  
>> able to
>>          enable/disable connectivity monitoring of a particular
>> Ethernet LSP.
>>
>>
>>        To my point in #1 above, you should use the native CFM
>> functionality over the ethernet interface and signal
>>        those capabilities to the bridges at both ends using the IEEE
>> CFM signaling procedures (when and if they
>>        are created).  If you want to test the underlying GMPLS  
>> LSP(s),
>> then you should use some
>>        other mechanism defined for that layer such as the work stated
>> in draft-ali-ccamp-gmpls-LSP-ping-traceroute-00.txt
>>
>>
>
>
> -- 
> 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]
>
> This email was Anti Virus checked by Astaro Security Gateway. http://www.astaro.com
>
>

Delivery-date: Tue, 04 Dec 2007 19:28:01 +0000
Date: Tue, 04 Dec 2007 20:26:23 +0100
From: Loa Andersson <[email-masked]>
Organization: Acreo AB
To: Thomas Nadeau <[email-masked]>
CC: [email-masked], [email-masked],  [email-masked]
Subject: Re: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt

Tom,

Thomas Nadeau wrote:
> 
> 
>     After reading this draft, I have some questions/comments.
> 
>     1) Overall, I am concerned that the definition of a new TLV and
> these procedures represent
>         what amounts to a laying violation 

did mean to say layering violation ???

/Loa

and ask that the ADs take a
> look at this
>         approach closely. This is similar to the now-rejected approach
> that was proposed
>         in the l2vpn WG about munging CFM + PWs.  To my reading, this is
> essentially
>         the same thing. If you want to run CFM, run it natively over the
> ethernet interfaces and
>         have no regard for the underlying topology (GMPLS, PWs, etc...)
> otherwise you
>         will be creating a mess for implementations and interoperability.
> 
>     2) The introductory sections in this draft give a lot of discussion
> about fast fault detection. I
>         am puzzled by this given that GMPLS networks tend to run over
> quickly self-healing
>         optical infrastructures. Is it therefore truly necessary to
> motivate this work by
>         requiring fast CFMs?
> 
>     3) This document does not cover E-LMI. Why not?
> 
>         For the purposes of this document, we only discuss Ethernet OAM
>            [IEEE-CFM] aspects that are relevant for the connectivity
> monitoring
>            of bidirectional point-to-point PBB-TE connections.
> 
>     4) Is this the right place to define this document or should this be
> done in GELS?
> 
>     5)   In section 2 you make the following statement:
> 
>         2.  GMPLS RSVP-TE Extensions
> 
>            To simplify the configuration of connectivity monitoring,
> when an
>            Ethernet LSP is signalled the associated MEPs should be
> automatically
>            established.  Further more, GMPLS signalling should be able to
>           enable/disable connectivity monitoring of a particular
> Ethernet LSP.
> 
> 
>         To my point in #1 above, you should use the native CFM
> functionality over the ethernet interface and signal
>         those capabilities to the bridges at both ends using the IEEE
> CFM signaling procedures (when and if they
>         are created).  If you want to test the underlying GMPLS LSP(s),
> then you should use some
>         other mechanism defined for that layer such as the work stated
> in draft-ali-ccamp-gmpls-LSP-ping-traceroute-00.txt
> 
> 

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

This email was Anti Virus checked by Astaro Security Gateway. http://www.astaro.com

Delivery-date: Tue, 04 Dec 2007 18:55:34 +0000
Content-class: urn:content-classes:message
Subject: RE: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt
Date: Tue, 4 Dec 2007 19:51:54 +0100
From: "Attila Takacs" <[email-masked]>
To: "Thomas Nadeau" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

This is a multi-part message in MIME format.

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

Hi Thomas,
=20
Thank you for the comments!
Please see answers inline.
=20
Best regards,
Attila

________________________________

	From: Thomas Nadeau [mailto:[email-masked]]=20
	Sent: Tuesday, December 04, 2007 2:58 PM
	To: [email-masked]
	Cc: Attila Takacs; [email-masked]
	Subject: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt
=09
=09
=09
=09
=09
=09
	After reading this draft, I have some questions/comments.
=09
=09
=09
	1) Overall, I am concerned that the definition of a new TLV and
these procedures represent=20
	what amounts to a laying violation and ask that the ADs take a
look at this
=09
	approach closely. This is similar to the now-rejected approach
that was proposed
=09
	in the l2vpn WG about munging CFM + PWs.  To my reading, this is
essentially
=09
	the same thing. If you want to run CFM, run it natively over the
ethernet interfaces and
	have no regard for the underlying topology (GMPLS, PWs, etc...)
otherwise you=20
=09
	will be creating a mess for implementations and
interoperability. =20

The application of the draft is exactly for what you are calling out:
when CFM is run natively over the Ethernet interfaces. The document
focuses on GELS and Ethernet LSPs. That is, to establish CFM entities
for GMPLS controlled Ethernet LSPs. Hence, I think there is no layer
violation issue.

	2) The introductory sections in this draft give a lot of
discussion about fast fault detection. I
=09
	am puzzled by this given that GMPLS networks tend to run over
quickly self-healing
=09
	optical infrastructures. Is it therefore truly necessary to
motivate this work by
=09
	requiring fast CFMs?
=09

It is right that frequent CCMs are not required if the layers below
Ethernet handle protection. However, the ID focuses on Ethernet LSPs
where Ethernet is not just a single hop above a transport LSP. In this
case Ethernet layer (for clarity GELS) may provide protection for
Ethernet LSPs. In any case,  the whole point of the ID is to allow for
the appropriate configuration of CFM for Ethernet LSPs with GMPLS.

	3) This document does not cover E-LMI. Why not?
=09
=09

E-LMI is run over the MEF UNI. The ID focuses on Ethernet LSPs within a
network.
=20

	For the purposes of this document, we only discuss Ethernet OAM
	   [IEEE-CFM] aspects that are relevant for the connectivity
monitoring
	   of bidirectional point-to-point PBB-TE connections. =20
=09
=09
	4) Is this the right place to define this document or should
this be done in GELS?
=09
=09

Well, GELS is done in CCAMP...this seems to be the right place.

	=20
=09
=09
	5)   In section 2 you make the following statement:
=09
=09
	2.  GMPLS RSVP-TE Extensions
=09
=09
	    To simplify the configuration of connectivity monitoring,
when an
	   Ethernet LSP is signalled the associated MEPs should be
automatically
	    established.  Further more, GMPLS signalling should be able
to
	  enable/disable connectivity monitoring of a particular
Ethernet LSP.
=09
=09
=09
=09
	To my point in #1 above, you should use the native CFM
functionality over the ethernet interface and signal
	those capabilities to the bridges at both ends using the IEEE
CFM signaling procedures (when and if they
=09
	are created).  If you want to test the underlying GMPLS LSP(s),
then you should use some
	other mechanism defined for that layer such as the work stated
in draft-ali-ccamp-gmpls-LSP-ping-traceroute-00.txt

See the note to your point #1. There is no relation to the
gmpls-LSP-ping draft.=20

=20
=20

------_=_NextPart_001_01C836A6.BD3C0438
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.1589" name=3DGENERATOR></HEAD>
<BODY=20
style=3D"WORD-WRAP: break-word; webkit-nbsp-mode: space; =
webkit-line-break: after-white-space">
<DIV><SPAN class=3D382281718-04122007><FONT face=3DArial color=3D#0000ff =
size=3D2>Hi=20
Thomas,</FONT></SPAN></DIV>
<DIV><SPAN class=3D382281718-04122007><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D382281718-04122007><FONT face=3DArial color=3D#0000ff =
size=3D2>Thank=20
you&nbsp;for the comments!</FONT></SPAN></DIV>
<DIV><SPAN class=3D382281718-04122007><FONT face=3DArial color=3D#0000ff =
size=3D2>Please=20
see answers inline.</FONT></SPAN></DIV>
<DIV><SPAN class=3D382281718-04122007><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D382281718-04122007><FONT face=3DArial color=3D#0000ff =
size=3D2>Best=20
regards,<BR>Attila</FONT></SPAN></DIV><BR>
<BLOCKQUOTE dir=3Dltr=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> Thomas Nadeau=20
  [mailto:[email-masked]] <BR><B>Sent:</B> Tuesday, December =
04, 2007=20
  2:58 PM<BR><B>To:</B> [email-masked]<BR><B>Cc:</B> Attila Takacs;=20
  [email-masked]<BR><B>Subject:</B>=20
  draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt<BR></FONT><BR></DIV>
  <DIV></DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2></FONT><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT><FONT=20
  face=3DArial color=3D#0000ff size=3D2></FONT><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT><BR>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2></FONT><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT><FONT=20
  face=3DArial color=3D#0000ff size=3D2></FONT><BR=20
  class=3Dwebkit-block-placeholder></DIV>
  <DIV><SPAN class=3DApple-tab-span style=3D"WHITE-SPACE: =
pre"></SPAN>After reading=20
  this draft, I have some questions/comments.<BR=20
  class=3Dwebkit-block-placeholder></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2></FONT><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT><FONT=20
  face=3DArial color=3D#0000ff size=3D2></FONT><BR=20
  class=3Dwebkit-block-placeholder></DIV>
  <DIV><SPAN class=3DApple-tab-span style=3D"WHITE-SPACE: pre"></SPAN>1) =

  Overall,&nbsp;I am concerned that the definition of a new TLV and =
these=20
  procedures represent&nbsp;</DIV>
  <DIV><SPAN class=3DApple-tab-span style=3D"WHITE-SPACE: =
pre"></SPAN>what amounts=20
  to a laying violation and ask that the ADs take a look at this<BR=20
  class=3Dwebkit-block-placeholder></DIV>
  <DIV><SPAN class=3DApple-tab-span style=3D"WHITE-SPACE: =
pre"></SPAN>approach=20
  closely. This is similar to the now-rejected approach that was =
proposed<BR=20
  class=3Dwebkit-block-placeholder></DIV>
  <DIV><SPAN class=3DApple-tab-span style=3D"WHITE-SPACE: pre"></SPAN>in =
the l2vpn=20
  WG about munging CFM + PWs. &nbsp;To my reading, this is =
essentially<BR=20
  class=3Dwebkit-block-placeholder></DIV>
  <DIV><SPAN class=3DApple-tab-span style=3D"WHITE-SPACE: =
pre"></SPAN>the same=20
  thing. If you want to run CFM, run it natively over the ethernet =
interfaces=20
  and</DIV>
  <DIV><SPAN class=3DApple-tab-span style=3D"WHITE-SPACE: =
pre"></SPAN>have no regard=20
  for the underlying topology (GMPLS, PWs, etc...) otherwise =
you&nbsp;<BR=20
  class=3Dwebkit-block-placeholder></DIV>
  <DIV><SPAN class=3DApple-tab-span style=3D"WHITE-SPACE: =
pre"></SPAN>will be=20
  creating a mess for implementations and interoperability.&nbsp;<SPAN=20
  class=3D382281718-04122007><FONT face=3DArial color=3D#0000ff=20
  size=3D2>&nbsp;</FONT></SPAN></DIV></BLOCKQUOTE>
<DIV dir=3Dltr><SPAN class=3D382281718-04122007></SPAN><FONT =
face=3DArial><FONT=20
color=3D#0000ff><FONT size=3D2>T<SPAN class=3D382281718-04122007>he=20
application&nbsp;of the draft is exactly for what you are calling out: =
when CFM=20
is run natively over the Ethernet interfaces. The document focuses on =
GELS and=20
Ethernet LSPs.&nbsp;That is,&nbsp;to establish CFM entities for GMPLS =
controlled=20
Ethernet LSPs.&nbsp;Hence, </SPAN></FONT></FONT></FONT><FONT =
face=3DArial><FONT=20
color=3D#0000ff><FONT size=3D2><SPAN class=3D382281718-04122007>I think =
there is no=20
layer violation issue.</SPAN></FONT></FONT></FONT></DIV>
<DIV dir=3Dltr><FONT face=3DArial color=3D#0000ff size=3D2></FONT><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT><FONT=20
face=3DArial color=3D#0000ff size=3D2></FONT><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT><FONT face=3DArial color=3D#0000ff size=3D2></FONT><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT><BR =
class=3Dwebkit-block-placeholder></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV><SPAN class=3DApple-tab-span style=3D"WHITE-SPACE: =
pre"></SPAN>2)&nbsp;The=20
  introductory sections in this draft give a lot of discussion about =
fast fault=20
  detection. I<BR class=3Dwebkit-block-placeholder></DIV>
  <DIV><SPAN class=3DApple-tab-span style=3D"WHITE-SPACE: pre"></SPAN>am =
puzzled by=20
  this given that GMPLS networks tend to run over quickly =
self-healing<BR=20
  class=3Dwebkit-block-placeholder></DIV>
  <DIV><SPAN class=3DApple-tab-span style=3D"WHITE-SPACE: =
pre"></SPAN>optical=20
  infrastructures. Is it therefore&nbsp;truly&nbsp;necessary to motivate =
this=20
  work by<BR class=3Dwebkit-block-placeholder></DIV>
  <DIV><SPAN class=3DApple-tab-span style=3D"WHITE-SPACE: =
pre"></SPAN>requiring fast=20
  CFMs?<BR class=3Dwebkit-block-placeholder></DIV></BLOCKQUOTE>
<DIV><SPAN class=3D382281718-04122007><FONT face=3DArial color=3D#0000ff =
size=3D2>It is=20
right that frequent CCMs are not required if the layers below Ethernet =
handle=20
protection. However, the ID focuses on Ethernet LSPs where Ethernet =
is&nbsp;not=20
just a single hop&nbsp;above a transport LSP.&nbsp;In this =
case&nbsp;Ethernet=20
layer (for clarity GELS) may provide protection for Ethernet =
LSPs.&nbsp;In any=20
case,&nbsp; the whole point of the ID is to allow for the appropriate=20
configuration of CFM for Ethernet LSPs with GMPLS.</FONT></SPAN></DIV>
<DIV dir=3Dltr><FONT face=3DArial color=3D#0000ff size=3D2></FONT><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT><FONT=20
face=3DArial color=3D#0000ff size=3D2></FONT><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT><FONT face=3DArial color=3D#0000ff size=3D2></FONT><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT><FONT=20
face=3DArial color=3D#0000ff size=3D2></FONT><BR></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV><SPAN class=3DApple-tab-span style=3D"WHITE-SPACE: pre"></SPAN>3) =
This=20
  document does not cover E-LMI. Why not?<BR=20
  class=3Dwebkit-block-placeholder></DIV><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT><FONT face=3DArial=20
  color=3D#0000ff size=3D2></FONT><FONT face=3DArial color=3D#0000ff=20
size=3D2></FONT></BLOCKQUOTE>
<DIV><SPAN class=3D382281718-04122007><FONT face=3DArial color=3D#0000ff =
size=3D2>E-LMI=20
is run over the MEF UNI. The&nbsp;ID focuses on Ethernet LSPs within a=20
network.</FONT></SPAN></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT>&nbsp;</DIV>
<DIV dir=3Dltr><FONT face=3DArial color=3D#0000ff size=3D2></FONT><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT><FONT=20
face=3DArial color=3D#0000ff size=3D2></FONT><BR =
class=3Dwebkit-block-placeholder></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV><SPAN class=3DApple-tab-span style=3D"WHITE-SPACE: =
pre"></SPAN><SPAN=20
  class=3DApple-style-span style=3D"FONT-SIZE: 12px">For the purposes of =
this=20
  document, we only discuss Ethernet OAM</SPAN></DIV>
  <DIV style=3D"MARGIN: 0px; FONT: 12px Helvetica"><SPAN =
class=3DApple-tab-span=20
  style=3D"WHITE-SPACE: pre"></SPAN>&nbsp;&nbsp; [IEEE-CFM] aspects that =
are=20
  relevant for the connectivity monitoring</DIV>
  <DIV style=3D"MARGIN: 0px; FONT: 12px Helvetica"><SPAN =
class=3DApple-tab-span=20
  style=3D"WHITE-SPACE: pre"></SPAN>&nbsp;&nbsp; of bidirectional =
point-to-point=20
  PBB-TE connections. &nbsp;</DIV>
  <DIV style=3D"MARGIN: 0px; FONT: 12px Helvetica"><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT><FONT face=3DArial=20
  color=3D#0000ff size=3D2></FONT><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT><FONT=20
  face=3DArial color=3D#0000ff size=3D2></FONT><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT><FONT face=3DArial color=3D#0000ff size=3D2></FONT><BR =

  class=3Dwebkit-block-placeholder></DIV>
  <DIV style=3D"MARGIN: 0px; FONT: 12px Helvetica"><SPAN =
class=3DApple-tab-span=20
  style=3D"WHITE-SPACE: pre"></SPAN>4) Is this the right place to define =
this=20
  document or should this be done in GELS?<BR=20
  class=3Dwebkit-block-placeholder></DIV><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT><FONT face=3DArial=20
  color=3D#0000ff size=3D2></FONT><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT><FONT=20
  face=3DArial color=3D#0000ff size=3D2></FONT></BLOCKQUOTE>
<DIV dir=3Dltr><SPAN class=3D382281718-04122007><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>Well, GELS is done in CCAMP...this seems to be the right=20
place.</FONT></SPAN></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT>&nbsp;</DIV>
  <DIV style=3D"MARGIN: 0px; FONT: 12px Helvetica"><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT><FONT face=3DArial=20
  color=3D#0000ff size=3D2></FONT><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT><BR=20
  class=3Dwebkit-block-placeholder></DIV>
  <DIV style=3D"MARGIN: 0px; FONT: 12px Helvetica"><SPAN =
class=3DApple-tab-span=20
  style=3D"WHITE-SPACE: pre"></SPAN>5) &nbsp; In section 2 you make the =
following=20
  statement:</DIV>
  <DIV style=3D"MARGIN: 0px; FONT: 12px Helvetica"><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT><FONT face=3DArial=20
  color=3D#0000ff size=3D2></FONT><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT><FONT=20
  face=3DArial color=3D#0000ff size=3D2></FONT><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT><BR class=3Dwebkit-block-placeholder></DIV>
  <DIV style=3D"MARGIN: 0px; FONT: 12px Helvetica"><SPAN =
class=3DApple-tab-span=20
  style=3D"WHITE-SPACE: pre"></SPAN>2.&nbsp; GMPLS RSVP-TE =
Extensions</DIV>
  <DIV style=3D"MIN-HEIGHT: 14px; MARGIN: 0px; FONT: 12px =
Helvetica"><FONT=20
  face=3DArial color=3D#0000ff size=3D2></FONT><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT><FONT face=3DArial=20
  color=3D#0000ff size=3D2></FONT><BR></DIV>
  <DIV style=3D"MARGIN: 0px; FONT: 12px Helvetica"><SPAN =
class=3DApple-tab-span=20
  style=3D"WHITE-SPACE: pre"></SPAN>&nbsp;<SPAN class=3DApple-tab-span=20
  style=3D"WHITE-SPACE: pre"> </SPAN>&nbsp; To simplify the =
configuration of=20
  connectivity monitoring, when an</DIV>
  <DIV style=3D"MARGIN: 0px; FONT: 12px Helvetica"><SPAN =
class=3DApple-tab-span=20
  style=3D"WHITE-SPACE: pre"></SPAN>&nbsp;&nbsp; Ethernet LSP is =
signalled the=20
  associated MEPs should be automatically</DIV>
  <DIV style=3D"MARGIN: 0px; FONT: 12px Helvetica"><SPAN =
class=3DApple-tab-span=20
  style=3D"WHITE-SPACE: pre"></SPAN>&nbsp;<SPAN class=3DApple-tab-span=20
  style=3D"WHITE-SPACE: pre"> </SPAN>&nbsp; established.&nbsp; Further =
more, GMPLS=20
  signalling should be able to</DIV>
  <DIV style=3D"MARGIN: 0px; FONT: 12px Helvetica"><SPAN =
class=3DApple-tab-span=20
  style=3D"WHITE-SPACE: pre"></SPAN>&nbsp;&nbsp;enable/disable =
connectivity=20
  monitoring of a particular Ethernet LSP.</DIV>
  <DIV style=3D"MARGIN: 0px; FONT: 12px Helvetica"><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT><FONT face=3DArial=20
  color=3D#0000ff size=3D2></FONT><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT><BR=20
  class=3Dwebkit-block-placeholder></DIV>
  <DIV style=3D"MARGIN: 0px; FONT: 12px Helvetica"><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT><FONT face=3DArial=20
  color=3D#0000ff size=3D2></FONT><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT><BR=20
  class=3Dwebkit-block-placeholder></DIV>
  <DIV style=3D"MARGIN: 0px; FONT: 12px Helvetica"><SPAN =
class=3DApple-tab-span=20
  style=3D"WHITE-SPACE: pre"></SPAN>To my point in #1 above, you should =
use the=20
  native CFM functionality over the ethernet interface and signal</DIV>
  <DIV style=3D"MARGIN: 0px; FONT: 12px Helvetica"><SPAN =
class=3DApple-tab-span=20
  style=3D"WHITE-SPACE: pre"></SPAN>those capabilities to the bridges at =
both ends=20
  using the IEEE CFM signaling procedures (when and if they<BR=20
  class=3Dwebkit-block-placeholder></DIV>
  <DIV style=3D"MARGIN: 0px; FONT: 12px Helvetica"><SPAN =
class=3DApple-tab-span=20
  style=3D"WHITE-SPACE: pre"></SPAN>are created). &nbsp;If you want to =
test the=20
  underlying GMPLS LSP(s), then you should use some</DIV>
  <DIV style=3D"MARGIN: 0px; FONT: 12px Helvetica"><SPAN =
class=3DApple-tab-span=20
  style=3D"WHITE-SPACE: pre"></SPAN>other mechanism defined for that =
layer such as=20
  the work stated in&nbsp;<SPAN class=3DApple-style-span=20
  style=3D"FONT-WEIGHT: bold; FONT-SIZE: =
13px">draft-ali-ccamp-gmpls-LSP-ping-traceroute-00.txt</SPAN></DIV></BLOC=
KQUOTE>
<DIV dir=3Dltr style=3D"MARGIN: 0px; FONT: 12px Helvetica"><FONT =
face=3DArial><FONT=20
color=3D#0000ff><FONT size=3D2><SPAN class=3D382281718-04122007>See the =
note&nbsp;to=20
your point #1. There is no relation&nbsp;to the gmpls-LSP-ping=20
draft.</SPAN><SPAN=20
class=3D382281718-04122007>&nbsp;</SPAN></FONT></FONT></FONT><BR></DIV>
<DIV dir=3Dltr style=3D"MARGIN: 0px; FONT: 12px Helvetica"><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT>&nbsp;</DIV>
<DIV dir=3Dltr style=3D"MARGIN: 0px; FONT: 12px Helvetica"><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT>&nbsp;</DIV></BODY></HTML>

------_=_NextPart_001_01C836A6.BD3C0438--

Delivery-date: Tue, 04 Dec 2007 13:58:37 +0000
Cc: [email-masked], [email-masked]
From: Thomas Nadeau <[email-masked]>
To: [email-masked]
Subject: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt
Date: Tue, 4 Dec 2007 08:57:43 -0500

--Apple-Mail-19--573868090
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed;
	delsp=yes
Content-Transfer-Encoding: 7bit

	After reading this draft, I have some questions/comments.

	1) Overall, I am concerned that the definition of a new TLV and these  
procedures represent
		what amounts to a laying violation and ask that the ADs take a look  
at this
		approach closely. This is similar to the now-rejected approach that  
was proposed
		in the l2vpn WG about munging CFM + PWs.  To my reading, this is  
essentially
		the same thing. If you want to run CFM, run it natively over the  
ethernet interfaces and
		have no regard for the underlying topology (GMPLS, PWs, etc...)  
otherwise you
		will be creating a mess for implementations and interoperability.

	2) The introductory sections in this draft give a lot of discussion  
about fast fault detection. I
		am puzzled by this given that GMPLS networks tend to run over  
quickly self-healing
		optical infrastructures. Is it therefore truly necessary to motivate  
this work by
		requiring fast CFMs?

	3) This document does not cover E-LMI. Why not?

		For the purposes of this document, we only discuss Ethernet OAM
		   [IEEE-CFM] aspects that are relevant for the connectivity  
monitoring
		   of bidirectional point-to-point PBB-TE connections.

	4) Is this the right place to define this document or should this be  
done in GELS?

	5)   In section 2 you make the following statement:

		2.  GMPLS RSVP-TE Extensions

	 	  To simplify the configuration of connectivity monitoring, when an
		   Ethernet LSP is signalled the associated MEPs should be  
automatically
	 	  established.  Further more, GMPLS signalling should be able to
		  enable/disable connectivity monitoring of a particular Ethernet LSP.

		To my point in #1 above, you should use the native CFM functionality  
over the ethernet interface and signal
		those capabilities to the bridges at both ends using the IEEE CFM  
signaling procedures (when and if they
		are created).  If you want to test the underlying GMPLS LSP(s), then  
you should use some
		other mechanism defined for that layer such as the work stated in  
draft-ali-ccamp-gmpls-LSP-ping-traceroute-00.txt

--Apple-Mail-19--573868090
Content-Type: text/html;
	charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

<html><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; "><br><div><br =
class=3D"webkit-block-placeholder"></div><div><span =
class=3D"Apple-tab-span" style=3D"white-space:pre">	</span>After =
reading this draft, I have some questions/comments.<br =
class=3D"webkit-block-placeholder"></div><div><br =
class=3D"webkit-block-placeholder"></div><div><span =
class=3D"Apple-tab-span" style=3D"white-space:pre">	</span>1) =
Overall,&nbsp;I am concerned that the definition of a new TLV and these =
procedures represent&nbsp;</div><div><span class=3D"Apple-tab-span" =
style=3D"white-space: pre; ">		</span>what amounts to a laying =
violation and ask that the ADs take a look at this<br =
class=3D"webkit-block-placeholder"></div><div><span =
class=3D"Apple-tab-span" style=3D"white-space: pre; ">		=
</span>approach closely. This is similar to the now-rejected approach =
that was proposed<br class=3D"webkit-block-placeholder"></div><div><span =
class=3D"Apple-tab-span" style=3D"white-space: pre; ">		=
</span>in the l2vpn WG about munging CFM + PWs. &nbsp;To my reading, =
this is essentially<br class=3D"webkit-block-placeholder"></div><div><span=
 class=3D"Apple-tab-span" style=3D"white-space: pre; ">		=
</span>the same thing. If you want to run CFM, run it natively over the =
ethernet interfaces and</div><div><span class=3D"Apple-tab-span" =
style=3D"white-space:pre">		</span>have no regard for the =
underlying topology (GMPLS, PWs, etc...) otherwise you&nbsp;<br =
class=3D"webkit-block-placeholder"></div><div><span =
class=3D"Apple-tab-span" style=3D"white-space:pre">		=
</span>will be creating a mess for implementations and =
interoperability.&nbsp;<br =
class=3D"webkit-block-placeholder"></div><div><br =
class=3D"webkit-block-placeholder"></div><div><span =
class=3D"Apple-tab-span" style=3D"white-space:pre">	=
</span>2)&nbsp;The introductory sections in this draft give a lot of =
discussion about fast fault detection. I<br =
class=3D"webkit-block-placeholder"></div><div><span =
class=3D"Apple-tab-span" style=3D"white-space:pre">		=
</span>am puzzled by this given that GMPLS networks tend to run over =
quickly self-healing<br =
class=3D"webkit-block-placeholder"></div><div><span =
class=3D"Apple-tab-span" style=3D"white-space:pre">		=
</span>optical infrastructures. Is it =
therefore&nbsp;truly&nbsp;necessary to motivate this work by<br =
class=3D"webkit-block-placeholder"></div><div><span =
class=3D"Apple-tab-span" style=3D"white-space:pre">		=
</span>requiring fast CFMs?<br =
class=3D"webkit-block-placeholder"></div><div><br></div><div><span =
class=3D"Apple-tab-span" style=3D"white-space:pre">	</span>3) This =
document does not cover E-LMI. Why not?<br =
class=3D"webkit-block-placeholder"></div><div><br =
class=3D"webkit-block-placeholder"></div><div><span =
class=3D"Apple-tab-span" style=3D"white-space:pre">		=
</span><span class=3D"Apple-style-span" style=3D"font-size: 12px; ">For =
the purposes of this document, we only discuss Ethernet =
OAM</span></div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
12px/normal Helvetica; "><span class=3D"Apple-tab-span" =
style=3D"white-space:pre">		</span>&nbsp;&nbsp; [IEEE-CFM] =
aspects that are relevant for the connectivity monitoring</div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 12px/normal Helvetica; =
"><span class=3D"Apple-tab-span" style=3D"white-space:pre">		=
</span>&nbsp;&nbsp; of bidirectional point-to-point PBB-TE connections. =
&nbsp;</div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
12px/normal Helvetica; "><br class=3D"webkit-block-placeholder"></div><div=
 style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 12px/normal Helvetica; =
"><span class=3D"Apple-tab-span" style=3D"white-space:pre">	=
</span>4) Is this the right place to define this document or should this =
be done in GELS?<br class=3D"webkit-block-placeholder"></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 12px/normal Helvetica; =
"><br class=3D"webkit-block-placeholder"></div><div style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: =
normal normal normal 12px/normal Helvetica; "><span =
class=3D"Apple-tab-span" style=3D"white-space:pre">	</span>5) &nbsp; =
In section 2 you make the following statement:</div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 12px/normal Helvetica; =
"><br class=3D"webkit-block-placeholder"></div><div style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: =
normal normal normal 12px/normal Helvetica; "><span =
class=3D"Apple-tab-span" style=3D"white-space:pre">		=
</span>2.&nbsp; GMPLS RSVP-TE Extensions</div><div style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: =
normal normal normal 12px/normal Helvetica; min-height: 14px; =
"><br></div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
12px/normal Helvetica; "><span class=3D"Apple-tab-span" =
style=3D"white-space:pre">	</span>&nbsp;<span =
class=3D"Apple-tab-span" style=3D"white-space:pre">	</span>&nbsp; To =
simplify the configuration of connectivity monitoring, when an</div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 12px/normal Helvetica; =
"><span class=3D"Apple-tab-span" style=3D"white-space:pre">		=
</span>&nbsp;&nbsp; Ethernet LSP is signalled the associated MEPs should =
be automatically</div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
12px/normal Helvetica; "><span class=3D"Apple-tab-span" =
style=3D"white-space:pre">	</span>&nbsp;<span =
class=3D"Apple-tab-span" style=3D"white-space:pre">	</span>&nbsp; =
established.&nbsp; Further more, GMPLS signalling should be able =
to</div><div style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: =
0px; margin-left: 0px; font: normal normal normal 12px/normal Helvetica; =
"><span class=3D"Apple-tab-span" style=3D"white-space:pre">		=
</span>&nbsp;&nbsp;enable/disable connectivity monitoring of a =
particular Ethernet LSP.</div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal Helvetica; "><br =
class=3D"webkit-block-placeholder"></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal Helvetica; "><br =
class=3D"webkit-block-placeholder"></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal Helvetica; "><span class=3D"Apple-tab-span" =
style=3D"white-space:pre">		</span>To my point in #1 above, =
you should use the native CFM functionality over the ethernet interface =
and signal</div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
12px/normal Helvetica; "><span class=3D"Apple-tab-span" =
style=3D"white-space: pre; ">		</span>those capabilities to the =
bridges at both ends using the IEEE CFM signaling procedures (when and =
if they<br class=3D"webkit-block-placeholder"></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 12px/normal Helvetica; =
"><span class=3D"Apple-tab-span" style=3D"white-space: pre; ">		=
</span>are created). &nbsp;If you want to test the underlying GMPLS =
LSP(s), then you should use some</div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal Helvetica; "><span class=3D"Apple-tab-span" =
style=3D"white-space:pre">		</span>other mechanism defined =
for that layer such as the work stated in&nbsp;<span =
class=3D"Apple-style-span" style=3D"font-size: 13px; font-weight: bold; =
">draft-ali-ccamp-gmpls-LSP-ping-traceroute-00.txt</span></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 12px/normal Helvetica; =
"><br></div></body></html>=

--Apple-Mail-19--573868090--

Delivery-date: Tue, 04 Dec 2007 13:45:29 +0000
Cc: Otani Tomohiro <[email-masked]>, "((zali)) Ali Zafar" <[email-masked]>
From: Thomas Nadeau <[email-masked]>
To: [email-masked]
Subject: draft-ali-ccamp-gmpls-LSP-ping-traceroute-00.txt 
Date: Tue, 4 Dec 2007 08:42:55 -0500

	I have some questions/comments about this draft.
	
	0) The draft needs to be organized a bit better so that it is
		clear what you are trying to achieve.  For example,
		some of the introductory text is unclear as to whether
		or not you are verifying the control or data planes (or
		both). At least to my reading.

	1) This solution seems tightly coupled between RFCs 4204 and 4379.
		Is it reasonable to assume that all implementations
		will support 4204?  This also seems to beg the question
		of "are there too many moving parts here?" for this
		to ultimately work and interoperate between 2 vendors.

	2) Which packet formats are to be used in this approach? All I see
		are statements like "send Test messages", but no details of
		that.

	3) Can this approach guarantee that the data plane is checked
		completely, and if not, what percentage of coverage is
		given?

	4) In section 2.2, you stipulate:

	To limit the scope of LSP Verification to a
         particular LSP, LSP-id is used in LOCAL_LINK_ID or
         REMOTE_LINK_ID fields of the LMP message exchanges during
         verification.

	Something similar has been proposed as an addition to lsp ping for
	the multi-cast case. Please check into this to see if this is
	similar enough to reuse that object.

	5) Is the link verification actually sent over the LMP control  
channel or
		the actual data path? Your text is unclear on this:

		        To initiate the link verification procedure, the Ingress
         (Egress) node MUST send a BeginVerify message over a control
         channel with IP address of the destination (source) node of
         the LSP.  To limit the scope of LSP Verification to a
         particular LSP, LSP-id is used in LOCAL_LINK_ID or
         REMOTE_LINK_ID fields of the LMP message exchanges during
         verification. If the LINK_ID field is zero, the verification
         can span multiple LSPs between the set of Ingress/Egress nodes
         involved in the verification process. The rest of the details
         for LSP verification follow the LMP link verification
         procedure [RFC4204].

	RFC4204 states that the link verify messages are NOT to be sent
	over the control channel, and since you want to verify the
	data plane you should follow its rules for this:

	12.5.6.  Test Message (Msg Type = 10)

	   The Test message is transmitted over the data link and is used to
	   verify its physical connectivity.  Unless explicitly stated, these
	   messages MUST be transmitted over UDP like all other LMP messages.
	   The format of the Test messages is as follows:

	   <Test Message> ::= <Common Header> <LOCAL_INTERFACE_ID> <VERIFY_ID>

	   The above transmission order SHOULD be followed.

	   Note that this message is sent over a data link and NOT over the
  	  control channel.  The transport mechanism for the Test message is
  	  negotiated using the Verify Transport Mechanism field of the
  	  BEGIN_VERIFY object and the Verify Transport Response field of the
  	  BEGIN_VERIFY_ACK object (see Sections 13.8 and 13.9).

	6) I suggest passing this document by the MPLS WG and the LSP ping co- 
authors
		to ensure that your desire to reuse that protocol will indeed
		work, and that if this is eventually adopted as a CCAMP work item
		that it not pass WG last call until the MPLS WG has reviewed it.

Delivery-date: Tue, 04 Dec 2007 03:56:55 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Fw: [mpls] working group early review ofdraft-ietf-mpls-mpls-and-gmpls-security-framework-01.txt
Date: Tue, 4 Dec 2007 03:53:46 -0000

Hi CCAMP,

Please keep an eye on this work being done in the MPLS working group. It 
directly affects your protocol work.

Thanks,
Adrian
----- Original Message ----- 
From: "Loa Andersson" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, December 04, 2007 12:46 AM
Subject: [mpls] working group early review 
ofdraft-ietf-mpls-mpls-and-gmpls-security-framework-01.txt

> Working Group,
>
> at the working group meeting today we agreed that it is time for
> a *working group early review* of the
>
> draft-ietf-mpls-mpls-and-gmpls-security-framework-01.txt
>
> We want the working group participants to take the time to
> carefully read and comment on the draft.
>
> Please send your comments to the working group mailing list.
>
> Loa and George
>
> -- 
> 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]
>
> This email was Anti Virus checked by Astaro Security Gateway. 
> http://www.astaro.com
>
>
>
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mpls
> 

Delivery-date: Mon, 03 Dec 2007 04:24:41 +0000
Reply-To: <[email-masked]>
From: "Weiqiang Sun" <[email-masked]>
To: "'Adrian Farrel'" <[email-masked]>, <[email-masked]>
Cc: "'Brungard, Deborah A, ALABS'" <[email-masked]>
Subject: RE: Slides on line
Date: Sun, 2 Dec 2007 23:20:59 -0500
Organization: Shanghai Jiao Tong University

Hi Adrian,

Would you please change the presenter of the lsp-ddpm draft scheduled last
in the Thursday meeting? I will be presenting the draft this time. :)
Thanks for your help and see you in Vancouver.

Weiqiang Sun

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Adrian Farrel
Sent: Sunday, December 02, 2007 2:56 PM
To: [email-masked]
Cc: Brungard, Deborah A, ALABS
Subject: Slides on line

Hi,

A good number of slide sets are already on line. Go to the agenda at 
http://www3.ietf.org/proceedings/07dec/agenda/ccamp.htm and follow the 
links.

Thanks to all who have made the effort to get their slides out early.

Still looking for material for...

Tuesday
- Requirements for GMPLS Inter-Domain Routing (Tomohiro)
- BGP Traffic Engineering Attribute (Yakov, Don, Hamid)
- GMPLS Ethernet Label Switching Architecture and Framework (Don)
- GMPLS control of Ethernet PBB-TE (Don)

Thursday
- ITU-T and OIF progress report (Lyndon)
- ARP For GMPLS controlled PSC Ethernet Interfaces (Zafar)
- OAM Requirements for GMPLS Networks (Tomohiro)
- Ping and Traceroute for GMPLS LSPs in Non-Packet Switched Networks (Zafar)
- GMPLS RSVP-TE Ethernet OAM Extensions (Attila)
- VCAT/LCAS (Greg)
- Lambda labels (Tomohiro)

Apologies if you have already sent slides. Please e-kick me.

Cheers,
Adrian 

Delivery-date: Sun, 02 Dec 2007 19:59:10 +0000
Date: Sun, 02 Dec 2007 19:55:53 +0000
From: Adrian Farrel <[email-masked]>
Subject: Slides on line
To: [email-masked]
Cc: "Brungard, Deborah A, ALABS" <[email-masked]>
Reply-to: Adrian Farrel <[email-masked]>

Hi,

A good number of slide sets are already on line. Go to the agenda at 
http://www3.ietf.org/proceedings/07dec/agenda/ccamp.htm and follow the 
links.

Thanks to all who have made the effort to get their slides out early.

Still looking for material for...

Tuesday
- Requirements for GMPLS Inter-Domain Routing (Tomohiro)
- BGP Traffic Engineering Attribute (Yakov, Don, Hamid)
- GMPLS Ethernet Label Switching Architecture and Framework (Don)
- GMPLS control of Ethernet PBB-TE (Don)

Thursday
- ITU-T and OIF progress report (Lyndon)
- ARP For GMPLS controlled PSC Ethernet Interfaces (Zafar)
- OAM Requirements for GMPLS Networks (Tomohiro)
- Ping and Traceroute for GMPLS LSPs in Non-Packet Switched Networks (Zafar)
- GMPLS RSVP-TE Ethernet OAM Extensions (Attila)
- VCAT/LCAS (Greg)
- Lambda labels (Tomohiro)

Apologies if you have already sent slides. Please e-kick me.

Cheers,
Adrian 

Delivery-date: Sun, 02 Dec 2007 12:54:48 +0000
Content-class: urn:content-classes:message
Subject: comment on draft-otani-ccamp-gmpls-routing-interlink-01.txt
Date: Sun, 2 Dec 2007 13:49:42 +0100
From: "PAPADIMITRIOU Dimitri" <[email-masked]>
To: <[email-masked]>

hi -=20

reading this doc. it seems that two additional elements of analysis
should be taken into account

o) setting up unidirectional PSC LSP (or even other type) leads to an
asymmetric bw counting that comes in addition to the setup bidirectional
LSP

o) ougoing information knowledge poses also the problem of the SC value
at the other end of the link e.g. [LS2C;PSC] link

note: there is a metric setting to be addressed when correlating
information at such boundary

thanks,
-d.