Get $2400 welcome bonus
"Berta Hare" <WendiquasistationaryBegay@chipmunks.com> Tue, 01 January 2008 03:09 UTC
Return-path: <WendiquasistationaryBegay@chipmunks.com>
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J9XVP-0004fL-52; Mon, 31 Dec 2007 22:09:27 -0500
Received: from pool-68-237-249-19.ny325.east.verizon.net ([68.237.249.19] helo=arielmedrano.myhome.westell.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J9XVO-0004JT-IM; Mon, 31 Dec 2007 22:09:26 -0500
Received: from bespeak by chipmunks.com with SMTP id wuYTl5B0UW for <ccamp-archive@ietf.org>; Mon, 31 Dec 2007 22:09:21 +0500
From: Berta Hare <WendiquasistationaryBegay@chipmunks.com>
To: ccamp-archive@ietf.org, ancp-request@ietf.org, cfrg-request@ietf.org, chair@ietf.org, capwap-archive@ietf.org
Subject: Get $2400 welcome bonus
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 1.2 (+)
X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de
X-Message-ID:
Message-ID: <20140418005842.2560.73453.ARCHIVE@ietfa.amsl.com>
X-Date: (the original message had no date)
Date: Tue, 01 Jan 2008 11:09:27 -0000
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/ Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 31 Dec 2007 19:56:13 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C84BE6.E7D709DF" Subject: RE: ccamp minutes Date: Mon, 31 Dec 2007 14:54:07 -0500 Message-ID: <449B2580D802A443A923DABF3EAB82AF0FE08795@OCCLUST04EVS1.ugd.att.com> Thread-Topic: ccamp minutes Thread-Index: AchL3LavtAcbaFe7SBuEfoCOVPhztQACaSHQ From: "BRUNGARD, DEBORAH A, ATTLABS" <dbrungard@att.com> To: <ccamp@ops.ietf.org> 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: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of BRUNGARD, DEBORAH A, ATTLABS Sent: Monday, December 31, 2007 1:41 PM To: ccamp@ops.ietf.org 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 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> </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> owner-ccamp@ops.ietf.org=20 [mailto:owner-ccamp@ops.ietf.org] <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 ccamp@ops.ietf.org<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> </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> </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> </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> </DIV></BODY></HTML> ------_=_NextPart_001_01C84BE6.E7D709DF-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 31 Dec 2007 18:43:55 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C84BDC.B759AB2C" Subject: ccamp minutes Date: Mon, 31 Dec 2007 13:41:11 -0500 Message-ID: <449B2580D802A443A923DABF3EAB82AF0FE08756@OCCLUST04EVS1.ugd.att.com> Thread-Topic: ccamp minutes Thread-Index: AchL3LavtAcbaFe7SBuEfoCOVPhztQ== From: "BRUNGARD, DEBORAH A, ATTLABS" <dbrungard@att.com> To: <ccamp@ops.ietf.org> 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> </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> </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> </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> </DIV></BODY></HTML> ------_=_NextPart_001_01C84BDC.B759AB2C-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 28 Dec 2007 18:58:57 +0000 Message-ID: <04fe01c84983$45362960$0501a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" <adrian@olddog.co.uk> From: "Adrian Farrel" <adrian@olddog.co.uk> To: "David Ward" <dward@cisco.com>, "Tim Polk" <tim.polk@nist.gov> Cc: "BRUNGARD, DEBORAH A, ATTLABS" <dbrungard@att.com>, "Kohei Shiomoto" <shiomoto.kohei@lab.ntt.co.jp>, "Ross Callon" <rcallon@juniper.net>, <ccamp@ops.ietf.org> Subject: Your Discusses and Comments on draft-ietf-ccamp-mpls-gmpls-interwork-fmwk Date: Fri, 28 Dec 2007 18:55:48 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit 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. Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 28 Dec 2007 14:25:38 +0000 Message-ID: <047b01c8495d$118600c0$0501a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" <adrian@olddog.co.uk> From: "Adrian Farrel" <adrian@olddog.co.uk> To: <ccamp@ops.ietf.org> Subject: Updated: Draft response to the OIF Date: Fri, 28 Dec 2007 14:14:52 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit 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 <lyong@ciena.com> Cc: Ross Callon, IETF Routing Area Director <rcallon@juniper.net> David Ward, IETF Routing Area Director <dward@cisco.com> 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 Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 21 Dec 2007 20:23:04 +0000 Message-ID: <01fc01c8440e$d9db2db0$0501a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" <adrian@olddog.co.uk> From: "Adrian Farrel" <adrian@olddog.co.uk> To: "Greg Bernstein" <gregb@grotto-networking.com> Cc: <ccamp@ops.ietf.org> Subject: Re: Liaison received from ITU-T on T-MPLS ring protection Date: Fri, 21 Dec 2007 20:19:13 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit 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" <gregb@grotto-networking.com> To: "Adrian Farrel" <adrian@olddog.co.uk> Cc: <ccamp@ops.ietf.org> 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 > > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 21 Dec 2007 15:37:43 +0000 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <E1J4NDu-0002Sc-4p@stiedprstage1.ietf.org> Date: Mon, 17 Dec 2007 16:10:02 -0500 Cc: ccamp@ops.ietf.org Subject: I-D Action:draft-ietf-ccamp-gmpls-mln-eval-05.txt Reply-To: internet-drafts@ietf.org --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 i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-gmpls-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: mailserv@ietf.org. 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="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-12-17160517.I-D@ietf.org> 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 I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 20 Dec 2007 19:04:11 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; bh=hCYRux0Pbg5pmGlmA1E/Ld8rCGxCQ7gP+GiMTTOSiBI=; b=NiGXwZOL+0syC1GVFaL/NtV+5711EUwqTSe32kEPPoQfYjVLQEa7GemMn7nB6JwdCiv0ccR9i2VkL825q0jya0Mo0rlZuJlu/ljwh/0QFFlL155e5qDZ4c6HvlTi8HXInY7vKOrA0uPrywYV3Ea8czj+u1c57zi4gdskabXQwMk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=GInkc4+fCFGwsLLS+B5SZ0ffbMin9u3pLobwSc07rKyc7Q51pmYPxY/RCuH2PxK+eJHJFmk8bFErHrCDktHx2d9BSy0b4C8fK+FEwVwmePoooJ59PYhCnBezX8g7SudWzV04WjRKsopjergHG0X8GxUm/vkDNBOpsD1C7e98VOA= Message-ID: <cbe76faa0712201053v170f6191rdb43ef5db5e86b82@mail.gmail.com> Date: Thu, 20 Dec 2007 10:53:51 -0800 From: "Richard Rabbat" <rabbat@alum.mit.edu> To: "Greg Bernstein" <gregb@grotto-networking.com> Subject: Re: On Labels for Wavelength Switched Optical Networks... Cc: ccamp <ccamp@ops.ietf.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_23283_11296360.1198176832020" ------=_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 <gregb@grotto-networking.com> 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're perfect :)<br>Richard.<br><br><div class="gmail_quote">On Dec 20, 2007 7:39 AM, Greg Bernstein < <a href="mailto:gregb@grotto-networking.com">gregb@grotto-networking.com</a>> 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'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.<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'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> </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> </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> </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> Now any of the previous formats could be used with the 32 bit lambda label already defined.<span> </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;"> </span></span>While floating point numbers provide great flexibility, as a label they have issues when it comes to comparison operations.<span> </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;"> </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;"> </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;"> </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;"> </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. <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;"> </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;"> </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;"> </span></span>The format includes information on the grid spacing which is important WDM context information useful in many label selection processes.<span> </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> </span>Note that only those frequencies (labels) that fall on the grid are supported and not intermediate frequencies.</p> <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 "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-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 20 Dec 2007 17:35:17 +0000 Message-ID: <476AA711.3090905@grotto-networking.com> Date: Thu, 20 Dec 2007 09:32:01 -0800 From: Greg Bernstein <gregb@grotto-networking.com> User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Adrian Farrel <adrian@olddog.co.uk> CC: ccamp@ops.ietf.org Subject: Re: Liaison received from ITU-T on T-MPLS ring protection Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 20 Dec 2007 15:42:36 +0000 Message-ID: <476A8C9A.6010301@grotto-networking.com> Date: Thu, 20 Dec 2007 07:39:06 -0800 From: Greg Bernstein <gregb@grotto-networking.com> User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: ccamp <ccamp@ops.ietf.org> Subject: Re: On Labels for Wavelength Switched Optical Networks... Content-Type: multipart/alternative; boundary="------------040304080106020609050803" 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 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.<br> <br> Regards<br> <br> Greg B.<br> <br> Greg Bernstein wrote: <blockquote cite="mid:4762AC75.3090304@grotto-networking.com" 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=""> </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=""> </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=""> </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> </o:p>Now any of the previous formats could be used with the 32 bit lambda label already defined.<span style=""> </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: "Times New Roman"; font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-size-adjust: none; font-stretch: normal;"> </span></span><!--[endif]-->While floating point numbers provide great flexibility, as a label they have issues when it comes to comparison operations.<span style=""> </span></p> <p class="MsoNormal" style="margin-left: 0.5in; text-indent: -0.25in;"><!--[if !supportLists]--><span style="">(b)<span style="font-family: "Times New Roman"; font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-size-adjust: none; font-stretch: normal;"> </span></span><!--[endif]-->An integer format with a suitably scaled exponent is relatively simple and just leaves the choice of “exponent” 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: "Times New Roman"; font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-size-adjust: none; font-stretch: normal;"> </span></span><!--[endif]-->Neither format contains any “context” 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: "Times New Roman"; font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-size-adjust: none; font-stretch: normal;"> </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: "Times New Roman"; font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-size-adjust: none; font-stretch: normal;"> </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. <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: "Times New Roman"; font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-size-adjust: none; font-stretch: normal;"> </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: "Times New Roman"; font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-size-adjust: none; font-stretch: normal;"> </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: "Times New Roman"; font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-size-adjust: none; font-stretch: normal;"> </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=""> </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=""> </span>Note that only those frequencies (labels) that fall on the grid are supported and not intermediate frequencies.</p> <p class="MsoNormal"><o:p> </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 “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 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-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 17 Dec 2007 22:01:55 +0000 Message-ID: <035001c840f3$bf07d010$9200a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" <adrian@olddog.co.uk> From: "Adrian Farrel" <adrian@olddog.co.uk> To: "Ross Callon" <rcallon@juniper.net> Cc: <ccamp@ops.ietf.org>, "WG Milestone Tracker" <iesg-secretary@ietf.org>, <dward@cisco.com> Subject: Please publish draft-ietf-ccamp-gmpls-mln-eval-05 Date: Mon, 17 Dec 2007 21:28:10 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit 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. Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 17 Dec 2007 21:30:10 +0000 Message-ID: <034f01c840f3$bd511f60$9200a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" <adrian@olddog.co.uk> From: "Adrian Farrel" <adrian@olddog.co.uk> To: "Ross Callon" <rcallon@juniper.net> Cc: <ccamp@ops.ietf.org>, "WG Milestone Tracker" <iesg-secretary@ietf.org>, <dward@cisco.com> Subject: Please publish draft-ietf-ccamp-gmpls-mln-reqs-07 Date: Mon, 17 Dec 2007 21:25:39 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit 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. Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 17 Dec 2007 21:17:52 +0000 Message-ID: <034801c840f2$1cf34f30$9200a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" <adrian@olddog.co.uk> From: "Adrian Farrel" <adrian@olddog.co.uk> To: <ccamp@ops.ietf.org> Subject: Update: draft-ietf-ccamp-gmpls-mln-eval-05.txt Date: Mon, 17 Dec 2007 21:16:32 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Hi, Only changes are format and I-D nits necessary to advance the I-D to the AD for review. Adrian ----- Original Message ----- From: <Internet-Drafts@ietf.org> To: <i-d-announce@ietf.org> Cc: <ccamp@ops.ietf.org> 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 > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > Internet-Drafts are also available by anonymous FTP. Login with the > username "anonymous" and a password of your e-mail address. After > logging in, type "cd internet-drafts" and then > "get draft-ietf-ccamp-gmpls-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: > mailserv@ietf.org. > 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 > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 17 Dec 2007 21:12:31 +0000 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D Action:draft-ietf-ccamp-gmpls-mln-eval-05.txt Message-Id: <E1J4NDu-0002Sc-4p@stiedprstage1.ietf.org> 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 i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-gmpls-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: mailserv@ietf.org. 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="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-12-17160517.I-D@ietf.org> 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-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 17 Dec 2007 16:25:53 +0000 Message-ID: <030501c840c9$3272fd20$9200a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" <adrian@olddog.co.uk> From: "Adrian Farrel" <adrian@olddog.co.uk> To: <ccamp@ops.ietf.org> Subject: Liaison received from ITU-T on T-MPLS ring protection Date: Mon, 17 Dec 2007 16:18:45 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit 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 Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 17 Dec 2007 14:58:21 +0000 Message-ID: <02e101c840bd$08eaa090$9200a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" <adrian@olddog.co.uk> From: "Adrian Farrel" <adrian@olddog.co.uk> To: <ccamp@ops.ietf.org> Subject: Draft response to the OIF Date: Mon, 17 Dec 2007 14:50:46 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit 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 <lyong@ciena.com> Cc: Ross Callon, IETF Routing Area Director <rcallon@juniper.net> David Ward, IETF Routing Area Director <dward@cisco.com> 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 Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 17 Dec 2007 13:44:10 +0000 Message-ID: <47667C2B.4090100@kddilabs.jp> Date: Mon, 17 Dec 2007 22:39:55 +0900 From: Tomohiro Otani <otani@kddilabs.jp> User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Diego Caviglia <diego.caviglia@ericsson.com>, Greg Bernstein <gregb@grotto-networking.com> Cc: ccamp <ccamp@ops.ietf.org> Subject: Re: On Labels for Wavelength Switched Optical Networks... Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable 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:* owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] *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 Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 17 Dec 2007 09:02:41 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8408B.1556104D" Subject: RE: On Labels for Wavelength Switched Optical Networks... Date: Mon, 17 Dec 2007 09:59:20 +0100 Message-ID: <0428AC48A879ED46A94F39D5665DF684E5DF3C@esealmw110.eemea.ericsson.se> Thread-Topic: On Labels for Wavelength Switched Optical Networks... Thread-Index: Acg+bummec4oBBqjTUK/OmIaHQaRDQCGzQTA From: "Diego Caviglia" <diego.caviglia@ericsson.com> To: "Greg Bernstein" <gregb@grotto-networking.com>, "ccamp" <ccamp@ops.ietf.org> 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: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] 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> </o:p></span></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’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, …) 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> </o:p></span></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> </o:p></span></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> </o:p></span></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> </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'> owner-ccamp@ops.ietf.org = [mailto:owner-ccamp@ops.ietf.org] <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> </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. 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). 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.<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'> </u1:p>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.<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'> </span></span></font>While = floating point numbers provide great flexibility, as a label they have issues = when it comes to comparison operations. <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'> </span></span></font>An integer = format with a suitably scaled exponent is relatively simple and just leaves the = choice of “exponent” 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'> = </span></span></font>Neither format contains any “context” 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'> </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'> </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. <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'> </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'> </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'> </span></span></font>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.<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'> <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 “G.694 label”. 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> </o:p></span></font></pre></div> </div> </body> </html> ------_=_NextPart_001_01C8408B.1556104D-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 17 Dec 2007 02:52:54 +0000 Date: Mon, 17 Dec 2007 10:49:15 +0800 From: Dan Li <danli@huawei.com> Subject: Re: On Labels for Wavelength Switched Optical Networks... To: Greg Bernstein <gregb@grotto-networking.com>, ccamp <ccamp@ops.ietf.org> Message-id: <052c01c84057$6948a4c0$3f4d460a@china.huawei.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_Ad810cjgjsTDLe8cI94HZA)" 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 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0KPE1FVEEgY29udGVudD0iTVNIVE1M IDYuMDAuMjgwMC4xNTYxIiBuYW1lPUdFTkVSQVRPUj4NCjxTVFlMRT48L1NUWUxFPg0KPC9IRUFE Pg0KPEJPRFkgdGV4dD0jMDAwMDAwIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+SGkgR3JlZyw8L0RJ Vj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPkZvciB0aGUgbGFzdCBwYXJ0IG9mIHlvdXIgZW1h aWwsIGRvIHlvdSBtZWFuIHdlIG5lZWQgYSBmaWVsZCBpbiB0aGUgMzJiaXQgDQpsYWJlbCB0byBp bmRpY2F0ZSB0aGlzIGlzIGEgRy42OTQgbGFiZWw/PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0K PERJVj5UaGFua3MsPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5EYW48L0RJVj4NCjxE SVY+Jm5ic3A7PC9ESVY+DQo8QkxPQ0tRVU9URSBkaXI9bHRyIA0Kc3R5bGU9IlBBRERJTkctUklH SFQ6IDBweDsgUEFERElORy1MRUZUOiA1cHg7IE1BUkdJTi1MRUZUOiA1cHg7IEJPUkRFUi1MRUZU OiAjMDAwMDAwIDJweCBzb2xpZDsgTUFSR0lOLVJJR0hUOiAwcHgiPg0KICA8RElWIHN0eWxlPSJG T05UOiA5cHQgJiMyMzQzNTsmIzIwMzA3OyI+LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSA8 L0RJVj4NCiAgPERJViBzdHlsZT0iQkFDS0dST1VORDogI2U0ZTRlNDsgRk9OVDogOXB0ICYjMjM0 MzU7JiMyMDMwNzs7IGZvbnQtY29sb3I6IGJsYWNrIj48Qj5Gcm9tOjwvQj4gDQogIDxBIHRpdGxl PWdyZWdiQGdyb3R0by1uZXR3b3JraW5nLmNvbSANCiAgaHJlZj0ibWFpbHRvOmdyZWdiQGdyb3R0 by1uZXR3b3JraW5nLmNvbSI+R3JlZyBCZXJuc3RlaW48L0E+IDwvRElWPg0KICA8RElWIHN0eWxl PSJGT05UOiA5cHQgJiMyMzQzNTsmIzIwMzA3OyI+PEI+VG86PC9CPiA8QSB0aXRsZT1jY2FtcEBv cHMuaWV0Zi5vcmcgDQogIGhyZWY9Im1haWx0bzpjY2FtcEBvcHMuaWV0Zi5vcmciPmNjYW1wPC9B PiA8L0RJVj4NCiAgPERJViBzdHlsZT0iRk9OVDogOXB0ICYjMjM0MzU7JiMyMDMwNzsiPjxCPlNl bnQ6PC9CPiBTYXR1cmRheSwgRGVjZW1iZXIgMTUsIDIwMDcgMTI6MTYgDQogIEFNPC9ESVY+DQog IDxESVYgc3R5bGU9IkZPTlQ6IDlwdCAmIzIzNDM1OyYjMjAzMDc7Ij48Qj5TdWJqZWN0OjwvQj4g T24gTGFiZWxzIGZvciBXYXZlbGVuZ3RoIFN3aXRjaGVkIA0KICBPcHRpY2FsIE5ldHdvcmtzLi4u PC9ESVY+DQogIDxESVY+PEJSPjwvRElWPg0KICA8UD5IaSBmb2xrcywgYXQgdGhlIFZhbmNvdXZl ciBtZWV0aW5nIHRoZSBsYW1iZGEgbGFiZWwgZm9ybWF0IG9mIE90YW5pLCBldC4gDQogIGFsLjxB IA0KICBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1vdGFuaS1jY2FtcC1n bXBscy1sYW1iZGEtbGFiZWxzLTAxLnR4dCI+IA0KICBkcmFmdC1vdGFuaS1jY2FtcC1nbXBscy1s YW1iZGEtbGFiZWxzLTAxLnR4dDwvQT4gW090YW5pXSB3YXMgcHJlc2VudGVkIGZvciBhIA0KICBz ZWNvbmQgdGltZSBhbmQgYSBmZXcgbmV3IGlzc3VlcyBzZWVtZWQgdG8gYXJpc2UuIEknbSB3cml0 aW5nIHRoaXMgbm90ZSB0byBzZWUgDQogIGlmIHdlIGNhbiByZXNvbHZlIHRoZXNlIG9uIHRoZSBs aXN0IHNvIHRoaXMgd29yayBjYW4gbW92ZSBmb3J3YXJkLCBzaW5jZSB0aGUgDQogIGxhYmVsIGZv cm1hdCBpcyB2YWx1YWJsZSwgaW4gZ2VuZXJhbCwgdG8gdGhlIGNvbnRyb2wgb2Ygd2F2ZWxlbmd0 aCBzd2l0Y2hlZCANCiAgb3B0aWNhbCBuZXR3b3JrcyAoV1NPTikuPEJSPjwvUD4NCiAgPFAgY2xh c3M9TXNvTm9ybWFsPkZpcnN0LCBhIGdlbmVyYWwgMzIgYml0IGxhbWJkYSBsYWJlbCBoYXMgYmVl biBkZWZpbmVkIGluIA0KICBSRkMzNDcxLjxTUEFOPiZuYnNwOyA8L1NQQU4+VGhpcyBwcmV2aW91 cyBsYWJlbCBkb2VzIG5vdCBkaXJlY3RseSByZWxhdGUgdG8gDQogIGVpdGhlciB0aGUgd2F2ZWxl bmd0aCBvciBmcmVxdWVuY3kgb2YgdGhlIGxpZ2h0IHVzZWQgaW4gYSBsYW1iZGEgTFNQIGluIGEg DQogIHN0YW5kYXJkaXplZCB3YXkgKGZvbGtzIGNhbiB1c2UgdGhlIDMyIGJpdHMgYXMgdGhleSBz ZWUgZml0KS48QlI+VG8gY29tZSB1cCANCiAgd2l0aCBhIGNvbXBsZXRlbHkgZ2VuZXJhbCAibGFt YmRhIGxhYmVsIiBvbmUgY291bGQvc2hvdWxkIGRlZmluZSBib3RoIGEgKGkpIA0KICB3YXZlbGVu Z3RoIGxhYmVsIHNwZWNpZmllZCBpbiBtZXRlcnMgYW5kIChpaSkgYSBmcmVxdWVuY3kgbGFiZWwg c3BlY2lmaWVkIGluIA0KICBIZXJ0eiAoSHopLjxTUEFOPiZuYnNwOyA8L1NQQU4+VGhlc2UgY291 bGQgYmUgc3BlY2lmaWVkIGVpdGhlciB3aXRoIGEgMzIgYml0IA0KICBJRUVFIGZsb2F0aW5nIHBv aW50IG51bWJlciBvciB2aWEgYSBzdWl0YWJsZSAzMiBiaXQgaW50ZWdlciBieSBzdWl0YWJseSAN CiAgYWRqdXN0aW5nIHRoZSBiYXNlIHVuaXRzLjxTUEFOPiZuYnNwOyA8L1NQQU4+V2UgY291bGQg cmVwcmVzZW50IHRoZSBmcmVxdWVuY3kgDQogIHZpYSBhIDMyIGJpdCBpbnRlZ2VyIGluIE1Ieiwg dGhlbiBhIDE5My4xVEh6IGxpZ2h0IHNvdXJjZSBjb3VsZCBiZSANCiAgY2hhcmFjdGVyaXplZCBi eSB0aGUgaW50ZWdlciAxOTMsMTAwLDAwMC4gU2ltaWxhcmx5IHdlIGNvdWxkIHJlcHJlc2VudCB0 aGUgDQogIHdhdmVsZW5ndGggbGFiZWwgdmlhIGEgMzIgYml0IGludGVnZXIgaW4gcGljbyBtZXRl cnMgKDEwLTEyIG1ldGVycyksIHRoZW4gYSANCiAgMTU1MG5tIHdhdmVsZW5ndGggY291bGQgYmUg Y2hhcmFjdGVyaXplZCBieSB0aGUgaW50ZWdlciAxLDU1MCwwMDAuPC9QPg0KICA8UCBjbGFzcz1N c29Ob3JtYWw+PE86UD4mbmJzcDs8L086UD5Ob3cgYW55IG9mIHRoZSBwcmV2aW91cyBmb3JtYXRz IGNvdWxkIGJlIA0KICB1c2VkIHdpdGggdGhlIDMyIGJpdCBsYW1iZGEgbGFiZWwgYWxyZWFkeSBk ZWZpbmVkLjxTUEFOPiZuYnNwOyA8L1NQQU4+VGhlIA0KICBwcm9ibGVtIGhlcmUgaXMgdG8gcGlj ayBhIGZvcm1hdCBmb3IgaW50ZXJvcGVyYWJpbGl0eSBhbmQgY29tcGF0aWJpbGl0eSB3aXRoIA0K ICBwb3RlbnRpYWxseSBjb21tb24gd2F2ZWxlbmd0aCBzd2l0Y2hlZCBjb250cm9sIA0KICBvcGVy YXRpb25zLjxCUj48TzpQPjwvTzpQPklzc3VlcyB3aXRoIHRoZSBwcmV2aW91c2x5IG1lbnRpb25l ZCBmb3JtYXRzOjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU4tTEVGVDog MC41aW47IFRFWFQtSU5ERU5UOiAtMC4yNWluIj4mbHQ7IS0tW2lmIA0KICAhc3VwcG9ydExpc3Rz XS0tJmd0OzxTUEFOPihhKTxTUEFOIA0KICBzdHlsZT0iRk9OVDogN3B0ICdUaW1lcyBOZXcgUm9t YW4nOyBmb250LXNpemUtYWRqdXN0OiBub25lOyBmb250LXN0cmV0Y2g6IG5vcm1hbCI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7IA0KICA8L1NQQU4+PC9TUEFOPiZsdDshLS1bZW5kaWZdLS0mZ3Q7V2hpbGUg ZmxvYXRpbmcgcG9pbnQgbnVtYmVycyBwcm92aWRlIGdyZWF0IA0KICBmbGV4aWJpbGl0eSwgYXMg YSBsYWJlbCB0aGV5IGhhdmUgaXNzdWVzIHdoZW4gaXQgY29tZXMgdG8gY29tcGFyaXNvbiANCiAg b3BlcmF0aW9ucy48U1BBTj4mbmJzcDsgPC9TUEFOPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFs IHN0eWxlPSJNQVJHSU4tTEVGVDogMC41aW47IFRFWFQtSU5ERU5UOiAtMC4yNWluIj4mbHQ7IS0t W2lmIA0KICAhc3VwcG9ydExpc3RzXS0tJmd0OzxTUEFOPihiKTxTUEFOIA0KICBzdHlsZT0iRk9O VDogN3B0ICdUaW1lcyBOZXcgUm9tYW4nOyBmb250LXNpemUtYWRqdXN0OiBub25lOyBmb250LXN0 cmV0Y2g6IG5vcm1hbCI+Jm5ic3A7Jm5ic3A7IA0KICA8L1NQQU4+PC9TUEFOPiZsdDshLS1bZW5k aWZdLS0mZ3Q7QW4gaW50ZWdlciBmb3JtYXQgd2l0aCBhIHN1aXRhYmx5IHNjYWxlZCANCiAgZXhw b25lbnQgaXMgcmVsYXRpdmVseSBzaW1wbGUgYW5kIGp1c3QgbGVhdmVzIHRoZSBjaG9pY2Ugb2Yg k2V4cG9uZW50lCB0byBiZSANCiAgZGVjaWRlZC48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbCBz dHlsZT0iTUFSR0lOLUxFRlQ6IDAuNWluOyBURVhULUlOREVOVDogLTAuMjVpbiI+Jmx0OyEtLVtp ZiANCiAgIXN1cHBvcnRMaXN0c10tLSZndDs8U1BBTj4oYyk8U1BBTiANCiAgc3R5bGU9IkZPTlQ6 IDdwdCAnVGltZXMgTmV3IFJvbWFuJzsgZm9udC1zaXplLWFkanVzdDogbm9uZTsgZm9udC1zdHJl dGNoOiBub3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyANCiAgPC9TUEFOPjwvU1BBTj4mbHQ7IS0t W2VuZGlmXS0tJmd0O05laXRoZXIgZm9ybWF0IGNvbnRhaW5zIGFueSCTY29udGV4dJQgDQogIGlu Zm9ybWF0aW9uIGFib3V0IHRoZSBXRE0gc3lzdGVtIGluIGdlbmVyYWwuPC9QPg0KICA8UCBjbGFz cz1Nc29Ob3JtYWw+VGhlIGZvcm1hdCBwcm9wb3NlZCBpbiBbT3RhbmldLiBhdm9pZHMgdGhlIGFi b3ZlIHRocmVlIA0KICBpc3N1ZXMgYW5kIGVuaGFuY2VzIGNvbW1vbiBjb250cm9sIHBsYW5lIG9w ZXJhdGlvbnMgYXMgZm9sbG93czo8L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFS R0lOLUxFRlQ6IDAuNWluOyBURVhULUlOREVOVDogLTAuMjVpbiI+Jmx0OyEtLVtpZiANCiAgIXN1 cHBvcnRMaXN0c10tLSZndDs8U1BBTj4oYSk8U1BBTiANCiAgc3R5bGU9IkZPTlQ6IDdwdCAnVGlt ZXMgTmV3IFJvbWFuJzsgZm9udC1zaXplLWFkanVzdDogbm9uZTsgZm9udC1zdHJldGNoOiBub3Jt YWwiPiZuYnNwOyZuYnNwOyZuYnNwOyANCiAgPC9TUEFOPjwvU1BBTj4mbHQ7IS0tW2VuZGlmXS0t Jmd0O1RoZSBmb3JtYXQgaXMgaW50ZWdlciBiYXNlZCwgaGVuY2UgYXZvaWRzIA0KICBpc3N1ZXMg d2l0aCBmbG9hdGluZyBwb2ludCBjb21wYXJpc29ucy48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1h bCBzdHlsZT0iTUFSR0lOLUxFRlQ6IDAuNWluOyBURVhULUlOREVOVDogLTAuMjVpbiI+Jmx0OyEt LVtpZiANCiAgIXN1cHBvcnRMaXN0c10tLSZndDs8U1BBTj4oYik8U1BBTiANCiAgc3R5bGU9IkZP TlQ6IDdwdCAnVGltZXMgTmV3IFJvbWFuJzsgZm9udC1zaXplLWFkanVzdDogbm9uZTsgZm9udC1z dHJldGNoOiBub3JtYWwiPiZuYnNwOyZuYnNwOyANCiAgPC9TUEFOPjwvU1BBTj4mbHQ7IS0tW2Vu ZGlmXS0tJmd0O1RoZSBmb3JtYXQgaXMgYmFzZWQgb24gdGhlIHdpZGVseSByZWNvZ25pemVkIA0K ICBJVFUtVCBzdGFuZGFyZCBncmlkcyAoSVRVLVQgRy42OTQuMSBhbmQgLjIpIGFuZCBmb3N0ZXJz IGludGVyb3BlcmFiaWxpdHkgbW9yZSANCiAgdGhhbiBwb3RlbnRpYWxseSBhbnkgb3RoZXIgY2hv aWNlLiZuYnNwOzxTUEFOPjwvU1BBTj48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0i TUFSR0lOLUxFRlQ6IDAuNWluOyBURVhULUlOREVOVDogLTAuMjVpbiI+Jmx0OyEtLVtpZiANCiAg IXN1cHBvcnRMaXN0c10tLSZndDs8U1BBTj4oYyk8U1BBTiANCiAgc3R5bGU9IkZPTlQ6IDdwdCAn VGltZXMgTmV3IFJvbWFuJzsgZm9udC1zaXplLWFkanVzdDogbm9uZTsgZm9udC1zdHJldGNoOiBu b3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyANCiAgPC9TUEFOPjwvU1BBTj4mbHQ7IS0tW2VuZGlm XS0tJmd0O1RoZSBJVFUtVCBncmlkcyBjb21lIGluIHZhcmlvdXMgd2lkdGhzIGFuZCANCiAgaGVu Y2UgaGF2ZSBhbiBpbmhlcmVudCBncm93dGggcGF0aC48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1h bCBzdHlsZT0iTUFSR0lOLUxFRlQ6IDAuNWluOyBURVhULUlOREVOVDogLTAuMjVpbiI+Jmx0OyEt LVtpZiANCiAgIXN1cHBvcnRMaXN0c10tLSZndDs8U1BBTj4oZCk8U1BBTiANCiAgc3R5bGU9IkZP TlQ6IDdwdCAnVGltZXMgTmV3IFJvbWFuJzsgZm9udC1zaXplLWFkanVzdDogbm9uZTsgZm9udC1z dHJldGNoOiBub3JtYWwiPiZuYnNwOyZuYnNwOyANCiAgPC9TUEFOPjwvU1BBTj4mbHQ7IS0tW2Vu ZGlmXS0tJmd0O1RoZSBJVFUtVCBncmlkcyBjb21lIGluIGJvdGggZnJlcXVlbmN5IA0KICAoRy42 OTQuMSkgYW5kIHdhdmVsZW5ndGggKEcuNjk0LjIpIGZsYXZvcmVkIHZlcnNpb25zIGFuIGJvdGgg YXJlIGluY29ycG9yYXRlZCANCiAgaW4gdGhlIFtPdGFuaV0gbGFiZWwgZm9ybWF0LjwvUD4NCiAg PFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU4tTEVGVDogMC41aW47IFRFWFQtSU5ERU5U OiAtMC4yNWluIj4mbHQ7IS0tW2lmIA0KICAhc3VwcG9ydExpc3RzXS0tJmd0OzxTUEFOPihlKTxT UEFOIA0KICBzdHlsZT0iRk9OVDogN3B0ICdUaW1lcyBOZXcgUm9tYW4nOyBmb250LXNpemUtYWRq dXN0OiBub25lOyBmb250LXN0cmV0Y2g6IG5vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICA8 L1NQQU4+PC9TUEFOPiZsdDshLS1bZW5kaWZdLS0mZ3Q7VGhlIGZvcm1hdCBpbmNsdWRlcyBpbmZv cm1hdGlvbiBvbiB0aGUgZ3JpZCANCiAgc3BhY2luZyB3aGljaCBpcyBpbXBvcnRhbnQgV0RNIGNv bnRleHQgaW5mb3JtYXRpb24gdXNlZnVsIGluIG1hbnkgbGFiZWwgDQogIHNlbGVjdGlvbiBwcm9j ZXNzZXMuPFNQQU4+Jm5ic3A7IDwvU1BBTj5Gb3IgZXhhbXBsZSBhIHR1bmFibGUgbGFzZXIgYXNz b2NpYXRlZCANCiAgd2l0aCBhIDUwR0h6IHNwYWNpbmcgV0RNIHN5c3RlbSBjb3VsZCBzcGVjaWZ5 IGFjY2VwdGFibGUgbGFiZWwgcmFuZ2UgdmlhIHRoZSANCiAgaW5jbHVzaXZlIHJhbmdlIGxhYmVs IHNldCBtZWNoYW5pc20uPFNQQU4+Jm5ic3A7IDwvU1BBTj5Ob3RlIHRoYXQgb25seSB0aG9zZSAN CiAgZnJlcXVlbmNpZXMgKGxhYmVscykgdGhhdCBmYWxsIG9uIHRoZSBncmlkIGFyZSBzdXBwb3J0 ZWQgYW5kIG5vdCBpbnRlcm1lZGlhdGUgDQogIGZyZXF1ZW5jaWVzLjwvUD4NCiAgPFAgY2xhc3M9 TXNvTm9ybWFsPjxPOlA+PC9POlA+PEJSPkF0IHRoZSBDQ0FNUCBXRyBtZWV0aW5nIGluIFZhbmNv dXZlciBpdCB3YXMgDQogIHBvaW50ZWQgb3V0IChieSBMb3UgQmVyZ2VyKSB0aGF0IHNpbmNlIGEg bGFtYmRhIGxhYmVsIGFscmVhZHkgZXhpc3RzIGFuZCB0aGF0IA0KICBleGlzdGluZyBpbXBsZW1l bnRhdGlvbnMgbWF5IG1ha2UgdXNlIG9mIGl0IHRoYXQgdGhlIHByb3Bvc2VkIGxhYmVsIG9mIFtP dGFuaV0gDQogIHdvdWxkIGJlIGJldHRlciBvZmYgcmVmZXJyZWQgdG8gYXMgYSCTRy42OTQgbGFi ZWyULiBXaXRoIHN1Y2ggYSBjaGFuZ2UgSSB0aGluayANCiAgdGhhdCB0aGlzIGxhYmVsIGZvcm1h dCAoYW5kIGFjY29tcGFueWluZyBkcmFmdCkgc2hvdWxkIG1vdmUgZm9yd2FyZCBhcyBhIA0KICB3 b3JraW5nIGdyb3VwIGRvY3VtZW50LjxCUj48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD5Db21t ZW50cywgc3VnZ2VzdGlvbnMsIGlzc3Vlcz88QlI+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+ UmVnYXJkczxCUj48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD5HcmVnIEIuPEJSPjwvUD48UFJF IGNsYXNzPW1vei1zaWduYXR1cmUgY29scz0iNzIiPi0tIA0KPT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQpEciBHcmVnIEJlcm5zdGVpbiwgR3JvdHRv IE5ldHdvcmtpbmcgKDUxMCkgNTczLTIyMzcNCg0KPC9QUkU+PC9CTE9DS1FVT1RFPjwvQk9EWT48 L0hUTUw+DQo= --Boundary_(ID_Ad810cjgjsTDLe8cI94HZA)-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 14 Dec 2007 19:12:23 +0000 Message-ID: <4762AA56.6050207@chello.nl> Date: Fri, 14 Dec 2007 17:07:50 +0100 From: Huub van Helvoort <hhelvoort@chello.nl> User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Aaron Daubman <daubman@gmail.com> CC: ccamp@ops.ietf.org Subject: Re: Question on draft-ietf-ccamp-gmpls-vcat-lcas and VCG Member Sharing Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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... Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 14 Dec 2007 17:06:46 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Question on draft-ietf-ccamp-gmpls-vcat-lcas and VCG Member Sharing Date: Fri, 14 Dec 2007 17:05:47 -0000 Message-ID: <B03A52266C74544CA7C8CDB507AC53140DDE0984@zharhxm1.corp.nortel.com> Thread-Topic: Question on draft-ietf-ccamp-gmpls-vcat-lcas and VCG Member Sharing Thread-Index: Acg+aos7kmLW3KR9R36NDCMFvbrOkgABOz8g From: "Trevor Wilson" <wilsont@nortel.com> To: "Aaron Daubman" <daubman@gmail.com>, <ccamp@ops.ietf.org> 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: wilsont@nortel.com 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: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Aaron Daubman Sent: 14 December 2007 15:34 To: ccamp@ops.ietf.org 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 Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 14 Dec 2007 16:39:31 +0000 Message-ID: <4762B17B.5080308@grotto-networking.com> Date: Fri, 14 Dec 2007 08:38:19 -0800 From: Greg Bernstein <gregb@grotto-networking.com> User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Aaron Daubman <daubman@gmail.com> CC: ccamp@ops.ietf.org Subject: Re: Question on draft-ietf-ccamp-gmpls-vcat-lcas and VCG Member Sharing Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 14 Dec 2007 16:18:46 +0000 Message-ID: <4762AC75.3090304@grotto-networking.com> Date: Fri, 14 Dec 2007 08:16:53 -0800 From: Greg Bernstein <gregb@grotto-networking.com> User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: ccamp <ccamp@ops.ietf.org> Subject: On Labels for Wavelength Switched Optical Networks... Content-Type: multipart/alternative; boundary="------------040908000103070203060209" 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=""> </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=""> </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=""> </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> </o:p>Now any of the previous formats could be used with the 32 bit lambda label already defined.<span style=""> </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: "Times New Roman"; font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-size-adjust: none; font-stretch: normal;"> </span></span><!--[endif]-->While floating point numbers provide great flexibility, as a label they have issues when it comes to comparison operations.<span style=""> </span></p> <p class="MsoNormal" style="margin-left: 0.5in; text-indent: -0.25in;"><!--[if !supportLists]--><span style="">(b)<span style="font-family: "Times New Roman"; font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-size-adjust: none; font-stretch: normal;"> </span></span><!--[endif]-->An integer format with a suitably scaled exponent is relatively simple and just leaves the choice of “exponent” 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: "Times New Roman"; font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-size-adjust: none; font-stretch: normal;"> </span></span><!--[endif]-->Neither format contains any “context” 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: "Times New Roman"; font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-size-adjust: none; font-stretch: normal;"> </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: "Times New Roman"; font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-size-adjust: none; font-stretch: normal;"> </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. <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: "Times New Roman"; font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-size-adjust: none; font-stretch: normal;"> </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: "Times New Roman"; font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-size-adjust: none; font-stretch: normal;"> </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: "Times New Roman"; font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-size-adjust: none; font-stretch: normal;"> </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=""> </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=""> </span>Note that only those frequencies (labels) that fall on the grid are supported and not intermediate frequencies.</p> <p class="MsoNormal"><o:p> </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 “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 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-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 14 Dec 2007 15:36:15 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=sAfRaOYLK1pU2jGd4aS3oncsH/UOkja9jTukwnjjXyw=; b=n2P1YIR3z0IVpAITUaHmmcQy2oo7b/xTZmMt4l8WisslOQpt9pPQNx/WCsTGzZWdQYNFLdyfGmpN2PS4d2B4326eHIyEIOLQIUSs5/MaWoRy//RbTqYVlgv8QmYLkCRL40Q+WE5ceDSErCXRmXR0a7aQ6+09jPZoOnb4EfpGM1w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=Sa9JdN3lwb3n3ZeWTFxns/1U1Ey6xO4E0qWDwAH7NqLlfgvj/UI0Er0dGjt09Ux6kGDOAARIm/mhY+3uHOCidTaM8I96LCpMTdbZLapVUDHFG5uhxAeFmLQwxyaETf51jgz1oKkN5cMcqZFVdjc06RMg4XZDFhmQfYPb0dmFcCo= Message-ID: <ae6373410712140733r570b562g7437f88b76f0217d@mail.gmail.com> Date: Fri, 14 Dec 2007 10:33:30 -0500 From: "Aaron Daubman" <daubman@gmail.com> To: ccamp@ops.ietf.org Subject: Question on draft-ietf-ccamp-gmpls-vcat-lcas and VCG Member Sharing MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline 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: ccamp-data@psg.com Delivery-date: Wed, 12 Dec 2007 23:07:37 +0000 To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: RFC 5073 on IGP Routing Protocol Extensions for Discovery of Traffic Engineering Node Capabilities From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, ccamp@ops.ietf.org Message-Id: <20071212230501.5EE4FFF1FD@bosco.isi.edu> 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: jpv@cisco.com, jeanlouis.leroux@orange-ftgroup.com 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 IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG 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 RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 10 Dec 2007 14:14:46 +0000 Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <B69BE7D1-1507-4553-847C-13A5E6C0F6B9@cisco.com> Cc: Ashok Narayanan <ashokn@cisco.com>, Jukka Manner MJ <jmanner@cs.Helsinki.FI>, allan GUILLOU <allan.guillou@neufcegetel.fr>, hemant.malik@airtel.in, tsvwg tsvwg <tsvwg@ietf.org>, Le Faucheur Francois <flefauch@cisco.com> Content-Transfer-Encoding: 7bit From: Francois Le Faucheur IMAP <flefauch@cisco.com> Subject: Re: CCAMP Vancouver comments on draft-ietf-tsvwg-rsvp-proxy-proto Date: Mon, 10 Dec 2007 15:12:10 +0100 To: ccamp@ops.ietf.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2698; t=1197295941; x=1198159941; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=flefauch@cisco.com; z=From:=20Francois=20Le=20Faucheur=20IMAP=20<flefauch@cisco. com> |Subject:=20Re=3A=20CCAMP=20Vancouver=20comments=20on=20dra ft-ietf-tsvwg-rsvp-proxy-proto |Sender:=20; bh=k/guwalT0lZwkKYy+MUmpGLpCv5YlhKXm9HqkfARFTQ=; b=l8nUtlGzH4OQ6gYRTEIO/aSBnW+NOwAa0YCB1/sBckqlqDNcBzLLgUMiS+ 0OK9/dq2UB2MAwGK9UP4ONIQCu0YkutLHIsKah5nmaJXWOKcrXcwQSqIOlys rVCxSodMBW; Authentication-Results: ams-dkim-2; header.From=flefauch@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); 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. " Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 08 Dec 2007 04:53:34 +0000 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D Action:draft-ietf-ccamp-gmpls-ason-routing-ospf-04.txt Message-Id: <E1J0rda-0001XA-6S@stiedprstage1.ietf.org> 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 i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-gmpls-ason-routing-ospf-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: mailserv@ietf.org. 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="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-12-07234038.I-D@ietf.org> 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-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 06 Dec 2007 19:24:17 +0000 Message-ID: <47584C19.9020204@pi.se> Date: Thu, 06 Dec 2007 20:23:05 +0100 From: Loa Andersson <loa@pi.se> Organization: Acreo AB User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: neil.2.harrison@bt.com CC: danli@huawei.com, diego.caviglia@ericsson.com, Attila.Takacs@ericsson.com, tnadeau@lucidvision.com, ccamp@ops.ietf.org Subject: Re: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit yes - that was what I asked :) /Loa neil.2.harrison@bt.com 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:loa@pi.se] >> Sent: 05 December 2007 20:37 >> To: Dan Li >> Cc: Diego Caviglia; Harrison,N,Neil,DMN R; Attila Takacs; >> tnadeau@lucidvision.com; ccamp@ops.ietf.org >> 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: neil.2.harrison@bt.com ; Attila Takacs ; >> tnadeau@lucidvision.com >>> Cc: ccamp@ops.ietf.org >>> 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: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] >>> Sent: martedì 4 dicembre 2007 22.55 >>> To: Attila Takacs; tnadeau@lucidvision.com; Diego Caviglia >>> Cc: ccamp@ops.ietf.org >>> 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: owner-ccamp@ops.ietf.org >> [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Attila Takacs >>> Sent: 05 December 2007 02:03 >>> To: Thomas Nadeau; Diego Caviglia >>> Cc: ccamp@ops.ietf.org >>> Subject: RE: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt >>> >>> Hi Tom, >>> >>> please see inline. >>> >>> Best regards, >>> >>> Attila >>> >>> >>> >>> >>> >> ---------------------------------------------------------------------- >>> ---- >>> >>> From: Thomas Nadeau [mailto:tnadeau@lucidvision.com] >>> Sent: Wednesday, December 05, 2007 2:19 AM >>> To: Diego Caviglia >>> Cc: Attila Takacs; ccamp@ops.ietf.org; >> balazs.gero@ericsson.com >>> 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: owner-ccamp@ops.ietf.org >> [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Thomas Nadeau >>> Sent: martedì 4 dicembre 2007 11.30 >>> To: Attila Takacs >>> Cc: ccamp@ops.ietf.org; balazs.gero@ericsson.com >>> 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:tnadeau@lucidvision.com] >>> Sent: Tuesday, December 04, 2007 2:58 PM >>> To: ccamp@ops.ietf.org >>> Cc: Attila Takacs; balazs.gero@ericsson.com >>> 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: loa.andersson@acreo.se >> loa@pi.se >> >> 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: loa.andersson@acreo.se loa@pi.se This email was Anti Virus checked by Astaro Security Gateway. http://www.astaro.com Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 06 Dec 2007 19:17:07 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt Date: Thu, 6 Dec 2007 19:14:17 -0000 Message-ID: <2ECAA42C79676B42AEBAC11229CA7D0C018D2366@E03MVB2-UKBR.domain1.systemhost.net> Thread-Topic: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt Thread-Index: Acg3fqLx+kew6ly0RDmqpYbVOHGE5AAvR4Eg From: <neil.2.harrison@bt.com> To: <loa@pi.se>, <danli@huawei.com> Cc: <diego.caviglia@ericsson.com>, <Attila.Takacs@ericsson.com>, <tnadeau@lucidvision.com>, <ccamp@ops.ietf.org> 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:loa@pi.se]=20 > Sent: 05 December 2007 20:37 > To: Dan Li > Cc: Diego Caviglia; Harrison,N,Neil,DMN R; Attila Takacs;=20 > tnadeau@lucidvision.com; ccamp@ops.ietf.org > 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: neil.2.harrison@bt.com ; Attila Takacs ;=20 > tnadeau@lucidvision.com=20 > > Cc: ccamp@ops.ietf.org=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: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]=20 > > Sent: marted=EC 4 dicembre 2007 22.55 > > To: Attila Takacs; tnadeau@lucidvision.com; Diego Caviglia > > Cc: ccamp@ops.ietf.org > > 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: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Attila Takacs > > Sent: 05 December 2007 02:03 > > To: Thomas Nadeau; Diego Caviglia > > Cc: ccamp@ops.ietf.org > > 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:tnadeau@lucidvision.com]=20 > > Sent: Wednesday, December 05, 2007 2:19 AM > > To: Diego Caviglia > > Cc: Attila Takacs; ccamp@ops.ietf.org;=20 > balazs.gero@ericsson.com > > 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: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Thomas Nadeau > > Sent: marted=EC 4 dicembre 2007 11.30 > > To: Attila Takacs > > Cc: ccamp@ops.ietf.org; balazs.gero@ericsson.com > > 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:tnadeau@lucidvision.com]=20 > > Sent: Tuesday, December 04, 2007 2:58 PM > > To: ccamp@ops.ietf.org > > Cc: Attila Takacs; balazs.gero@ericsson.com > > 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: loa.andersson@acreo.se > loa@pi.se >=20 > This email was Anti Virus checked by Astaro Security Gateway.=20 http://www.astaro.com Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 06 Dec 2007 16:24:03 +0000 Message-ID: <47582192.2090801@psg.com> Date: Thu, 06 Dec 2007 17:21:38 +0100 From: dimitri papadimitriou <dpapadimitriou@psg.com> Reply-To: dpapadimitriou@psg.com User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Adrian Farrel <adrian@olddog.co.uk> CC: Loa Andersson <loa@pi.se>, ccamp <ccamp@ops.ietf.org> Subject: Re: GELS: what happened alternatively what will happen Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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" <loa@pi.se> > To: "ccamp" <ccamp@ops.ietf.org> > 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: loa.andersson@acreo.se >> loa@pi.se >> >> This email was Anti Virus checked by Astaro Security Gateway. >> http://www.astaro.com >> >> >> > > > > > . > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 06 Dec 2007 15:00:26 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=w6rrDV1px2URYMLwS6/SsFLQ2zwJ2njAeeg4CFjdI4701UXZcUeZCPY3HlSN7KEQsZwTygMNDBMiZ+U2GL5t8NWQV/jxfAcydXolYp1ZhZzsnABhnTBKUsFUquLXIHu3/QrSdzXdv3MgPQjPgjj24DCYT5IKh0s2/zgKVSNY0e8=; Date: Thu, 6 Dec 2007 06:58:03 -0800 (PST) From: Igor Bryskin <i_bryskin@yahoo.com> Subject: Re: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt To: Attila Takacs <Attila.Takacs@ericsson.com>, Wataru Imajuku <imajuku.wataru@lab.ntt.co.jp> Cc: ccamp@ops.ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-913381410-1196953083=:79554" Message-ID: <971230.79554.qm@web36805.mail.mud.yahoo.com> --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 <Attila.Takacs@ericsson.com> To: Wataru Imajuku <imajuku.wataru@lab.ntt.co.jp> Cc: ccamp@ops.ietf.org 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:imajuku.wataru@lab.ntt.co.jp] Sent: Wednesday, December 05, 2007 9:53 PM To: Attila Takacs Cc: ccamp@ops.ietf.org 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:danli@huawei.com] Sent: Wednesday, December 05, 2007 6:01 PM To: Diego Caviglia; neil.2.harrison@bt.com; Attila Takacs; tnadeau@lucidvision.com Cc: ccamp@ops.ietf.org 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: neil.2.harrison@bt.com ; Attila Takacs ; tnadeau@lucidvision.com Cc: ccamp@ops.ietf.org 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: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] Sent: marted$B!&(B4 dicembre 2007 22.55 To: Attila Takacs; tnadeau@lucidvision.com; Diego Caviglia Cc: ccamp@ops.ietf.org 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: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Attila Takacs Sent: 05 December 2007 02:03 To: Thomas Nadeau; Diego Caviglia Cc: ccamp@ops.ietf.org Subject: RE: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt Hi Tom, please see inline. Best regards, Attila From: Thomas Nadeau [mailto:tnadeau@lucidvision.com] Sent: Wednesday, December 05, 2007 2:19 AM To: Diego Caviglia Cc: Attila Takacs; ccamp@ops.ietf.org; balazs.gero@ericsson.com 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: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Thomas Nadeau Sent: marted$B!&(B4 dicembre 2007 11.30 To: Attila Takacs Cc: ccamp@ops.ietf.org; balazs.gero@ericsson.com 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:tnadeau@lucidvision.com] Sent: Tuesday, December 04, 2007 2:58 PM To: ccamp@ops.ietf.org Cc: Attila Takacs; balazs.gero@ericsson.com 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 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.<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 <Attila.Takacs@ericsson.com><br>To: Wataru Imajuku <imajuku.wataru@lab.ntt.co.jp><br>Cc: ccamp@ops.ietf.org<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> </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> </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., 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. </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> </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 is needed, again to have 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> </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 accounts for flexibility.</font></span></div> <div><span class="434585301-06122007"><font color="#0000ff" face="Arial" size="2"></font></span> </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> </div> <div><span class="434585301-06122007"><font color="#0000ff" face="Arial" size="2"></font></span> </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:imajuku.wataru@lab.ntt.co.jp] <br><b>Sent:</b> Wednesday, December 05, 2007 9:53 PM<br><b>To:</b> Attila Takacs<br><b>Cc:</b> ccamp@ops.ietf.org<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> I understand this proposal automates manual configuration to set CFM interval in data plane.<br> Control of CFM interval is new issue which GMPLS signaling mechanism has not covered.<br> 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> On the other hand, I could not understand why do you need M bit in Admin Status Object.<br> Why do not use A=1 ?<br> 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"> <br><font color="#0000ff" face="arial" size="2">Hi all,<br></font> <br><font color="#0000ff" face="arial" size="2">Neil's and Dan's summary are exact. Thanks for your comments!<br></font> <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> <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:danli@huawei.com" target="_blank" href="mailto:danli@huawei.com">mailto:danli@huawei.com</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; neil.2.harrison@bt.com; Attila Takacs; tnadeau@lucidvision.com<br> </font></dd><dd><font face="tahoma" size="2">Cc: ccamp@ops.ietf.org<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> </dd><dd>I think there is a misunderstanding with respect to the objective of this draft. <br> </dd><dd><br> </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> </dd><dd>Regards,<br> </dd><dd><br> </dd><dd>Dan<br> </dd><dd><br> </dd><dd><br> </dd><dd>----- Original Message ----- <br> </dd><dd>From: <a rel="nofollow" ymailto="mailto:diego.caviglia@ericsson.com" target="_blank" href="mailto:diego.caviglia@ericsson.com">Diego Caviglia</a> <br> </dd><dd>To: <a rel="nofollow" ymailto="mailto:neil.2.harrison@bt.com" target="_blank" href="mailto:neil.2.harrison@bt.com">neil.2.harrison@bt.com</a> ; <a rel="nofollow" ymailto="mailto:Attila.Takacs@ericsson.com" target="_blank" href="mailto:Attila.Takacs@ericsson.com">Attila Takacs</a> ; <a rel="nofollow" ymailto="mailto:tnadeau@lucidvision.com" target="_blank" href="mailto:tnadeau@lucidvision.com">tnadeau@lucidvision.com</a> <br> </dd><dd>Cc: <a rel="nofollow" ymailto="mailto:ccamp@ops.ietf.org" target="_blank" href="mailto:ccamp@ops.ietf.org">ccamp@ops.ietf.org</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"> Yes I totally agree with your analysis.<br></font><br> </dd><dd><font color="#000080" face="arial" size="2"><br></font><br> </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> </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> </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> </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:neil.2.harrison@bt.com" target="_blank" href="mailto:neil.2.harrison@bt.com">neil.2.harrison@bt.com</a> [<a rel="nofollow" ymailto="mailto:neil.2.harrison@bt.com" target="_blank" href="mailto:neil.2.harrison@bt.com">mailto:neil.2.harrison@bt.com</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:tnadeau@lucidvision.com" target="_blank" href="mailto:tnadeau@lucidvision.com">tnadeau@lucidvision.com</a>; Diego Caviglia<br> </font></dd><dd><font face="tahoma" size="2">Cc: <a rel="nofollow" ymailto="mailto:ccamp@ops.ietf.org" target="_blank" href="mailto:ccamp@ops.ietf.org">ccamp@ops.ietf.org</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> </dd><dd><font color="#800000" face="comic sans ms" size="2">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.<br></font><br> </dd><dd><font face="times new roman"><br></font><br> </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). 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.<br></font><br> </dd><dd><font face="times new roman"><br></font><br> </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. 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.<br></font><br> </dd><dd><font face="times new roman"><br></font><br> </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: owner-ccamp@ops.ietf.org [<a rel="nofollow" ymailto="mailto:owner-ccamp@ops.ietf.org" target="_blank" href="mailto:owner-ccamp@ops.ietf.org">mailto:owner-ccamp@ops.ietf.org</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: ccamp@ops.ietf.org<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:tnadeau@lucidvision.com" target="_blank" href="mailto:tnadeau@lucidvision.com">mailto:tnadeau@lucidvision.com</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; ccamp@ops.ietf.org; balazs.gero@ericsson.com<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> </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"> 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> </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> </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? <br></font><br></dd></dl><font face="times new roman"> <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"> <br></font><br><font face="times new roman"> <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"> <br></font><br><font face="times new roman">No, I do not agree. 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"> <br></font><br><font face="times new roman"> <br></font><br><font color="#0000ff" face="arial" size="2">Sorry, I cannot follow.<br></font><br><font face="times new roman"> <br></font><br><font face="times new roman"> <br></font> <dl><br> <dd><font face="times new roman"><br></font><br> </dd><dd><font face="times new roman"><br></font><br> </dd><dd><font face="times new roman"><br></font><br> </dd><dd><font face="times new roman">--Tom<br></font><br> </dd><dd><font face="times new roman"><br></font><br> </dd><dd><font face="times new roman"><br></font><br><font face="times new roman"><br><br></font> </dd><dd><font color="#000080" face="arial" size="2"> </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:owner-ccamp@ops.ietf.org" target="_blank" href="mailto:owner-ccamp@ops.ietf.org">owner-ccamp@ops.ietf.org</a> [<a rel="nofollow" ymailto="mailto:owner-ccamp@ops.ietf.org" target="_blank" href="mailto:owner-ccamp@ops.ietf.org">mailto:owner-ccamp@ops.ietf.org</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:ccamp@ops.ietf.org" target="_blank" href="mailto:ccamp@ops.ietf.org">ccamp@ops.ietf.org</a>; <a rel="nofollow" ymailto="mailto:balazs.gero@ericsson.com" target="_blank" href="mailto:balazs.gero@ericsson.com">balazs.gero@ericsson.com</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:tnadeau@lucidvision.com" target="_blank" href="mailto:tnadeau@lucidvision.com">mailto:tnadeau@lucidvision.com</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:ccamp@ops.ietf.org" target="_blank" href="mailto:ccamp@ops.ietf.org">ccamp@ops.ietf.org</a><br> </font></dd><dd><font face="tahoma" size="2">Cc: Attila Takacs; <a rel="nofollow" ymailto="mailto:balazs.gero@ericsson.com" target="_blank" href="mailto:balazs.gero@ericsson.com">balazs.gero@ericsson.com</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. 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"> </font>This solution specifically only works for GMPLS ethernet LSPs, right? <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? 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? 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, 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"> [IEEE-CFM] aspects that are relevant for the connectivity monitoring<br></font><br> </dd><dd><font face="helvetica" size="1"> of bidirectional point-to-point PBB-TE connections. <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) In section 2 you make the following statement:<br></font><br> </dd><dd><font face="helvetica" size="1">2. GMPLS RSVP-TE Extensions<br></font><br> </dd><dd><font face="helvetica" size="1"> To simplify the configuration of connectivity monitoring, when an<br></font><br> </dd><dd><font face="helvetica" size="1"> Ethernet LSP is signalled the associated MEPs should be automatically<br></font><br> </dd><dd><font face="helvetica" size="1"> established. Further more, GMPLS signalling should be able to<br></font><br> </dd><dd><font face="helvetica" size="1"> 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). 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"> </font>The point I am making is that perhaps it should.<br><br><font face="times new roman"> </font>--Tom<br><br><font face="times new roman"> <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-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 06 Dec 2007 10:35:46 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt Date: Thu, 6 Dec 2007 11:33:56 +0100 Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB026051A31A9@ftrdmel2> Thread-Topic: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt Thread-Index: Acg3jXZaSbMWwJMzR3OTicQlihNz0gAY+PTg From: "MEURIC Julien RD-CORE-LAN" <julien.meuric@orange-ftgroup.com> To: "Thomas Nadeau" <tnadeau@lucidvision.com> Cc: <ccamp@ops.ietf.org> 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: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] 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: neil.2.harrison@bt.com ; Attila Takacs ; tnadeau@lucidvision.com >> Cc: ccamp@ops.ietf.org >> 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: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] >> Sent: marted=EC 4 dicembre 2007 22.55 >> To: Attila Takacs; tnadeau@lucidvision.com; Diego Caviglia >> Cc: ccamp@ops.ietf.org >> 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: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] =20 >> On Behalf Of Attila Takacs >> Sent: 05 December 2007 02:03 >> To: Thomas Nadeau; Diego Caviglia >> Cc: ccamp@ops.ietf.org >> Subject: RE: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt >> >> Hi Tom, >> >> please see inline. >> >> Best regards, >> >> Attila >> >> >> >> >> = -------------------------------------------------------------------------= - >> >> From: Thomas Nadeau [mailto:tnadeau@lucidvision.com] >> Sent: Wednesday, December 05, 2007 2:19 AM >> To: Diego Caviglia >> Cc: Attila Takacs; ccamp@ops.ietf.org; balazs.gero@ericsson.com >> 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: owner-ccamp@ops.ietf.org [mailto:owner-=20 >> ccamp@ops.ietf.org] On Behalf Of Thomas Nadeau >> Sent: marted=EC 4 dicembre 2007 11.30 >> To: Attila Takacs >> Cc: ccamp@ops.ietf.org; balazs.gero@ericsson.com >> 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:tnadeau@lucidvision.com] >> Sent: Tuesday, December 04, 2007 2:58 PM >> To: ccamp@ops.ietf.org >> Cc: Attila Takacs; balazs.gero@ericsson.com >> 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: loa.andersson@acreo.se > loa@pi.se > > This email was Anti Virus checked by Astaro Security Gateway. = http://www.astaro.com > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 06 Dec 2007 09:58:43 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt Date: Thu, 6 Dec 2007 09:55:04 -0000 Message-ID: <2ECAA42C79676B42AEBAC11229CA7D0C018813BC@E03MVB2-UKBR.domain1.systemhost.net> Thread-Topic: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt Thread-Index: Acg3i+1GEuVpw1alT4uzeK4Jfb5eVQAUoEtA From: <neil.2.harrison@bt.com> To: <tnadeau@lucidvision.com>, <loa@pi.se> Cc: <danli@huawei.com>, <diego.caviglia@ericsson.com>, <Attila.Takacs@ericsson.com>, <ccamp@ops.ietf.org> 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: neil.2.harrison@bt.com ; Attila Takacs ; > tnadeau@lucidvision.com > >> Cc: ccamp@ops.ietf.org > >> 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: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] > >> Sent: marted=EC 4 dicembre 2007 22.55 > >> To: Attila Takacs; tnadeau@lucidvision.com; Diego Caviglia > >> Cc: ccamp@ops.ietf.org > >> 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: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] = > >> On Behalf Of Attila Takacs > >> Sent: 05 December 2007 02:03 > >> To: Thomas Nadeau; Diego Caviglia > >> Cc: ccamp@ops.ietf.org > >> 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:tnadeau@lucidvision.com] > >> Sent: Wednesday, December 05, 2007 2:19 AM > >> To: Diego Caviglia > >> Cc: Attila Takacs; ccamp@ops.ietf.org; > balazs.gero@ericsson.com > >> 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: owner-ccamp@ops.ietf.org [mailto:owner-=20 > >> ccamp@ops.ietf.org] On Behalf Of Thomas Nadeau > >> Sent: marted=EC 4 dicembre 2007 11.30 > >> To: Attila Takacs > >> Cc: ccamp@ops.ietf.org; balazs.gero@ericsson.com > >> 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:tnadeau@lucidvision.com] > >> Sent: Tuesday, December 04, 2007 2:58 PM > >> To: ccamp@ops.ietf.org > >> Cc: Attila Takacs; balazs.gero@ericsson.com > >> 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: loa.andersson@acreo.se > > loa@pi.se > > > > This email was Anti Virus checked by Astaro Security Gateway. > > http://www.astaro.com > > > > >=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 06 Dec 2007 09:46:43 +0000 Date: Thu, 06 Dec 2007 09:43:28 +0000 From: Adrian Farrel <adrian@olddog.co.uk> Subject: GELS: what happened alternatively what will happen To: Loa Andersson <loa@pi.se>, ccamp <ccamp@ops.ietf.org> Reply-to: Adrian Farrel <adrian@olddog.co.uk> Message-id: <02dd01c837ec$79172a70$bd148182@your029b8cecfe> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7bit 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" <loa@pi.se> To: "ccamp" <ccamp@ops.ietf.org> 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: loa.andersson@acreo.se > loa@pi.se > > This email was Anti Virus checked by Astaro Security Gateway. > http://www.astaro.com > > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 06 Dec 2007 03:08:33 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C837B5.27F0AC40" Subject: RE: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt Date: Thu, 6 Dec 2007 04:07:37 +0100 Message-ID: <53CCFDD6E346CB43994852666C210E9102624612@esealmw116.eemea.ericsson.se> Thread-Topic: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt Thread-Index: Acg3gDEwHgzwuP1RQpW2V7jAqvE8ogAKqyMg From: "Attila Takacs" <Attila.Takacs@ericsson.com> To: "Wataru Imajuku" <imajuku.wataru@lab.ntt.co.jp> Cc: <ccamp@ops.ietf.org> 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:imajuku.wataru@lab.ntt.co.jp] Sent: Wednesday, December 05, 2007 9:53 PM To: Attila Takacs Cc: ccamp@ops.ietf.org 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:danli@huawei.com] Sent: Wednesday, December 05, 2007 6:01 PM To: Diego Caviglia; neil.2.harrison@bt.com; Attila Takacs; tnadeau@lucidvision.com Cc: ccamp@ops.ietf.org 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:diego.caviglia@ericsson.com> To: neil.2.harrison@bt.com ; Attila Takacs <mailto:Attila.Takacs@ericsson.com> ; tnadeau@lucidvision.com Cc: ccamp@ops.ietf.org 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: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] Sent: marted$B!&(J4 dicembre 2007 22.55 To: Attila Takacs; tnadeau@lucidvision.com; Diego Caviglia Cc: ccamp@ops.ietf.org 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: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Attila Takacs Sent: 05 December 2007 02:03 To: Thomas Nadeau; Diego Caviglia Cc: ccamp@ops.ietf.org Subject: RE: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt Hi Tom, please see inline. Best regards, Attila ________________________________ From: Thomas Nadeau [mailto:tnadeau@lucidvision.com] Sent: Wednesday, December 05, 2007 2:19 AM To: Diego Caviglia Cc: Attila Takacs; ccamp@ops.ietf.org; balazs.gero@ericsson.com 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: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Thomas Nadeau Sent: marted$B!&(J4 dicembre 2007 11.30 To: Attila Takacs Cc: ccamp@ops.ietf.org; balazs.gero@ericsson.com 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:tnadeau@lucidvision.com] Sent: Tuesday, December 04, 2007 2:58 PM To: ccamp@ops.ietf.org Cc: Attila Takacs; balazs.gero@ericsson.com 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> </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> </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., 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. </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> </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 is needed, again to have 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> </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 accounts for flexibility.</FONT></SPAN></DIV> <DIV><SPAN class=434585301-06122007><FONT face=Arial color=#0000ff size=2></FONT></SPAN> </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> </DIV> <DIV><SPAN class=434585301-06122007><FONT face=Arial color=#0000ff size=2></FONT></SPAN> </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:imajuku.wataru@lab.ntt.co.jp] <BR><B>Sent:</B> Wednesday, December 05, 2007 9:53 PM<BR><B>To:</B> Attila Takacs<BR><B>Cc:</B> ccamp@ops.ietf.org<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> I understand this proposal automates manual configuration to set CFM interval in data plane.<BR> Control of CFM interval is new issue which GMPLS signaling mechanism has not covered.<BR> 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> On the other hand, I could not understand why do you need M bit in Admin Status Object.<BR> Why do not use A=1 ?<BR> 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"> <BR><FONT face=arial color=#0000ff size=2>Hi all,<BR></FONT> <BR><FONT face=arial color=#0000ff size=2>Neil's and Dan's summary are exact. Thanks for your comments!<BR></FONT> <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> <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:danli@huawei.com" eudora="autourl">mailto:danli@huawei.com</A>] <BR> <DD>Sent:</B> Wednesday, December 05, 2007 6:01 PM<BR> <DD>To:</B> Diego Caviglia; neil.2.harrison@bt.com; Attila Takacs; tnadeau@lucidvision.com<BR> <DD>Cc:</B> ccamp@ops.ietf.org<BR> <DD>Subject:</B> Re: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt<BR></FONT><BR> <DD>Hi,<BR> <DD><BR> <DD>I think there is a misunderstanding with respect to the objective of this draft. <BR> <DD><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><BR> <DD>Regards,<BR> <DD><BR> <DD>Dan<BR> <DD><BR> <DD><BR> <DD>----- Original Message ----- <BR> <DD>From:</B> <A href="mailto:diego.caviglia@ericsson.com">Diego Caviglia</A> <BR> <DD>To:</B> <A href="mailto:neil.2.harrison@bt.com">neil.2.harrison@bt.com</A> ; <A href="mailto:Attila.Takacs@ericsson.com">Attila Takacs</A> ; <A href="mailto:tnadeau@lucidvision.com">tnadeau@lucidvision.com</A> <BR> <DD>Cc:</B> <A href="mailto:ccamp@ops.ietf.org">ccamp@ops.ietf.org</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> Yes I totally agree with your analysis.<BR></FONT><BR> <DD><FONT face=arial color=#000080 size=2><BR></FONT><BR> <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> <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> <DD><FONT face=arial color=#000080 size=2>BR<BR></FONT><BR> <DD><FONT face=arial color=#000080 size=2><BR></FONT><BR> <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:neil.2.harrison@bt.com">neil.2.harrison@bt.com</A> [<A href="mailto:neil.2.harrison@bt.com" eudora="autourl">mailto:neil.2.harrison@bt.com</A>] <BR> <DD>Sent:</B> marted$B!&(B4 dicembre 2007 22.55<BR> <DD>To:</B> Attila Takacs; <A href="mailto:tnadeau@lucidvision.com">tnadeau@lucidvision.com</A>; Diego Caviglia<BR> <DD>Cc:</B> <A href="mailto:ccamp@ops.ietf.org">ccamp@ops.ietf.org</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> <DD><FONT face="comic sans ms" color=#800000 size=2>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.<BR></FONT><BR> <DD><FONT face="times new roman"><BR></FONT><BR> <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). 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.<BR></FONT><BR> <DD><FONT face="times new roman"><BR></FONT><BR> <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. 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.<BR></FONT><BR> <DD><FONT face="times new roman"><BR></FONT><BR> <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> owner-ccamp@ops.ietf.org [<A href="mailto:owner-ccamp@ops.ietf.org" eudora="autourl">mailto:owner-ccamp@ops.ietf.org</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> ccamp@ops.ietf.org<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:tnadeau@lucidvision.com" eudora="autourl">mailto:tnadeau@lucidvision.com</A>] <BR> <DD>Sent:</B> Wednesday, December 05, 2007 2:19 AM<BR> <DD>To:</B> Diego Caviglia<BR> <DD>Cc:</B> Attila Takacs; ccamp@ops.ietf.org; balazs.gero@ericsson.com<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> <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> 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> <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> </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? <BR></FONT><BR></DD></DL><FONT face="times new roman"> <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"> <BR></FONT><BR><FONT face="times new roman"> <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"> <BR></FONT><BR><FONT face="times new roman">No, I do not agree. 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"> <BR></FONT><BR><FONT face="times new roman"> <BR></FONT><BR><FONT face=arial color=#0000ff size=2>Sorry, I cannot follow.<BR></FONT><BR><FONT face="times new roman"> <BR></FONT><BR><FONT face="times new roman"> <BR></FONT> <DL><BR> <DD><FONT face="times new roman"><BR></FONT><BR> <DD><FONT face="times new roman"><BR></FONT><BR> <DD><FONT face="times new roman"><BR></FONT><BR> <DD><FONT face="times new roman">--Tom<BR></FONT><BR> <DD><FONT face="times new roman"><BR></FONT><BR> <DD><FONT face="times new roman"><BR></FONT><BR><FONT face="times new roman"><BR><BR></FONT> <DD><FONT face=arial color=#000080 size=2> </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:owner-ccamp@ops.ietf.org">owner-ccamp@ops.ietf.org</A> [<A href="mailto:owner-ccamp@ops.ietf.org">mailto:owner-ccamp@ops.ietf.org</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:ccamp@ops.ietf.org">ccamp@ops.ietf.org</A>; <A href="mailto:balazs.gero@ericsson.com">balazs.gero@ericsson.com</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:tnadeau@lucidvision.com">mailto:tnadeau@lucidvision.com</A>] <BR> <DD>Sent:</B> Tuesday, December 04, 2007 2:58 PM<BR> <DD>To:</B> <A href="mailto:ccamp@ops.ietf.org">ccamp@ops.ietf.org</A><BR> <DD>Cc:</B> Attila Takacs; <A href="mailto:balazs.gero@ericsson.com">balazs.gero@ericsson.com</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. 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"> </FONT>This solution specifically only works for GMPLS ethernet LSPs, right? <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? 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? 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, 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> [IEEE-CFM] aspects that are relevant for the connectivity monitoring<BR></FONT><BR> <DD><FONT face=helvetica size=1> of bidirectional point-to-point PBB-TE connections. <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) In section 2 you make the following statement:<BR></FONT><BR> <DD><FONT face=helvetica size=1>2. GMPLS RSVP-TE Extensions<BR></FONT><BR> <DD><FONT face=helvetica size=1> To simplify the configuration of connectivity monitoring, when an<BR></FONT><BR> <DD><FONT face=helvetica size=1> Ethernet LSP is signalled the associated MEPs should be automatically<BR></FONT><BR> <DD><FONT face=helvetica size=1> established. Further more, GMPLS signalling should be able to<BR></FONT><BR> <DD><FONT face=helvetica size=1> 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). 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"> </FONT>The point I am making is that perhaps it should.<BR><BR><FONT face="times new roman"> </FONT>--Tom<BR><BR><FONT face="times new roman"> <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-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 06 Dec 2007 02:31:09 +0000 Message-ID: <47575E4A.1040500@pi.se> Date: Thu, 06 Dec 2007 03:28:26 +0100 From: Loa Andersson <loa@pi.se> Organization: Acreo AB User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: ccamp <ccamp@ops.ietf.org> Subject: what happened alternatively what will happen Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: loa.andersson@acreo.se loa@pi.se This email was Anti Virus checked by Astaro Security Gateway. http://www.astaro.com Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 05 Dec 2007 22:14:07 +0000 Cc: Dan Li <danli@huawei.com>, Diego Caviglia <diego.caviglia@ericsson.com>, neil.2.harrison@bt.com, Attila Takacs <Attila.Takacs@ericsson.com>, ccamp@ops.ietf.org Message-Id: <74C2EEA4-898C-43A0-AB54-CAD9C53E59BE@lucidvision.com> From: Thomas Nadeau <tnadeau@lucidvision.com> To: Loa Andersson <loa@pi.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v915) 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: neil.2.harrison@bt.com ; Attila Takacs ; tnadeau@lucidvision.com >> Cc: ccamp@ops.ietf.org >> 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: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] >> Sent: marted=EC 4 dicembre 2007 22.55 >> To: Attila Takacs; tnadeau@lucidvision.com; Diego Caviglia >> Cc: ccamp@ops.ietf.org >> 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: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] =20= >> On Behalf Of Attila Takacs >> Sent: 05 December 2007 02:03 >> To: Thomas Nadeau; Diego Caviglia >> Cc: ccamp@ops.ietf.org >> Subject: RE: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt >> >> Hi Tom, >> >> please see inline. >> >> Best regards, >> >> Attila >> >> >> >> >> = --------------------------------------------------------------------------= >> >> From: Thomas Nadeau [mailto:tnadeau@lucidvision.com] >> Sent: Wednesday, December 05, 2007 2:19 AM >> To: Diego Caviglia >> Cc: Attila Takacs; ccamp@ops.ietf.org; balazs.gero@ericsson.com >> 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: owner-ccamp@ops.ietf.org [mailto:owner-=20 >> ccamp@ops.ietf.org] On Behalf Of Thomas Nadeau >> Sent: marted=EC 4 dicembre 2007 11.30 >> To: Attila Takacs >> Cc: ccamp@ops.ietf.org; balazs.gero@ericsson.com >> 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:tnadeau@lucidvision.com] >> Sent: Tuesday, December 04, 2007 2:58 PM >> To: ccamp@ops.ietf.org >> Cc: Attila Takacs; balazs.gero@ericsson.com >> 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: loa.andersson@acreo.se > loa@pi.se > > This email was Anti Virus checked by Astaro Security Gateway. = http://www.astaro.com > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 05 Dec 2007 21:29:24 +0000 Message-ID: <01fe01c83785$bf17df90$bd148182@your029b8cecfe> Reply-To: "Adrian Farrel" <adrian@olddog.co.uk> From: "Adrian Farrel" <adrian@olddog.co.uk> To: "Attila Takacs" <Attila.Takacs@ericsson.com>, "Wataru Imajuku" <imajuku.wataru@lab.ntt.co.jp> Cc: <ccamp@ops.ietf.org> Subject: Re: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt Date: Wed, 5 Dec 2007 21:28:09 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-2022-jp"; reply-type=original Content-Transfer-Encoding: 7bit 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 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 05 Dec 2007 20:49:31 +0000 Message-Id: <6.0.0.20.2.20071206053200.06f7d8b0@mailsv4.y.ecl.ntt.co.jp> Date: Thu, 06 Dec 2007 05:52:45 +0900 To: "Attila Takacs" <Attila.Takacs@ericsson.com> From: Wataru Imajuku <imajuku.wataru@lab.ntt.co.jp> Subject: RE: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt Cc: <ccamp@ops.ietf.org> Mime-Version: 1.0 Content-Type: text/html; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit <html> <body> Hi, Attila<br><br> I understand this proposal automates manual configuration to set CFM interval in data plane.<br> Control of CFM interval is new issue which GMPLS signaling mechanism has not covered.<br> 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> On the other hand, I could not understand why do you need M bit in Admin Status Object.<br> Why do not use A=1 ?<br> 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"> <br> <font face="arial" size=2 color="#0000FF">Hi all,<br> </font> <br> <font face="arial" size=2 color="#0000FF">Neil's and Dan's summary are exact. Thanks for your comments!<br> </font> <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: "GMPLS RSVP-TE Extensions to *Control* Ethernet OAM".<br> Nevertheless, when updating the ID we will clarify our point even more.<br> </font> <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:danli@huawei.com" eudora="autourl">mailto:danli@huawei.com</a>] <br> <dd>Sent:</b> Wednesday, December 05, 2007 6:01 PM<br> <dd>To:</b> Diego Caviglia; neil.2.harrison@bt.com; Attila Takacs; tnadeau@lucidvision.com<br> <dd>Cc:</b> ccamp@ops.ietf.org<br> <dd>Subject:</b> Re: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt<br> </font><br> <dd>Hi,<br> <dd> <br> <dd>I think there is a misunderstanding with respect to the objective of this draft. <br> <dd> <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> <br> <dd>Regards,<br> <dd> <br> <dd>Dan<br> <dd> <br> <dd> <br> <dd>----- Original Message ----- <br> <dd>From:</b> <a href="mailto:diego.caviglia@ericsson.com">Diego Caviglia</a> <br> <dd>To:</b> <a href="mailto:neil.2.harrison@bt.com">neil.2.harrison@bt.com</a> ; <a href="mailto:Attila.Takacs@ericsson.com">Attila Takacs</a> ; <a href="mailto:tnadeau@lucidvision.com">tnadeau@lucidvision.com</a> <br> <dd>Cc:</b> <a href="mailto:ccamp@ops.ietf.org">ccamp@ops.ietf.org</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"> Yes I totally agree with your analysis.<br> </font><br> <dd><font face="arial" size=2 color="#000080"> <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"> <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"> <br> </font><br> <dd><font face="arial" size=2 color="#000080">BR<br> </font><br> <dd><font face="arial" size=2 color="#000080"> <br> </font><br> <dd><font face="arial" size=2 color="#000080">Diego<br> </font><br> <dd><font face="arial" size=2 color="#000080"> <br> <hr> <div align="center"></font></div> <dd><font face="tahoma" size=2>From:</b> <a href="mailto:neil.2.harrison@bt.com">neil.2.harrison@bt.com</a> [<a href="mailto:neil.2.harrison@bt.com" eudora="autourl">mailto:neil.2.harrison@bt.com</a>] <br> <dd>Sent:</b> marted$Bw(B4 dicembre 2007 22.55<br> <dd>To:</b> Attila Takacs; <a href="mailto:tnadeau@lucidvision.com">tnadeau@lucidvision.com</a>; Diego Caviglia<br> <dd>Cc:</b> <a href="mailto:ccamp@ops.ietf.org">ccamp@ops.ietf.org</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> <dd><font face="comic sans ms" size=2 color="#800000">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.<br> </font><br> <dd><font face="times new roman"> <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). 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.<br> </font><br> <dd><font face="times new roman"> <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. 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.<br> </font><br> <dd><font face="times new roman"> <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> owner-ccamp@ops.ietf.org [<a href="mailto:owner-ccamp@ops.ietf.org" eudora="autourl">mailto:owner-ccamp@ops.ietf.org</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> ccamp@ops.ietf.org<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"> <br> <hr> <div align="center"></font></div> <dd><font face="tahoma" size=2>From:</b> Thomas Nadeau [<a href="mailto:tnadeau@lucidvision.com" eudora="autourl">mailto:tnadeau@lucidvision.com</a>] <br> <dd>Sent:</b> Wednesday, December 05, 2007 2:19 AM<br> <dd>To:</b> Diego Caviglia<br> <dd>Cc:</b> Attila Takacs; ccamp@ops.ietf.org; balazs.gero@ericsson.com<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> <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"> 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"> <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"> <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? <br> </font><br> </dl><font face="times new roman"> <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 "as transport"? GMPLS is just controlling OAM, CFM is run solely in the data plane.<br> </font><br> <font face="times new roman"> <br> </font><br> <font face="times new roman"> <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"> <br> </font><br> <font face="times new roman">No, I do not agree. 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"> <br> </font><br> <font face="times new roman"> <br> </font><br> <font face="arial" size=2 color="#0000FF">Sorry, I cannot follow.<br> </font><br> <font face="times new roman"> <br> </font><br> <font face="times new roman"> <br> </font> <dl><br> <dd><font face="times new roman"> <br> </font><br> <dd><font face="times new roman"> <br> </font><br> <dd><font face="times new roman"> <br> </font><br> <dd><font face="times new roman">--Tom<br> </font><br> <dd><font face="times new roman"> <br> </font><br> <dd><font face="times new roman"> <br> </font><br> <font face="times new roman"><br><br> </font> <dd><font face="arial" size=2 color="#000080"> </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:owner-ccamp@ops.ietf.org">owner-ccamp@ops.ietf.org</a> [<a href="mailto:owner-ccamp@ops.ietf.org">mailto:owner-ccamp@ops.ietf.org</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:ccamp@ops.ietf.org">ccamp@ops.ietf.org</a>; <a href="mailto:balazs.gero@ericsson.com">balazs.gero@ericsson.com</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:tnadeau@lucidvision.com">mailto:tnadeau@lucidvision.com</a>] <br> <dd>Sent:</b> Tuesday, December 04, 2007 2:58 PM<br> <dd>To:</b> <a href="mailto:ccamp@ops.ietf.org">ccamp@ops.ietf.org</a><br> <dd>Cc:</b> Attila Takacs; <a href="mailto:balazs.gero@ericsson.com">balazs.gero@ericsson.com</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. 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"> </font> This solution specifically only works for GMPLS ethernet LSPs, right? <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? 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? 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, 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> [IEEE-CFM] aspects that are relevant for the connectivity monitoring<br> </font><br> <dd><font face="helvetica" size=1> of bidirectional point-to-point PBB-TE connections. <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) In section 2 you make the following statement:<br> </font><br> <dd><font face="helvetica" size=1>2. GMPLS RSVP-TE Extensions<br> </font><br> <dd><font face="helvetica" size=1> To simplify the configuration of connectivity monitoring, when an<br> </font><br> <dd><font face="helvetica" size=1> Ethernet LSP is signalled the associated MEPs should be automatically<br> </font><br> <dd><font face="helvetica" size=1> established. Further more, GMPLS signalling should be able to<br> </font><br> <dd><font face="helvetica" size=1> 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). 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"> </font> The point I am making is that perhaps it should.<br><br> <font face="times new roman"> </font> --Tom<br><br> <font face="times new roman"> <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> Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 05 Dec 2007 20:39:03 +0000 Message-ID: <47570BE6.1020007@pi.se> Date: Wed, 05 Dec 2007 21:36:54 +0100 From: Loa Andersson <loa@pi.se> Organization: Acreo AB User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Dan Li <danli@huawei.com> CC: Diego Caviglia <diego.caviglia@ericsson.com>, neil.2.harrison@bt.com, Attila Takacs <Attila.Takacs@ericsson.com>, tnadeau@lucidvision.com, ccamp@ops.ietf.org Subject: Re: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit 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: neil.2.harrison@bt.com ; Attila Takacs ; tnadeau@lucidvision.com > Cc: ccamp@ops.ietf.org > 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: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] > Sent: martedì 4 dicembre 2007 22.55 > To: Attila Takacs; tnadeau@lucidvision.com; Diego Caviglia > Cc: ccamp@ops.ietf.org > 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: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Attila Takacs > Sent: 05 December 2007 02:03 > To: Thomas Nadeau; Diego Caviglia > Cc: ccamp@ops.ietf.org > Subject: RE: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt > > Hi Tom, > > please see inline. > > Best regards, > > Attila > > > > > -------------------------------------------------------------------------- > > From: Thomas Nadeau [mailto:tnadeau@lucidvision.com] > Sent: Wednesday, December 05, 2007 2:19 AM > To: Diego Caviglia > Cc: Attila Takacs; ccamp@ops.ietf.org; balazs.gero@ericsson.com > 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: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Thomas Nadeau > Sent: martedì 4 dicembre 2007 11.30 > To: Attila Takacs > Cc: ccamp@ops.ietf.org; balazs.gero@ericsson.com > 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:tnadeau@lucidvision.com] > Sent: Tuesday, December 04, 2007 2:58 PM > To: ccamp@ops.ietf.org > Cc: Attila Takacs; balazs.gero@ericsson.com > 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: loa.andersson@acreo.se loa@pi.se This email was Anti Virus checked by Astaro Security Gateway. http://www.astaro.com Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 05 Dec 2007 19:39:48 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C83776.3E1B4EEC" Subject: RE: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt Date: Wed, 5 Dec 2007 20:37:16 +0100 Message-ID: <53CCFDD6E346CB43994852666C210E910262460F@esealmw116.eemea.ericsson.se> Thread-Topic: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt Thread-Index: Acg3YGbnOB7kck6nQPSKbkKvf3bh5wADu/Jw From: "Attila Takacs" <Attila.Takacs@ericsson.com> To: "Dan Li" <danli@huawei.com>, "Diego Caviglia" <diego.caviglia@ericsson.com>, <neil.2.harrison@bt.com>, <tnadeau@lucidvision.com> Cc: <ccamp@ops.ietf.org> 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:danli@huawei.com]=20 Sent: Wednesday, December 05, 2007 6:01 PM To: Diego Caviglia; neil.2.harrison@bt.com; Attila Takacs; = tnadeau@lucidvision.com Cc: ccamp@ops.ietf.org 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:diego.caviglia@ericsson.com> =20 To: neil.2.harrison@bt.com ; Attila Takacs = <mailto:Attila.Takacs@ericsson.com> ; tnadeau@lucidvision.com=20 Cc: ccamp@ops.ietf.org=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: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]=20 Sent: marted=EC 4 dicembre 2007 22.55 To: Attila Takacs; tnadeau@lucidvision.com; Diego Caviglia Cc: ccamp@ops.ietf.org 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: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On = Behalf Of Attila Takacs Sent: 05 December 2007 02:03 To: Thomas Nadeau; Diego Caviglia Cc: ccamp@ops.ietf.org 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:tnadeau@lucidvision.com]=20 Sent: Wednesday, December 05, 2007 2:19 AM To: Diego Caviglia Cc: Attila Takacs; ccamp@ops.ietf.org; balazs.gero@ericsson.com 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: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On = Behalf Of Thomas Nadeau Sent: marted=EC 4 dicembre 2007 11.30 To: Attila Takacs Cc: ccamp@ops.ietf.org; balazs.gero@ericsson.com 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:tnadeau@lucidvision.com]=20 Sent: Tuesday, December 04, 2007 2:58 PM To: ccamp@ops.ietf.org Cc: Attila Takacs; balazs.gero@ericsson.com 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> </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> </DIV> <DIV><FONT face=3DArial><FONT color=3D#0000ff><FONT size=3D2><SPAN=20 class=3D546514718-05122007>Maybe the title of the ID caused the=20 misunderstanding, it would say more if it would read: "</SPAN>GMPLS = RSVP-TE=20 Extensions to <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 clarify 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> </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:danli@huawei.com]=20 <BR><B>Sent:</B> Wednesday, December 05, 2007 6:01 PM<BR><B>To:</B> = Diego=20 Caviglia; neil.2.harrison@bt.com; Attila Takacs;=20 tnadeau@lucidvision.com<BR><B>Cc:</B> = ccamp@ops.ietf.org<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> </DIV> <DIV>I think there is a misunderstanding with respect to the = objective of=20 this draft. </DIV> <DIV> </DIV> <DIV>As I read this draft, it describes how to extend = the RSVP=20 protocol to support the configuration/enable the OAM function of = Ethernet=20 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.</DIV> <DIV> </DIV> <DIV>Regards,</DIV> <DIV> </DIV> <DIV>Dan</DIV> <DIV> </DIV> <DIV> </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=3Ddiego.caviglia@ericsson.com=20 href=3D"mailto:diego.caviglia@ericsson.com">Diego Caviglia</A> = </DIV> <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A = title=3Dneil.2.harrison@bt.com=20 href=3D"mailto:neil.2.harrison@bt.com">neil.2.harrison@bt.com</A> ; = <A=20 title=3DAttila.Takacs@ericsson.com=20 href=3D"mailto:Attila.Takacs@ericsson.com">Attila Takacs</A> ; <A=20 title=3Dtnadeau@lucidvision.com=20 href=3D"mailto:tnadeau@lucidvision.com">tnadeau@lucidvision.com</A> = </DIV> <DIV style=3D"FONT: 10pt arial"><B>Cc:</B> <A = title=3Dccamp@ops.ietf.org=20 href=3D"mailto:ccamp@ops.ietf.org">ccamp@ops.ietf.org</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"> =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> </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> </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> </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> </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> </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:neil.2.harrison@bt.com">neil.2.harrison@bt.com</A>=20 [mailto:neil.2.harrison@bt.com] <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:tnadeau@lucidvision.com">tnadeau@lucidvision.com</A>; = Diego=20 Caviglia<BR><B><SPAN style=3D"FONT-WEIGHT: bold">Cc:</SPAN></B> <A=20 = href=3D"mailto:ccamp@ops.ietf.org">ccamp@ops.ietf.org</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> </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. I read the draft and thought it was excellent. = 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. If we don't ensure this then there will be obvious = operational problems. 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"> <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 OOB 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). 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 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. 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"> <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. When we partition a time resource in = irregular=20 time-slices we create a co-ps mode layer network. 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"> <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 owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] = <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 ccamp@ops.ietf.org<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> </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:tnadeau@lucidvision.com] <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>; = ccamp@ops.ietf.org;=20 balazs.gero@ericsson.com<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> </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"> = =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> </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"> <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. </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 a control plane to setup = the data=20 plane. In this case we propose to use 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? </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> </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. <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"> <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> </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> </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. 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"> <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></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"> <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></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"> <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></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> </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> </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> </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"> <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"> </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:owner-ccamp@ops.ietf.org">owner-ccamp@ops.ietf.org</A> = [<A=20 = href=3D"mailto:owner-ccamp@ops.ietf.org">mailto:owner-ccamp@ops.ietf.org<= /A>]<SPAN=20 class=3Dapple-converted-space> </SPAN><B><SPAN=20 style=3D"FONT-WEIGHT: bold">On Behalf Of<SPAN=20 class=3Dapple-converted-space> </SPAN></SPAN></B>Thomas=20 Nadeau<BR><B><SPAN style=3D"FONT-WEIGHT: = bold">Sent:</SPAN></B><SPAN=20 class=3Dapple-converted-space> </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> </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> </SPAN><A=20 href=3D"mailto:ccamp@ops.ietf.org">ccamp@ops.ietf.org</A>;<SPAN=20 class=3Dapple-converted-space> </SPAN><A=20 = href=3D"mailto:balazs.gero@ericsson.com">balazs.gero@ericsson.com</A><BR>= <B><SPAN=20 style=3D"FONT-WEIGHT: bold">Subject:</SPAN></B><SPAN=20 class=3Dapple-converted-space> </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 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"> </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:tnadeau@lucidvision.com">mailto:tnadeau@lucidvision.com</A= >]<SPAN=20 class=3Dapple-converted-space> </SPAN><BR><B><SPAN=20 style=3D"FONT-WEIGHT: bold">Sent:</SPAN></B><SPAN=20 class=3Dapple-converted-space> </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> </SPAN><A=20 = href=3D"mailto:ccamp@ops.ietf.org">ccamp@ops.ietf.org</A><BR><B><SPAN=20 style=3D"FONT-WEIGHT: bold">Cc:</SPAN></B><SPAN=20 class=3Dapple-converted-space> </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> </SPAN><A=20 = href=3D"mailto:balazs.gero@ericsson.com">balazs.gero@ericsson.com</A><BR>= <B><SPAN=20 style=3D"FONT-WEIGHT: bold">Subject:</SPAN></B><SPAN=20 = class=3Dapple-converted-space> </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, I am concerned that the definition of a new TLV = and=20 these procedures=20 = represent <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. 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 <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. </SPAN></FONT><FONT face=3DArial = color=3Dblue=20 size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: = Arial"> </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 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. That is, to = establish CFM=20 entities for GMPLS controlled Ethernet LSPs. 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"> </SPAN></FON= T></SPAN><SPAN=20 class=3Dapple-converted-space><FONT color=3Dblack><SPAN=20 style=3D"COLOR: black"> </SPAN></FONT></SPAN><FONT = color=3Dblack><SPAN=20 style=3D"COLOR: black">This solution specifically only works for = GMPLS=20 ethernet LSPs, right?=20 <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) 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? 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? 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. <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) 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 truly 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 not just a single hop above a transport=20 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=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 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"> =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"> =20 of bidirectional point-to-point PBB-TE connections.=20 <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 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. =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> <SPAN=20 class=3Dapple-converted-space> </SPAN> 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"> =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"> <SPAN=20 class=3Dapple-converted-space> </SPAN> = established. =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"> 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). 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 </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 to your point #1. There is no relation to the=20 gmpls-LSP-ping draft. </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"> </SPAN></FON= T></SPAN><SPAN=20 class=3Dapple-converted-space><FONT color=3Dblack><SPAN=20 style=3D"COLOR: black"> </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"> </SPAN></FON= T></SPAN><SPAN=20 class=3Dapple-converted-space><FONT color=3Dblack><SPAN=20 style=3D"COLOR: black"> </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> </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-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 05 Dec 2007 17:01:36 +0000 Date: Thu, 06 Dec 2007 01:00:41 +0800 From: Dan Li <danli@huawei.com> Subject: Re: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt To: Diego Caviglia <diego.caviglia@ericsson.com>, neil.2.harrison@bt.com, Attila Takacs <Attila.Takacs@ericsson.com>, tnadeau@lucidvision.com Cc: ccamp@ops.ietf.org Message-id: <002c01c83760$5edf74f0$42418182@dan> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_ri+RKGJ58xhymCKK5aRKfw)" 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: neil.2.harrison@bt.com ; Attila Takacs ; tnadeau@lucidvision.com=20 Cc: ccamp@ops.ietf.org=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: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]=20 Sent: marted=EC 4 dicembre 2007 22.55 To: Attila Takacs; tnadeau@lucidvision.com; Diego Caviglia Cc: ccamp@ops.ietf.org 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: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On = Behalf Of Attila Takacs Sent: 05 December 2007 02:03 To: Thomas Nadeau; Diego Caviglia Cc: ccamp@ops.ietf.org 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:tnadeau@lucidvision.com]=20 Sent: Wednesday, December 05, 2007 2:19 AM To: Diego Caviglia Cc: Attila Takacs; ccamp@ops.ietf.org; balazs.gero@ericsson.com 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: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] = On Behalf Of Thomas Nadeau Sent: marted=EC 4 dicembre 2007 11.30 To: Attila Takacs Cc: ccamp@ops.ietf.org; balazs.gero@ericsson.com 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:tnadeau@lucidvision.com]=20 Sent: Tuesday, December 04, 2007 2:58 PM To: ccamp@ops.ietf.org Cc: Attila Takacs; balazs.gero@ericsson.com 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> </DIV> <DIV>I think there is a misunderstanding with respect to the = objective of=20 this draft. </DIV> <DIV> </DIV> <DIV>As I read this draft, it describes how to extend the RSVP = protocol to support the configuration/enable the OAM function of = Ethernet=20 LSP, 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 to clarify = the=20 objective at the beginning of this draft.</DIV> <DIV> </DIV> <DIV>Regards,</DIV> <DIV> </DIV> <DIV>Dan</DIV> <DIV> </DIV> <DIV> </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=3Ddiego.caviglia@ericsson.com=20 href=3D"mailto:diego.caviglia@ericsson.com">Diego Caviglia</A> </DIV> <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A = title=3Dneil.2.harrison@bt.com=20 href=3D"mailto:neil.2.harrison@bt.com">neil.2.harrison@bt.com</A> ; <A = title=3DAttila.Takacs@ericsson.com=20 href=3D"mailto:Attila.Takacs@ericsson.com">Attila Takacs</A> ; <A=20 title=3Dtnadeau@lucidvision.com=20 href=3D"mailto:tnadeau@lucidvision.com">tnadeau@lucidvision.com</A> = </DIV> <DIV style=3D"FONT: 10pt arial"><B>Cc:</B> <A = title=3Dccamp@ops.ietf.org=20 href=3D"mailto:ccamp@ops.ietf.org">ccamp@ops.ietf.org</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"> =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> </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> </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> </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> </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> </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:neil.2.harrison@bt.com">neil.2.harrison@bt.com</A>=20 [mailto:neil.2.harrison@bt.com] <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:tnadeau@lucidvision.com">tnadeau@lucidvision.com</A>; = Diego=20 Caviglia<BR><B><SPAN style=3D"FONT-WEIGHT: bold">Cc:</SPAN></B> <A=20 href=3D"mailto:ccamp@ops.ietf.org">ccamp@ops.ietf.org</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> </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. I read the draft and thought it was excellent. 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. If we don't ensure this then there will be obvious=20 operational problems. 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"> <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 OOB 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). 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 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. 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"> <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. When we partition a time resource in = irregular=20 time-slices we create a co-ps mode layer network. 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"> <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 owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] <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 ccamp@ops.ietf.org<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> </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:tnadeau@lucidvision.com] <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 ccamp@ops.ietf.org; balazs.gero@ericsson.com<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> </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"> = =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> </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"> <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. </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 a control plane to setup the = data plane.=20 In this case we propose to use 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? </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> </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. <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"> <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> </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> </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. 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"> <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></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"> <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></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"> <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></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> </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> </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> </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"> <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"> </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:owner-ccamp@ops.ietf.org">owner-ccamp@ops.ietf.org</A> = [<A=20 = href=3D"mailto:owner-ccamp@ops.ietf.org">mailto:owner-ccamp@ops.ietf.org<= /A>]<SPAN=20 class=3Dapple-converted-space> </SPAN><B><SPAN=20 style=3D"FONT-WEIGHT: bold">On Behalf Of<SPAN=20 class=3Dapple-converted-space> </SPAN></SPAN></B>Thomas=20 Nadeau<BR><B><SPAN style=3D"FONT-WEIGHT: = bold">Sent:</SPAN></B><SPAN=20 class=3Dapple-converted-space> </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> </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> </SPAN><A=20 href=3D"mailto:ccamp@ops.ietf.org">ccamp@ops.ietf.org</A>;<SPAN=20 class=3Dapple-converted-space> </SPAN><A=20 = href=3D"mailto:balazs.gero@ericsson.com">balazs.gero@ericsson.com</A><BR>= <B><SPAN=20 style=3D"FONT-WEIGHT: bold">Subject:</SPAN></B><SPAN=20 class=3Dapple-converted-space> </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 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"> </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:tnadeau@lucidvision.com">mailto:tnadeau@lucidvision.com</A= >]<SPAN=20 class=3Dapple-converted-space> </SPAN><BR><B><SPAN=20 style=3D"FONT-WEIGHT: bold">Sent:</SPAN></B><SPAN=20 class=3Dapple-converted-space> </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> </SPAN><A=20 = href=3D"mailto:ccamp@ops.ietf.org">ccamp@ops.ietf.org</A><BR><B><SPAN=20 style=3D"FONT-WEIGHT: bold">Cc:</SPAN></B><SPAN=20 class=3Dapple-converted-space> </SPAN><st1:PersonName=20 w:st=3D"on">Attila Takacs</st1:PersonName>;<SPAN=20 class=3Dapple-converted-space> </SPAN><A=20 = href=3D"mailto:balazs.gero@ericsson.com">balazs.gero@ericsson.com</A><BR>= <B><SPAN=20 style=3D"FONT-WEIGHT: bold">Subject:</SPAN></B><SPAN=20 = class=3Dapple-converted-space> </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, I am=20 concerned that the definition of a new TLV and these procedures=20 = represent <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. 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 <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. </SPAN></FONT><FONT=20 face=3DArial color=3Dblue size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: = Arial"> </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 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. That is, to establish = CFM=20 entities for GMPLS controlled Ethernet LSPs. 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"> </SPAN></FON= T></SPAN><SPAN=20 class=3Dapple-converted-space><FONT color=3Dblack><SPAN=20 style=3D"COLOR: black"> </SPAN></FONT></SPAN><FONT = color=3Dblack><SPAN=20 style=3D"COLOR: black">This solution specifically only works for = GMPLS=20 ethernet LSPs, right?=20 <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) 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 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? 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. <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) 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 truly 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 not just a single hop above a transport = LSP. In this=20 case Ethernet layer (for clarity GELS) may provide = protection for=20 Ethernet LSPs. In any case, 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 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"> =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"> =20 of bidirectional point-to-point PBB-TE connections.=20 <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 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. =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> <SPAN=20 class=3Dapple-converted-space> </SPAN> 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"> =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"> <SPAN=20 class=3Dapple-converted-space> </SPAN> = established. =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"> 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). 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 </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 to your point #1. There is no relation to the=20 gmpls-LSP-ping draft. </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"> </SPAN></FON= T></SPAN><SPAN=20 class=3Dapple-converted-space><FONT color=3Dblack><SPAN=20 style=3D"COLOR: black"> </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"> </SPAN></FON= T></SPAN><SPAN=20 class=3Dapple-converted-space><FONT color=3Dblack><SPAN=20 style=3D"COLOR: black"> </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> </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)-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 05 Dec 2007 16:53:44 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8375F.41AC3A97" Subject: RE: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt Date: Wed, 5 Dec 2007 17:52:41 +0100 Message-ID: <0428AC48A879ED46A94F39D5665DF684DF2FC0@esealmw110.eemea.ericsson.se> Thread-Topic: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt Thread-Index: Acg23NTgoIFKofLLTTqsgyKk8dFwjQAgfBwg From: "Diego Caviglia" <diego.caviglia@ericsson.com> To: "Thomas Nadeau" <tnadeau@lucidvision.com> Cc: "Attila Takacs" <Attila.Takacs@ericsson.com>, <ccamp@ops.ietf.org>, <balazs.gero@ericsson.com> 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:tnadeau@lucidvision.com]=20 Sent: marted=EC 4 dicembre 2007 17.19 To: Diego Caviglia Cc: Attila Takacs; ccamp@ops.ietf.org; balazs.gero@ericsson.com 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: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On = Behalf Of Thomas Nadeau Sent: marted=EC 4 dicembre 2007 11.30 To: Attila Takacs Cc: ccamp@ops.ietf.org; balazs.gero@ericsson.com 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:tnadeau@lucidvision.com]=20 Sent: Tuesday, December 04, 2007 2:58 PM To: ccamp@ops.ietf.org Cc: Attila Takacs; balazs.gero@ericsson.com 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> </o:p></span></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> </o:p></span></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> </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:tnadeau@lucidvision.com] <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>; ccamp@ops.ietf.org; = balazs.gero@ericsson.com<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> </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> </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'> = 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.</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> </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’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’re not happy with the fact the ID is so = technology specific am I right? </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> </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. <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 ‘session’ 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> </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. 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> </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> </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> </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'> <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> </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'> </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:owner-ccamp@ops.ietf.org">owner-ccamp@ops.ietf.org</a> [<a = href=3D"mailto:owner-ccamp@ops.ietf.org">mailto:owner-ccamp@ops.ietf.org<= /a>]<span class=3Dapple-converted-space> </span><b><span = style=3D'font-weight:bold'>On Behalf Of<span = class=3Dapple-converted-space> </span></span></b>Thomas Nadeau<br> <b><span style=3D'font-weight:bold'>Sent:</span></b><span class=3Dapple-converted-space> </span>marted=EC 4 dicembre 2007 = 11.30<br> <b><span style=3D'font-weight:bold'>To:</span></b><span class=3Dapple-converted-space> </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> </span><a = href=3D"mailto:ccamp@ops.ietf.org">ccamp@ops.ietf.org</a>;<span class=3Dapple-converted-space> </span><a href=3D"mailto:balazs.gero@ericsson.com">balazs.gero@ericsson.com</a><br>= <b><span style=3D'font-weight:bold'>Subject:</span></b><span class=3Dapple-converted-space> </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> </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> </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'> <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 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'> <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> </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'> </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:tnadeau@lucidvision.com">mailto:tnadeau@lucidvision.com</a= >]<span class=3Dapple-converted-space> </span><br> <b><span style=3D'font-weight:bold'>Sent:</span></b><span class=3Dapple-converted-space> </span>Tuesday, December 04, 2007 = 2:58 PM<br> <b><span style=3D'font-weight:bold'>To:</span></b><span class=3Dapple-converted-space> </span><a = href=3D"mailto:ccamp@ops.ietf.org">ccamp@ops.ietf.org</a><br> <b><span style=3D'font-weight:bold'>Cc:</span></b><span class=3Dapple-converted-space> </span><st1:PersonName = w:st=3D"on">Attila Takacs</st1:PersonName>;<span = class=3Dapple-converted-space> </span><a href=3D"mailto:balazs.gero@ericsson.com">balazs.gero@ericsson.com</a><br>= <b><span style=3D'font-weight:bold'>Subject:</span></b><span class=3Dapple-converted-space> </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> </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> </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> </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, I am concerned = that the definition of a new TLV and these procedures = represent <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. 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 <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. </span></font><font size=3D2 color=3Dblue face=3DArial><span = style=3D'font-size:10.0pt;font-family:Arial; color:blue'> </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 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.</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> </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'> &nbs= p; </span></font></span><span class=3Dapple-converted-space><font color=3Dblack><span = style=3D'color:black'> </span></font></span><font color=3Dblack><span style=3D'color:black'>This solution specifically = only works for GMPLS ethernet LSPs, right? <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) 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? 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? 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. <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) 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 truly 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 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.</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> </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 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'> <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> </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'> = [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'> = of bidirectional point-to-point PBB-TE connections. = <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> <= /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'> <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> <= /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) 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> <= /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. = 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'> </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'> <span class=3Dapple-converted-space> </span> 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'> = 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'> <span class=3Dapple-converted-space> </span> established. = 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'> 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> <= /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> <= /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). 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 </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 to your point #1. = There is no relation to the gmpls-LSP-ping = draft. </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> </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'> &nbs= p; </span></font></span><span class=3Dapple-converted-space><font color=3Dblack><span = style=3D'color:black'> </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> </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'> &nbs= p; </span></font></span><span class=3Dapple-converted-space><font color=3Dblack><span = style=3D'color:black'> </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> </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> </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'> </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><= /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><= /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> </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> </o:p></span></font></p> </div> </div> </body> </html> ------_=_NextPart_001_01C8375F.41AC3A97-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 05 Dec 2007 16:30:23 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8375B.C5166677" Subject: RE: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt Date: Wed, 5 Dec 2007 17:27:44 +0100 Message-ID: <0428AC48A879ED46A94F39D5665DF684DF2F9A@esealmw110.eemea.ericsson.se> Thread-Topic: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt Thread-Index: Acg23NTxGvHAwYB1RMusTe1rH8zc1AABNqKAAAj7JuAAFW/IEA== From: "Diego Caviglia" <diego.caviglia@ericsson.com> To: <neil.2.harrison@bt.com>, "Attila Takacs" <Attila.Takacs@ericsson.com>, <tnadeau@lucidvision.com> Cc: <ccamp@ops.ietf.org> 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: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]=20 Sent: marted=EC 4 dicembre 2007 22.55 To: Attila Takacs; tnadeau@lucidvision.com; Diego Caviglia Cc: ccamp@ops.ietf.org 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: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On = Behalf Of Attila Takacs Sent: 05 December 2007 02:03 To: Thomas Nadeau; Diego Caviglia Cc: ccamp@ops.ietf.org 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:tnadeau@lucidvision.com]=20 Sent: Wednesday, December 05, 2007 2:19 AM To: Diego Caviglia Cc: Attila Takacs; ccamp@ops.ietf.org; balazs.gero@ericsson.com 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: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On = Behalf Of Thomas Nadeau Sent: marted=EC 4 dicembre 2007 11.30 To: Attila Takacs Cc: ccamp@ops.ietf.org; balazs.gero@ericsson.com 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:tnadeau@lucidvision.com]=20 Sent: Tuesday, December 04, 2007 2:58 PM To: ccamp@ops.ietf.org Cc: Attila Takacs; balazs.gero@ericsson.com 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> </o:p></span></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> </o:p></span></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’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> </o:p></span></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> </o:p></span></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> </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'> neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] <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>; tnadeau@lucidvision.com; Diego Caviglia<br> <b><span style=3D'font-weight:bold'>Cc:</span></b> = ccamp@ops.ietf.org<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> </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. 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.</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></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 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.</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></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. 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.</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></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> = owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] <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> = ccamp@ops.ietf.org<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> </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:tnadeau@lucidvision.com] <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>; ccamp@ops.ietf.org; = balazs.gero@ericsson.com<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> </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'> = 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.</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> </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'> <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. </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 a control plane to setup the data plane. In this case we = propose to use 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’re not happy with the fact the ID is so = technology specific am I right? </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> </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. <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 "as transport"? 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'> <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> </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 ‘session’ 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> </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. 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'> <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></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'> <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></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'> <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></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> </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> </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> </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'> <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'> </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:owner-ccamp@ops.ietf.org">owner-ccamp@ops.ietf.org</a> [<a = href=3D"mailto:owner-ccamp@ops.ietf.org">mailto:owner-ccamp@ops.ietf.org<= /a>]<span class=3Dapple-converted-space> </span><b><span = style=3D'font-weight:bold'>On Behalf Of<span = class=3Dapple-converted-space> </span></span></b>Thomas Nadeau<br> <b><span style=3D'font-weight:bold'>Sent:</span></b><span class=3Dapple-converted-space> </span>marted=EC 4 dicembre 2007 = 11.30<br> <b><span style=3D'font-weight:bold'>To:</span></b><span class=3Dapple-converted-space> </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> </span><a = href=3D"mailto:ccamp@ops.ietf.org">ccamp@ops.ietf.org</a>;<span class=3Dapple-converted-space> </span><a href=3D"mailto:balazs.gero@ericsson.com">balazs.gero@ericsson.com</a><br>= <b><span style=3D'font-weight:bold'>Subject:</span></b><span class=3Dapple-converted-space> </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 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'> </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:tnadeau@lucidvision.com">mailto:tnadeau@lucidvision.com</a= >]<span class=3Dapple-converted-space> </span><br> <b><span style=3D'font-weight:bold'>Sent:</span></b><span class=3Dapple-converted-space> </span>Tuesday, December 04, 2007 = 2:58 PM<br> <b><span style=3D'font-weight:bold'>To:</span></b><span class=3Dapple-converted-space> </span><a = href=3D"mailto:ccamp@ops.ietf.org">ccamp@ops.ietf.org</a><br> <b><span style=3D'font-weight:bold'>Cc:</span></b><span class=3Dapple-converted-space> </span><st1:PersonName = w:st=3D"on">Attila Takacs</st1:PersonName>;<span = class=3Dapple-converted-space> </span><a href=3D"mailto:balazs.gero@ericsson.com">balazs.gero@ericsson.com</a><br>= <b><span style=3D'font-weight:bold'>Subject:</span></b><span class=3Dapple-converted-space> </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, I am = concerned that the definition of a new TLV and these procedures = represent <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. 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 <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. </span></font><font size=3D2 color=3Dblue face=3DArial><span = style=3D'font-size:10.0pt;font-family:Arial; color:blue'> </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 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.</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'> &nbs= p; </span></font></span><span class=3Dapple-converted-space><font color=3Dblack><span = style=3D'color:black'> </span></font></span><font color=3Dblack><span style=3D'color:black'>This solution specifically = only works for GMPLS ethernet LSPs, right? <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) 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? 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? 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. <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) 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 truly 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 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.</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 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'> [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'> = of bidirectional point-to-point PBB-TE connections. = <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) 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.= 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> </span> 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'> = 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'> <span class=3Dapple-converted-space> </span> established. = 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'> 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). 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 </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 to your point #1. = There is no relation to the gmpls-LSP-ping = draft. </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'> &nbs= p; </span></font></span><span class=3Dapple-converted-space><font color=3Dblack><span = style=3D'color:black'> </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'> &nbs= p; </span></font></span><span class=3Dapple-converted-space><font color=3Dblack><span = style=3D'color:black'> </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> </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-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 05 Dec 2007 13:12:11 +0000 Cc: <ccamp@ops.ietf.org>, "Otani Tomohiro" <otani@kddilabs.jp> Message-Id: <0230F537-A4C8-4131-BF40-B357431ADCB9@lucidvision.com> From: Thomas Nadeau <tnadeau@lucidvision.com> To: "Zafar Ali (zali)" <zali@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) 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:tnadeau@lucidvision.com] >> Sent: Tuesday, December 04, 2007 8:43 AM >> To: ccamp@ops.ietf.org >> 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 > > >> >> >> > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 05 Dec 2007 10:35:49 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: draft-ali-ccamp-gmpls-LSP-ping-traceroute-00.txt Date: Wed, 5 Dec 2007 05:33:11 -0500 Message-ID: <BABC859E6D0B9A4D8448CC7F41CD2B07058E58EC@xmb-rtp-203.amer.cisco.com> Thread-Topic: draft-ali-ccamp-gmpls-LSP-ping-traceroute-00.txt Thread-Index: Acg2e6FsYB0cNs4pQEmREDiLbfmfZAAcuWsA From: "Zafar Ali (zali)" <zali@cisco.com> To: "Thomas Nadeau" <tnadeau@lucidvision.com>, <ccamp@ops.ietf.org> Cc: "Otani Tomohiro" <otani@kddilabs.jp> DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5187; t=1196850805; x=1197714805; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=zali@cisco.com; z=From:=20=22Zafar=20Ali=20(zali)=22=20<zali@cisco.com> |Subject:=20RE=3A=20draft-ali-ccamp-gmpls-LSP-ping-traceroute-00.txt=20 |Sender:=20 |To:=20=22Thomas=20Nadeau=22=20<tnadeau@lucidvision.com>,=20<ccamp@ops.ie tf.org>; bh=euf/LgUWmBw8Ei+owC80+lglgzAG8EJU3E8YXzdXiDU=; b=VaWKs3oKSjcvzOXFtfVljXyhlVhM1l/VFIpWxIvFeu+GwHb4mfGSduFE+gg4+uh9lYTNZk7B vkbZBJSDcOvkhKTSbZ2A9QYCIDsJXt07uzfJdyLIEv1OWIfG4p5L5T+K; Authentication-Results: rtp-dkim-1; header.From=zali@cisco.com; dkim=pass (s ig from cisco.com/rtpdkim1001 verified; ); Hi Tom-=20 Thanks for your review; please see comments in-line. =20 Thanks Regards... Zafar=20 > -----Original Message----- > From: Thomas Nadeau [mailto:tnadeau@lucidvision.com]=20 > Sent: Tuesday, December 04, 2007 8:43 AM > To: ccamp@ops.ietf.org > 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 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 05 Dec 2007 07:00:05 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8370C.22930EF6" Subject: RE: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt Date: Wed, 5 Dec 2007 06:55:15 -0000 Message-ID: <2ECAA42C79676B42AEBAC11229CA7D0C01880C37@E03MVB2-UKBR.domain1.systemhost.net> Thread-Topic: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt Thread-Index: Acg23NTxGvHAwYB1RMusTe1rH8zc1AABNqKAAAj7JuA= From: <neil.2.harrison@bt.com> To: <Attila.Takacs@ericsson.com>, <tnadeau@lucidvision.com>, <diego.caviglia@ericsson.com> Cc: <ccamp@ops.ietf.org> 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: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On = Behalf Of Attila Takacs Sent: 05 December 2007 02:03 To: Thomas Nadeau; Diego Caviglia Cc: ccamp@ops.ietf.org 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:tnadeau@lucidvision.com]=20 Sent: Wednesday, December 05, 2007 2:19 AM To: Diego Caviglia Cc: Attila Takacs; ccamp@ops.ietf.org; balazs.gero@ericsson.com 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: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On = Behalf Of Thomas Nadeau Sent: marted=EC 4 dicembre 2007 11.30 To: Attila Takacs Cc: ccamp@ops.ietf.org; balazs.gero@ericsson.com 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:tnadeau@lucidvision.com]=20 Sent: Tuesday, December 04, 2007 2:58 PM To: ccamp@ops.ietf.org Cc: Attila Takacs; balazs.gero@ericsson.com 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. I read the draft and thought it was = excellent. =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. If we don't ensure this then there will be obvious = operational=20 problems. 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> </DIV> <DIV><SPAN class=3D673011106-05122007><FONT face=3D"Comic Sans MS" = color=3D#800000=20 size=3D2>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=20 signalling and routing components). 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 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. 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> </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. When we partition a time resource in = irregular=20 time-slices we create a co-ps mode layer network. 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> </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 owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] <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> = ccamp@ops.ietf.org<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:tnadeau@lucidvision.com] <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 ccamp@ops.ietf.org; balazs.gero@ericsson.com<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"> = =20 My understanding of the ID was that RSVP-TE can be used to = ‘piggyback’ 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> </DIV></BLOCKQUOTE> <DIV><SPAN class=3D993515301-05122007><FONT face=3DArial = color=3D#0000ff size=3D2>IEEE=20 specified CFM and MIBs to setup CFM. </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 a = control plane=20 to setup the data plane. In this case we propose to use 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’re not happy with the fact the = ID is so=20 technology specific am I right?=20 </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. <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> </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 ‘session’ 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. 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> </DIV> <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20 class=3D993515301-05122007></SPAN></FONT> </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> </DIV> <DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT> </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> </DIV> <DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT> </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> <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> </SPAN><A=20 = href=3D"mailto:owner-ccamp@ops.ietf.org">owner-ccamp@ops.ietf.org</A> = [<A=20 style=3D"COLOR: blue; TEXT-DECORATION: underline"=20 = href=3D"mailto:owner-ccamp@ops.ietf.org">mailto:owner-ccamp@ops.ietf.org<= /A>]<SPAN=20 class=3DApple-converted-space> </SPAN><B><SPAN=20 style=3D"FONT-WEIGHT: bold">On Behalf Of<SPAN=20 class=3DApple-converted-space> </SPAN></SPAN></B>Thomas=20 Nadeau<BR><B><SPAN style=3D"FONT-WEIGHT: = bold">Sent:</SPAN></B><SPAN=20 class=3DApple-converted-space> </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> </SPAN>Attila = Takacs<BR><B><SPAN=20 style=3D"FONT-WEIGHT: bold">Cc:</SPAN></B><SPAN=20 class=3DApple-converted-space> </SPAN><A=20 style=3D"COLOR: blue; TEXT-DECORATION: underline"=20 href=3D"mailto:ccamp@ops.ietf.org">ccamp@ops.ietf.org</A>;<SPAN=20 class=3DApple-converted-space> </SPAN><A=20 style=3D"COLOR: blue; TEXT-DECORATION: underline"=20 = href=3D"mailto:balazs.gero@ericsson.com">balazs.gero@ericsson.com</A><BR>= <B><SPAN=20 style=3D"FONT-WEIGHT: bold">Subject:</SPAN></B><SPAN=20 class=3DApple-converted-space> </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 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> </SPAN>Thomas Nadeau [<A=20 style=3D"COLOR: blue; TEXT-DECORATION: underline"=20 = href=3D"mailto:tnadeau@lucidvision.com">mailto:tnadeau@lucidvision.com</A= >]<SPAN=20 class=3DApple-converted-space> </SPAN><BR><B><SPAN=20 style=3D"FONT-WEIGHT: bold">Sent:</SPAN></B><SPAN=20 class=3DApple-converted-space> </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> </SPAN><A=20 style=3D"COLOR: blue; TEXT-DECORATION: underline"=20 = href=3D"mailto:ccamp@ops.ietf.org">ccamp@ops.ietf.org</A><BR><B><SPAN=20 style=3D"FONT-WEIGHT: bold">Cc:</SPAN></B><SPAN=20 class=3DApple-converted-space> </SPAN>Attila Takacs;<SPAN=20 class=3DApple-converted-space> </SPAN><A=20 style=3D"COLOR: blue; TEXT-DECORATION: underline"=20 = href=3D"mailto:balazs.gero@ericsson.com">balazs.gero@ericsson.com</A><BR>= <B><SPAN=20 style=3D"FONT-WEIGHT: bold">Subject:</SPAN></B><SPAN=20 = class=3DApple-converted-space> </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, I am concerned that the definition of a new TLV = and these=20 procedures represent <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. 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 <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. </SPAN></FONT><FONT face=3DArial = color=3Dblue=20 size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: = Arial"> </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 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. That is, to establish = CFM=20 entities for GMPLS controlled Ethernet LSPs. 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"> <SPAN=20 = class=3DApple-converted-space> </SPAN></SPAN></FONT></SPAN>This=20 solution specifically only works for GMPLS ethernet LSPs, right?=20 <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) 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? 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? 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. <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) 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 truly 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 not just a single hop above a transport = LSP. In this=20 case Ethernet layer (for clarity GELS) may provide = protection for=20 Ethernet LSPs. In any case, 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 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"> = [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"> = of=20 bidirectional point-to-point PBB-TE connections.=20 <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) 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. = 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"> <SPAN=20 class=3Dapple-tab-span><SPAN=20 class=3DApple-converted-space> </SPAN></SPAN> 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"> = 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"> <SPAN=20 class=3Dapple-tab-span><SPAN=20 class=3DApple-converted-space> </SPAN></SPAN> =20 established. 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"> 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). = 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 </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 to your point #1. There is no relation to the=20 gmpls-LSP-ping draft. </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"> <SPAN=20 = class=3DApple-converted-space> </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"> <SPAN=20 = class=3DApple-converted-space> </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-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 05 Dec 2007 02:04:43 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C836E3.05B15F17" Subject: RE: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt Date: Wed, 5 Dec 2007 03:03:26 +0100 Message-ID: <53CCFDD6E346CB43994852666C210E9102624609@esealmw116.eemea.ericsson.se> Thread-Topic: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt Thread-Index: Acg23NTxGvHAwYB1RMusTe1rH8zc1AABNqKA From: "Attila Takacs" <Attila.Takacs@ericsson.com> To: "Thomas Nadeau" <tnadeau@lucidvision.com>, "Diego Caviglia" <diego.caviglia@ericsson.com> Cc: <ccamp@ops.ietf.org> 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:tnadeau@lucidvision.com]=20 Sent: Wednesday, December 05, 2007 2:19 AM To: Diego Caviglia Cc: Attila Takacs; ccamp@ops.ietf.org; balazs.gero@ericsson.com 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: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On = Behalf Of Thomas Nadeau Sent: marted=EC 4 dicembre 2007 11.30 To: Attila Takacs Cc: ccamp@ops.ietf.org; balazs.gero@ericsson.com 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:tnadeau@lucidvision.com]=20 Sent: Tuesday, December 04, 2007 2:58 PM To: ccamp@ops.ietf.org Cc: Attila Takacs; balazs.gero@ericsson.com 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:tnadeau@lucidvision.com] <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 ccamp@ops.ietf.org; balazs.gero@ericsson.com<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"> = =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> </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. </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 a = control plane to=20 setup the data plane. In this case we propose to use 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? = </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. <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> </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. 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> </DIV> <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20 class=3D993515301-05122007></SPAN></FONT> </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> </DIV> <DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT> </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> </DIV> <DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT> </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> <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> </SPAN><A=20 = href=3D"mailto:owner-ccamp@ops.ietf.org">owner-ccamp@ops.ietf.org</A> = [<A=20 style=3D"COLOR: blue; TEXT-DECORATION: underline"=20 = href=3D"mailto:owner-ccamp@ops.ietf.org">mailto:owner-ccamp@ops.ietf.org<= /A>]<SPAN=20 class=3DApple-converted-space> </SPAN><B><SPAN=20 style=3D"FONT-WEIGHT: bold">On Behalf Of<SPAN=20 class=3DApple-converted-space> </SPAN></SPAN></B>Thomas=20 Nadeau<BR><B><SPAN style=3D"FONT-WEIGHT: bold">Sent:</SPAN></B><SPAN = class=3DApple-converted-space> </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> </SPAN>Attila Takacs<BR><B><SPAN = style=3D"FONT-WEIGHT: bold">Cc:</SPAN></B><SPAN=20 class=3DApple-converted-space> </SPAN><A=20 style=3D"COLOR: blue; TEXT-DECORATION: underline"=20 href=3D"mailto:ccamp@ops.ietf.org">ccamp@ops.ietf.org</A>;<SPAN=20 class=3DApple-converted-space> </SPAN><A=20 style=3D"COLOR: blue; TEXT-DECORATION: underline"=20 = href=3D"mailto:balazs.gero@ericsson.com">balazs.gero@ericsson.com</A><BR>= <B><SPAN=20 style=3D"FONT-WEIGHT: bold">Subject:</SPAN></B><SPAN=20 class=3DApple-converted-space> </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 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> </SPAN>Thomas Nadeau [<A=20 style=3D"COLOR: blue; TEXT-DECORATION: underline"=20 = href=3D"mailto:tnadeau@lucidvision.com">mailto:tnadeau@lucidvision.com</A= >]<SPAN=20 class=3DApple-converted-space> </SPAN><BR><B><SPAN=20 style=3D"FONT-WEIGHT: bold">Sent:</SPAN></B><SPAN=20 class=3DApple-converted-space> </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> </SPAN><A=20 style=3D"COLOR: blue; TEXT-DECORATION: underline"=20 = href=3D"mailto:ccamp@ops.ietf.org">ccamp@ops.ietf.org</A><BR><B><SPAN=20 style=3D"FONT-WEIGHT: bold">Cc:</SPAN></B><SPAN=20 class=3DApple-converted-space> </SPAN>Attila Takacs;<SPAN=20 class=3DApple-converted-space> </SPAN><A=20 style=3D"COLOR: blue; TEXT-DECORATION: underline"=20 = href=3D"mailto:balazs.gero@ericsson.com">balazs.gero@ericsson.com</A><BR>= <B><SPAN=20 style=3D"FONT-WEIGHT: bold">Subject:</SPAN></B><SPAN=20 = class=3DApple-converted-space> </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, I am concerned that the definition of a new TLV and = these=20 procedures represent <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. 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 <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. </SPAN></FONT><FONT face=3DArial = color=3Dblue=20 size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: = Arial"> </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 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. That is, to establish CFM entities = for=20 GMPLS controlled Ethernet LSPs. 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"> <SPAN=20 class=3DApple-converted-space> </SPAN></SPAN></FONT></SPAN>This = solution=20 specifically only works for GMPLS ethernet LSPs, right?=20 <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) 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? 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? 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. <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) 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 truly 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 not just a single hop above a transport LSP. In = this=20 case Ethernet layer (for clarity GELS) may provide protection = for=20 Ethernet LSPs. In any case, 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 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"> = [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"> of = bidirectional point-to-point PBB-TE connections.=20 <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) 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. 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"> <SPAN=20 class=3Dapple-tab-span><SPAN=20 class=3DApple-converted-space> </SPAN></SPAN> 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"> = 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"> <SPAN=20 class=3Dapple-tab-span><SPAN=20 class=3DApple-converted-space> </SPAN></SPAN> =20 established. 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"> 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). = 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 </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 to your point #1. There is no relation to the=20 gmpls-LSP-ping draft. </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"> <SPAN=20 class=3DApple-converted-space> </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"> <SPAN=20 = class=3DApple-converted-space> </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-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 05 Dec 2007 01:20:45 +0000 Cc: "Attila Takacs" <Attila.Takacs@ericsson.com>, <ccamp@ops.ietf.org>, <balazs.gero@ericsson.com> Message-Id: <238388FD-E9A8-47B3-A52D-8DBFBDFE33DB@lucidvision.com> From: Thomas Nadeau <tnadeau@lucidvision.com> To: "Diego Caviglia" <diego.caviglia@ericsson.com> Content-Type: multipart/alternative; boundary=Apple-Mail-28--532988434 Mime-Version: 1.0 (Apple Message framework v915) 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: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On =20= > Behalf Of Thomas Nadeau > Sent: marted=EC 4 dicembre 2007 11.30 > To: Attila Takacs > Cc: ccamp@ops.ietf.org; balazs.gero@ericsson.com > 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:tnadeau@lucidvision.com] > Sent: Tuesday, December 04, 2007 2:58 PM > To: ccamp@ops.ietf.org > Cc: Attila Takacs; balazs.gero@ericsson.com > 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; = "> = 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? = </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. <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. 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> <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> </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"> </span><a = href=3D"mailto:owner-ccamp@ops.ietf.org">owner-ccamp@ops.ietf.org</a> = [<a href=3D"mailto:owner-ccamp@ops.ietf.org" style=3D"color: blue; = text-decoration: underline; ">mailto:owner-ccamp@ops.ietf.org</a>]<span = class=3D"Apple-converted-space"> </span><b><span = style=3D"font-weight: bold; ">On Behalf Of<span = class=3D"Apple-converted-space"> </span></span></b>Thomas = Nadeau<br><b><span style=3D"font-weight: bold; ">Sent:</span></b><span = class=3D"Apple-converted-space"> </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"> </span>Attila Takacs<br><b><span = style=3D"font-weight: bold; ">Cc:</span></b><span = class=3D"Apple-converted-space"> </span><a = href=3D"mailto:ccamp@ops.ietf.org" style=3D"color: blue; = text-decoration: underline; ">ccamp@ops.ietf.org</a>;<span = class=3D"Apple-converted-space"> </span><a = href=3D"mailto:balazs.gero@ericsson.com" style=3D"color: blue; = text-decoration: underline; ">balazs.gero@ericsson.com</a><br><b><span = style=3D"font-weight: bold; ">Subject:</span></b><span = class=3D"Apple-converted-space"> </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> </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> </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; = "> <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 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; = "> <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> </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"> </span>Thomas Nadeau [<a = href=3D"mailto:tnadeau@lucidvision.com" style=3D"color: blue; = text-decoration: underline; ">mailto:tnadeau@lucidvision.com</a>]<span = class=3D"Apple-converted-space"> </span><br><b><span = style=3D"font-weight: bold; ">Sent:</span></b><span = class=3D"Apple-converted-space"> </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"> </span><a = href=3D"mailto:ccamp@ops.ietf.org" style=3D"color: blue; = text-decoration: underline; ">ccamp@ops.ietf.org</a><br><b><span = style=3D"font-weight: bold; ">Cc:</span></b><span = class=3D"Apple-converted-space"> </span>Attila Takacs;<span = class=3D"Apple-converted-space"> </span><a = href=3D"mailto:balazs.gero@ericsson.com" style=3D"color: blue; = text-decoration: underline; ">balazs.gero@ericsson.com</a><br><b><span = style=3D"font-weight: bold; ">Subject:</span></b><span = class=3D"Apple-converted-space"> </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> </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> </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> </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, I am concerned that the = definition of a new TLV and these procedures = represent <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. = 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 <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. </span></font><font size=3D"2" color=3D"blue" = face=3D"Arial"><span style=3D"font-size: 10pt; font-family: Arial; = color: blue; = "> </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 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.</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> </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; = "> <span = class=3D"Apple-converted-space"> </span></span></font></span>This = solution specifically only works for GMPLS ethernet LSPs, right? = <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) 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? 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? 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. <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) 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 truly 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 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.</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> </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 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; = "> <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> </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; "> [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; "> of bidirectional = point-to-point PBB-TE connections. = <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> </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; = "> <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> </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) 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> </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. 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> </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; "> <span class=3D"apple-tab-span"><span = class=3D"Apple-converted-space"> </span></span> 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; "> 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; "> <span class=3D"apple-tab-span"><span = class=3D"Apple-converted-space"> </span></span> = established. 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; "> 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> </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> </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). 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 </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 to your point #1. There is no relation to the = gmpls-LSP-ping draft. </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> </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; = "> <span = class=3D"Apple-converted-space"> </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> </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; = "> <span = class=3D"Apple-converted-space"> </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> </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> </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> </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></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></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> </o:p></span></font></div></div></div></div></span></blockquo= te></div><br></body></html>= --Apple-Mail-28--532988434-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 05 Dec 2007 00:36:25 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C836D6.7D4FEF53" Subject: RE: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt Date: Wed, 5 Dec 2007 01:33:41 +0100 Message-ID: <0428AC48A879ED46A94F39D5665DF684DF2AB9@esealmw110.eemea.ericsson.se> Thread-Topic: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt Thread-Index: Acg2rlSmo3V62q2PQumJpMz52jLMPgAJwcxw From: "Diego Caviglia" <diego.caviglia@ericsson.com> To: "Thomas Nadeau" <tnadeau@lucidvision.com>, "Attila Takacs" <Attila.Takacs@ericsson.com> Cc: <ccamp@ops.ietf.org>, <balazs.gero@ericsson.com> 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: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On = Behalf Of Thomas Nadeau Sent: marted=EC 4 dicembre 2007 11.30 To: Attila Takacs Cc: ccamp@ops.ietf.org; balazs.gero@ericsson.com 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:tnadeau@lucidvision.com]=20 Sent: Tuesday, December 04, 2007 2:58 PM To: ccamp@ops.ietf.org Cc: Attila Takacs; balazs.gero@ericsson.com 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 ‘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.<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> </o:p></span></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’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 ‘session’ 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> </o:p></span></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> </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'> owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] <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> ccamp@ops.ietf.org; balazs.gero@ericsson.com<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> </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> </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'> <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 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'> <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> </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:tnadeau@lucidvision.com">mailto:tnadeau@lucidvision.com</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:ccamp@ops.ietf.org">ccamp@ops.ietf.org</a><br> <b><span style=3D'font-weight:bold'>Cc:</span></b> Attila Takacs; <a href=3D"mailto:balazs.gero@ericsson.com">balazs.gero@ericsson.com</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> </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> </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> </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, I am concerned that the definition of a new TLV = and these procedures represent <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. 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 <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. </span></font><font size=3D2 color=3Dblue face=3DArial><span = style=3D'font-size:10.0pt;font-family:Arial; color:blue'> </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 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.</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> </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? = <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) 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? 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? 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. <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) 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 truly 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 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.</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> </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 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'> <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> </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'> [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'> of bidirectional point-to-point = PBB-TE connections. <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> </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'> <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> </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) 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> </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. 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> </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'> <span class=3Dapple-tab-span> </span> = 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'> 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'> <span class=3Dapple-tab-span> </span> established. 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'> 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> </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> </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). 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 </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 to your point #1. = There is no relation to the gmpls-LSP-ping = draft. </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> </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> </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> </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> </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> </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></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></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> </o:p></span></font></p> </div> </div> </body> </html> ------_=_NextPart_001_01C836D6.7D4FEF53-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 04 Dec 2007 19:30:24 +0000 Cc: <ccamp@ops.ietf.org>, <balazs.gero@ericsson.com> Message-Id: <7BEFF760-FEC4-4E10-974F-21386B048B13@lucidvision.com> From: Thomas Nadeau <tnadeau@lucidvision.com> To: "Attila Takacs" <Attila.Takacs@ericsson.com> Content-Type: multipart/alternative; boundary=Apple-Mail-25--553931354 Mime-Version: 1.0 (Apple Message framework v915) 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:tnadeau@lucidvision.com] > Sent: Tuesday, December 04, 2007 2:58 PM > To: ccamp@ops.ietf.org > Cc: Attila Takacs; balazs.gero@ericsson.com > 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> </div> <div><span = class=3D"382281718-04122007"><font face=3D"Arial" color=3D"#0000ff" = size=3D"2">Thank you 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> </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:tnadeau@lucidvision.com">mailto:tnadeau@lucidvision.com</a>= ] <br><b>Sent:</b> Tuesday, December 04, 2007 2:58 PM<br><b>To:</b> <a = href=3D"mailto:ccamp@ops.ietf.org">ccamp@ops.ietf.org</a><br><b>Cc:</b> = Attila Takacs; <a = href=3D"mailto:balazs.gero@ericsson.com">balazs.gero@ericsson.com</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, I am concerned that the definition of a new TLV and = these procedures represent </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. 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 <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. <span = class=3D"382281718-04122007"><font face=3D"Arial" color=3D"#0000ff" = size=3D"2"> </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 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, = </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? </div><div>What do I do if I = want to set up MPLS ethernet LSPs (i.e.: PWs) and do CFM over = those? Oh,</div><div>that is a different solution, right? 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? 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. </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) 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 truly 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 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.</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 ID focuses on = Ethernet LSPs within a network.</font></span></div> <div><font = face=3D"Arial" color=3D"#0000ff" size=3D"2"></font> </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> [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> of bidirectional = point-to-point PBB-TE connections. </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> </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) 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. 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> <span class=3D"Apple-tab-span" style=3D"WHITE-SPACE: = pre"> </span> 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> 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> <span class=3D"Apple-tab-span" style=3D"WHITE-SPACE: = pre"> </span> established. 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> 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). = 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 <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 to your = point #1. There is no relation to the gmpls-LSP-ping = draft.</span><span = class=3D"382281718-04122007"> </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> </div> <div dir=3D"ltr" = style=3D"MARGIN: 0px; FONT: 12px Helvetica"><font face=3D"Arial" = color=3D"#0000ff" = size=3D"2"></font> </div></div></blockquote></div><br></body></html>= --Apple-Mail-25--553931354-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 04 Dec 2007 19:29:57 +0000 Cc: ccamp@ops.ietf.org, attila.takacs@ericsson.com, balazs.gero@ericsson.com Message-Id: <29EB99D8-42DC-4133-8AFA-DFD9D9FA928F@lucidvision.com> From: Thomas Nadeau <tnadeau@lucidvision.com> To: Loa Andersson <loa@pi.se> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) 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: loa.andersson@acreo.se > loa@pi.se > > This email was Anti Virus checked by Astaro Security Gateway. http://www.astaro.com > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 04 Dec 2007 19:28:01 +0000 Message-ID: <4755A9DF.5060809@pi.se> Date: Tue, 04 Dec 2007 20:26:23 +0100 From: Loa Andersson <loa@pi.se> Organization: Acreo AB User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Thomas Nadeau <tnadeau@lucidvision.com> CC: ccamp@ops.ietf.org, attila.takacs@ericsson.com, balazs.gero@ericsson.com Subject: Re: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: loa.andersson@acreo.se loa@pi.se This email was Anti Virus checked by Astaro Security Gateway. http://www.astaro.com Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 04 Dec 2007 18:55:34 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C836A6.BD3C0438" Subject: RE: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt Date: Tue, 4 Dec 2007 19:51:54 +0100 Message-ID: <53CCFDD6E346CB43994852666C210E9102624606@esealmw116.eemea.ericsson.se> Thread-Topic: draft-takacs-ccamp-rsvp-te-eth-oam-ext-00.txt Thread-Index: Acg2fa9ERD84PXLlRIuBghgkPWaGDAAJD5Sg From: "Attila Takacs" <Attila.Takacs@ericsson.com> To: "Thomas Nadeau" <tnadeau@lucidvision.com>, <ccamp@ops.ietf.org> Cc: <balazs.gero@ericsson.com> 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:tnadeau@lucidvision.com]=20 Sent: Tuesday, December 04, 2007 2:58 PM To: ccamp@ops.ietf.org Cc: Attila Takacs; balazs.gero@ericsson.com 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> </DIV> <DIV><SPAN class=3D382281718-04122007><FONT face=3DArial color=3D#0000ff = size=3D2>Thank=20 you 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> </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:tnadeau@lucidvision.com] <BR><B>Sent:</B> Tuesday, December = 04, 2007=20 2:58 PM<BR><B>To:</B> ccamp@ops.ietf.org<BR><B>Cc:</B> Attila Takacs;=20 balazs.gero@ericsson.com<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, I am concerned that the definition of a new TLV and = these=20 procedures represent </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. 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 <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. <SPAN=20 class=3D382281718-04122007><FONT face=3DArial color=3D#0000ff=20 size=3D2> </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 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. That is, to establish CFM entities for GMPLS = controlled=20 Ethernet LSPs. 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) 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 truly 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 not=20 just a single hop above a transport LSP. In this = case Ethernet=20 layer (for clarity GELS) may provide protection for Ethernet = LSPs. In any=20 case, 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 ID focuses on Ethernet LSPs within a=20 network.</FONT></SPAN></DIV> <DIV><FONT face=3DArial color=3D#0000ff size=3D2></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><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> [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> of bidirectional = point-to-point=20 PBB-TE connections. </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> </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) 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. 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> <SPAN class=3DApple-tab-span=20 style=3D"WHITE-SPACE: pre"> </SPAN> 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> 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> <SPAN class=3DApple-tab-span=20 style=3D"WHITE-SPACE: pre"> </SPAN> established. 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> 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). 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 <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 to=20 your point #1. There is no relation to the gmpls-LSP-ping=20 draft.</SPAN><SPAN=20 class=3D382281718-04122007> </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> </DIV> <DIV dir=3Dltr style=3D"MARGIN: 0px; FONT: 12px Helvetica"><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT> </DIV></BODY></HTML> ------_=_NextPart_001_01C836A6.BD3C0438-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 04 Dec 2007 13:58:37 +0000 Cc: attila.takacs@ericsson.com, balazs.gero@ericsson.com Message-Id: <82939598-D4E1-418F-B661-D6E5A7A4AB09@lucidvision.com> From: Thomas Nadeau <tnadeau@lucidvision.com> To: ccamp@ops.ietf.org Content-Type: multipart/alternative; boundary=Apple-Mail-19--573868090 Mime-Version: 1.0 (Apple Message framework v915) 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, I am concerned that the definition of a new TLV and these = procedures represent </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. 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 <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. <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) 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 truly 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> [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> of bidirectional point-to-point PBB-TE connections. = </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) = 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. 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> <span = class=3D"Apple-tab-span" style=3D"white-space:pre"> </span> 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> 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> <span = class=3D"Apple-tab-span" style=3D"white-space:pre"> </span> = established. 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> 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). 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 <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-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 04 Dec 2007 13:45:29 +0000 Cc: Otani Tomohiro <otani@kddilabs.jp>, "((zali)) Ali Zafar" <zali@cisco.com> Message-Id: <1AF0E1E7-0264-4F61-A890-EE6BD4ADC1A9@lucidvision.com> From: Thomas Nadeau <tnadeau@lucidvision.com> To: ccamp@ops.ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) 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. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 04 Dec 2007 03:56:55 +0000 Message-ID: <02b301c83629$48da8a60$bd148182@your029b8cecfe> Reply-To: "Adrian Farrel" <adrian@olddog.co.uk> From: "Adrian Farrel" <adrian@olddog.co.uk> To: <ccamp@ops.ietf.org> 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 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit 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" <loa@pi.se> To: <mpls@ietf.org> 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: loa.andersson@acreo.se > loa@pi.se > > This email was Anti Virus checked by Astaro Security Gateway. > http://www.astaro.com > > > > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 03 Dec 2007 04:24:41 +0000 Reply-To: <sunwq@sjtu.edu.cn> From: "Weiqiang Sun" <sunwq@sjtu.edu.cn> To: "'Adrian Farrel'" <adrian@olddog.co.uk>, <ccamp@ops.ietf.org> Cc: "'Brungard, Deborah A, ALABS'" <dbrungard@att.com> Subject: RE: Slides on line Date: Sun, 2 Dec 2007 23:20:59 -0500 Organization: Shanghai Jiao Tong University Message-ID: <000901c83563$ef430380$cdc90a80$@edu.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: Acg1IQJecz518i1+TOaCMFWC8s6UAQAQWOfw Content-Language: zh-cn 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: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel Sent: Sunday, December 02, 2007 2:56 PM To: ccamp@ops.ietf.org 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 Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 02 Dec 2007 19:59:10 +0000 Date: Sun, 02 Dec 2007 19:55:53 +0000 From: Adrian Farrel <adrian@olddog.co.uk> Subject: Slides on line To: ccamp@ops.ietf.org Cc: "Brungard, Deborah A, ALABS" <dbrungard@att.com> Reply-to: Adrian Farrel <adrian@olddog.co.uk> Message-id: <006601c8351d$5a473940$7c01a8c0@your029b8cecfe> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7bit 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 Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 02 Dec 2007 12:54:48 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: comment on draft-otani-ccamp-gmpls-routing-interlink-01.txt Date: Sun, 2 Dec 2007 13:49:42 +0100 Message-ID: <8144761F31F48D43AD53D09F5350E38002176823@FRVELSMBS22.ad2.ad.alcatel.com> Thread-Topic: comment on draft-otani-ccamp-gmpls-routing-interlink-01.txt Thread-Index: Acg04c8CO25SA0PUSraJmcR4OeJpvg== From: "PAPADIMITRIOU Dimitri" <Dimitri.Papadimitriou@alcatel-lucent.be> To: <ccamp@ops.ietf.org> 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.
- Get $2400 welcome bonus Berta Hare