From 0112colo2008@gmail.com Mon Dec 1 16:22:26 2008 Return-Path: <0112colo2008@gmail.com> X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AA533A6991 for ; Mon, 1 Dec 2008 16:22:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.978 X-Spam-Level: * X-Spam-Status: No, score=1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, SUBJ_ALL_CAPS=2.077] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p+qd806X4W-2 for ; Mon, 1 Dec 2008 16:22:25 -0800 (PST) Received: from maildcarg4.dc-host.net.ar (maildcarg4.dc-host.net.ar [200.55.6.135]) by core3.amsl.com (Postfix) with ESMTP id 914C53A697B for ; Mon, 1 Dec 2008 16:22:25 -0800 (PST) Received: from coloso ([200.122.92.50]) by maildcarg4.dc-host.net.ar (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPA id <0KB800GQO3OUM5C0@maildcarg4.dc-host.net.ar> for ccamp-archive@ietf.org; Mon, 01 Dec 2008 21:22:06 -0300 (ART) Date: Mon, 01 Dec 2008 21:20:51 -0300 From: "0112colo2008@gmail.com" <0112colo2008@gmail.com> Subject: COMPUTADORA ATHLON COMPLETA To: PC FULL <0112colo2008@gmail.com> Message-id: <380-22008122202051142@coloso> MIME-version: 1.0 Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: quoted-printable COMPUTADORAS con 1 A=D1O DE GARANTIA ENTREGA EN LOCAL EN LA ZONA DE CABALL= ITO - CAPITAL FEDERAL ENVIOS AL INTERIOR, PAGO CON TARJETA DE CREDITO DE MANERA TELEFONICA CREDITOS PERSONALES HASTA EN 36 CUOTAS FACTURA A o B EMail: 0112colo2008@gmail=2Ecom -Modelo: ATHLON FIRE -Procesador: AMD ATHLON 64 DUAL CORE 5000+ Socket AM2 BOX -Motherboard: MSI K9N6GM-V chipset nVidia nForce 430 -Memoria: 1GB DDR2 667 -Placa de video: nVIDIA GeForce 6100GS 256MB -Disco r=EDgido: 80 GB SATA2 -Medio optico: ReGrabadora de DVD PHILIPS 20X -Placa de red: 10/100 on board -Placa de sonido: 8 canales -Puertos: 2USB frontales + 4USB traseros -Gabinete: KIT CIRKUIT PLANET 1305 -Teclado multimedia, Mouse optico, Parlantes y Diskettera 3 =BD=2E -Garantia 12 meses -Sistema operativo instalado y funcionando FULL, todos los programa y util= idades -Monitor: LCD 17" LG LS177WS Wide Screen -$1699 IVA Incluido Consulte por otras configuracion y otros productos, monitores LCD, noteboo= ks, etc From owner-ccamp@ops.ietf.org Tue Dec 2 07:10:07 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E7893A682D for ; Tue, 2 Dec 2008 07:10:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2hbb4ZLjqWT8 for ; Tue, 2 Dec 2008 07:10:06 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B578A3A68E3 for ; Tue, 2 Dec 2008 07:10:05 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7Wmi-00022y-LW for ccamp-data@psg.com; Tue, 02 Dec 2008 15:03:32 +0000 Received: from [164.164.94.83] (helo=webmail.india.tejasnetworks.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7Wmc-00022S-45 for ccamp@ops.ietf.org; Tue, 02 Dec 2008 15:03:29 +0000 Received: from localhost (unknown [127.0.0.1]) by webmail.india.tejasnetworks.com (india.tejasnetworks.com) with ESMTP id 6E6C62619EA; Tue, 2 Dec 2008 20:33:07 +0530 (IST) X-Virus-Scanned: amavisd-new at india.tejasnetworks.com Received: from webmail.india.tejasnetworks.com ([127.0.0.1]) by localhost (anche.india.tejasnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V+6IP4pfhf2a; Tue, 2 Dec 2008 20:33:02 +0530 (IST) Received: from Jishnu (unknown [192.168.0.10]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by webmail.india.tejasnetworks.com (india.tejasnetworks.com) with ESMTPSA id 8E9D02619E3; Tue, 2 Dec 2008 20:33:01 +0530 (IST) From: "Jishnu A" To: "'Greg Bernstein'" Cc: "'ccamp'" Subject: RE: [BULK] VCAT/LCAS draft update... Date: Tue, 2 Dec 2008 20:33:11 +0530 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AclJrPDNcWgth2kzTzadPlFRiy1ovgK4KNJQ In-Reply-To: <49230B3F.9010405@grotto-networking.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Dear Greg, One additional problem with VCAT/LCAS is the amount of differential delay supported at the destination node. Can it be mentioned as a note that co-routing or diversely routing is also based on the availability of enough sufficient differential delay buffer size at the destination node? Regards, Jishnu A -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Greg Bernstein Sent: Wednesday, November 19, 2008 12:07 AM To: ccamp Subject: [BULK] VCAT/LCAS draft update... Importance: Low Hi folks, I edited the VCAT/LCAS draft to use the CALL_ATTRIBUTES object from the MLN extensions draft. We define a new VCAT TLV for use in the aforementioned object. All procedures and encodings otherwise are the same as the previous draft. Note that the draft will now be contingent on the MLN extensions draft moving forward. A URL for the Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-vcat-lcas-06.txt Regards Greg -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 __________ Information from ESET NOD32 Antivirus, version of virus signature database 3623 (20081118) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __________ Information from ESET NOD32 Antivirus, version of virus signature database 3658 (20081202) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com From jerrileeraddie@21plus.org Tue Dec 2 07:23:41 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAD3B28C0ED for ; Tue, 2 Dec 2008 07:23:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.711 X-Spam-Level: X-Spam-Status: No, score=-14.711 tagged_above=-999 required=5 tests=[BAYES_60=1, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_SPACE_RATIO=2.219, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p6axHZmdiU6w for ; Tue, 2 Dec 2008 07:23:41 -0800 (PST) Received: from bzq-84-110-150-19.red.bezeqint.net (bzq-84-110-150-19.red.bezeqint.net [84.110.150.19]) by core3.amsl.com (Postfix) with SMTP id C57AD28C0DD for ; Tue, 2 Dec 2008 07:23:39 -0800 (PST) To: Subject: Delivery Status Notification From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081202152339.C57AD28C0DD@core3.amsl.com> Date: Tue, 2 Dec 2008 07:23:39 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From owner-ccamp@ops.ietf.org Tue Dec 2 07:52:58 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A11D3A6A9A for ; Tue, 2 Dec 2008 07:52:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.863 X-Spam-Level: X-Spam-Status: No, score=-103.863 tagged_above=-999 required=5 tests=[AWL=0.632, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NfByxuX36bLm for ; Tue, 2 Dec 2008 07:52:57 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DBC703A6902 for ; Tue, 2 Dec 2008 07:52:56 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7XUn-0004bZ-0R for ccamp-data@psg.com; Tue, 02 Dec 2008 15:49:05 +0000 Received: from [216.82.241.147] (helo=mail146.messagelabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7XUi-0004b9-DL for ccamp@ops.ietf.org; Tue, 02 Dec 2008 15:49:02 +0000 X-VirusChecked: Checked X-Env-Sender: dbrungard@att.com X-Msg-Ref: server-5.tower-146.messagelabs.com!1228232938!9781977!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 31731 invoked from network); 2 Dec 2008 15:48:58 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-5.tower-146.messagelabs.com with AES256-SHA encrypted SMTP; 2 Dec 2008 15:48:58 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id mB2FmwNQ007904 for ; Tue, 2 Dec 2008 10:48:58 -0500 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id mB2FmqjX007856 for ; Tue, 2 Dec 2008 10:48:53 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [BULK] VCAT/LCAS draft update... Date: Tue, 2 Dec 2008 10:48:50 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BULK] VCAT/LCAS draft update... Thread-Index: AclJrPDNcWgth2kzTzadPlFRiy1ovgK4KNJQAAGrAUA= References: <49230B3F.9010405@grotto-networking.com> From: "BRUNGARD, DEBORAH A, ATTLABS" To: "Jishnu A" , "Greg Bernstein" Cc: "ccamp" Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Shouldn't be a problem if the data plane is based on ITU - so it would need to support (at minimum) ITU's G.707 minimum differential delay requirements for VCAT. Deborah -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Jishnu A Sent: Tuesday, December 02, 2008 10:03 AM To: 'Greg Bernstein' Cc: 'ccamp' Subject: RE: [BULK] VCAT/LCAS draft update... Dear Greg, One additional problem with VCAT/LCAS is the amount of differential delay supported at the destination node. Can it be mentioned as a note that co-routing or diversely routing is also based on the availability of enough sufficient differential delay buffer size at the destination node?=20 Regards, Jishnu A -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Greg Bernstein Sent: Wednesday, November 19, 2008 12:07 AM To: ccamp Subject: [BULK] VCAT/LCAS draft update... Importance: Low Hi folks, I edited the VCAT/LCAS draft to use the CALL_ATTRIBUTES object from the MLN extensions draft. We define a new VCAT TLV for use in the aforementioned object. All=20 procedures and encodings otherwise are the same as the previous draft.=20 Note that the draft will now be contingent on the MLN extensions draft=20 moving forward. A URL for the Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-vcat-lcas-06. txt Regards Greg --=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 __________ Information from ESET NOD32 Antivirus, version of virus signature database 3623 (20081118) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com =20 =20 __________ Information from ESET NOD32 Antivirus, version of virus signature database 3658 (20081202) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com =20 From owner-ccamp@ops.ietf.org Tue Dec 2 08:05:52 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BC333A680D for ; Tue, 2 Dec 2008 08:05:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.078 X-Spam-Level: X-Spam-Status: No, score=-1.078 tagged_above=-999 required=5 tests=[AWL=-1.520, BAYES_05=-1.11, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6hPuuEwIZ55C for ; Tue, 2 Dec 2008 08:05:51 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C13803A67D6 for ; Tue, 2 Dec 2008 08:05:51 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7XhH-0005Jn-Kr for ccamp-data@psg.com; Tue, 02 Dec 2008 16:01:59 +0000 Received: from [156.106.192.41] (helo=protext01.itu.ch) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7XhC-0005JJ-MB for ccamp@ops.ietf.org; Tue, 02 Dec 2008 16:01:57 +0000 Received: from protext01.itu.ch ([156.106.192.41]) by protext01.itu.ch with Microsoft SMTPSVC(5.0.2195.6713); Tue, 2 Dec 2008 17:01:52 +0100 Received: From mail6.itu.ch ([156.106.192.22]) by protext01.itu.ch (WebShield SMTP v4.5 MR3) id 1228233712382; Tue, 2 Dec 2008 17:01:52 +0100 Received: from your029b8cecfe ([156.106.216.176]) by mail6.itu.ch (8.14.3/8.14.3) with ESMTP id mB2G1p2o375352 for ; Tue, 2 Dec 2008 17:01:52 +0100 (MET) Message-ID: <2089B64D43144AEEA390F5C4C7232087@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: CCAMP drafts for adoption Date: Tue, 2 Dec 2008 16:01:48 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (mail6.itu.ch [156.106.192.22]); Tue, 02 Dec 2008 17:01:52 +0100 (MET) X-OriginalArrivalTime: 02 Dec 2008 16:01:52.0835 (UTC) FILETIME=[4ACA8130:01C95497] Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Hi, Can you please express your opinion on the adoption of the following three drafts as WG drafts. Thanks, Adrian draft-takacs-ccamp-oam-configuration-fwk-01.txt draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt draft-bernstein-ccamp-wson-encode-01.txt (to become -rwa-encode-00) Cheers, Adrian and Deborah From owner-ccamp@ops.ietf.org Tue Dec 2 08:08:20 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 921C43A6B3D for ; Tue, 2 Dec 2008 08:08:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.824 X-Spam-Level: X-Spam-Status: No, score=-1.824 tagged_above=-999 required=5 tests=[AWL=-0.776, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VmBWHBEB5nWQ for ; Tue, 2 Dec 2008 08:08:19 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8B5DF3A6B24 for ; Tue, 2 Dec 2008 08:08:19 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7XjY-0005T5-PU for ccamp-data@psg.com; Tue, 02 Dec 2008 16:04:20 +0000 Received: from [156.106.192.41] (helo=protext01.itu.ch) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7XjO-0005SK-V6 for ccamp@ops.ietf.org; Tue, 02 Dec 2008 16:04:17 +0000 Received: from protext01.itu.ch ([156.106.192.41]) by protext01.itu.ch with Microsoft SMTPSVC(5.0.2195.6713); Tue, 2 Dec 2008 17:04:09 +0100 Received: From mail6.itu.ch ([156.106.192.22]) by protext01.itu.ch (WebShield SMTP v4.5 MR3) id 1228233849117; Tue, 2 Dec 2008 17:04:09 +0100 Received: from n172005.ep.ad.eplus.de ([156.106.216.152]) by mail6.itu.ch (8.14.3/8.14.3) with ESMTP id mB2G42VT375069; Tue, 2 Dec 2008 17:04:07 +0100 (MET) Message-ID: <49355C72.2070407@chello.nl> Date: Tue, 02 Dec 2008 17:04:02 +0100 From: Huub van Helvoort Reply-To: hhelvoort@chello.nl User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: "BRUNGARD, DEBORAH A, ATTLABS" CC: Jishnu A , Greg Bernstein , ccamp Subject: Re: [BULK] VCAT/LCAS draft update... References: <49230B3F.9010405@grotto-networking.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (mail6.itu.ch [156.106.192.22]); Tue, 02 Dec 2008 17:04:08 +0100 (MET) X-OriginalArrivalTime: 02 Dec 2008 16:04:09.0882 (UTC) FILETIME=[9C7A37A0:01C95497] Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Hi Deborah, You replied: > Shouldn't be a problem if the data plane is based on ITU - so it would > need to support (at minimum) ITU's G.707 minimum differential delay > requirements for VCAT. Minimum delay in G.707 is 125 usec (micro-seconds)... Maximum differential delay depends on implementation. Differential is the difference between the largest propagation delay of one of the members and the smallest propagation delay of one of the members. The sink VCAT/LCAS function is capable of detecting and reporting whether one or more members does not fit the differential delay capability. Cheers, Huub. > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On > Behalf Of Jishnu A > Sent: Tuesday, December 02, 2008 10:03 AM > To: 'Greg Bernstein' > Cc: 'ccamp' > Subject: RE: [BULK] VCAT/LCAS draft update... > > Dear Greg, > One additional problem with VCAT/LCAS is the amount of differential > delay > supported at the destination node. Can it be mentioned as a note that > co-routing or diversely routing is also based on the availability of > enough > sufficient differential delay buffer size at the destination node? > > Regards, > Jishnu A > > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On > Behalf > Of Greg Bernstein > Sent: Wednesday, November 19, 2008 12:07 AM > To: ccamp > Subject: [BULK] VCAT/LCAS draft update... > Importance: Low > > Hi folks, I edited the VCAT/LCAS draft to use the CALL_ATTRIBUTES object > > from the MLN extensions draft. > We define a new VCAT TLV for use in the aforementioned object. All > procedures and encodings otherwise are the same as the previous draft. > Note that the draft will now be contingent on the MLN extensions draft > moving forward. > > A URL for the Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-vcat-lcas-06. > txt > > > Regards > > Greg > -- ================================================================ http://www.van-helvoort.eu/ ================================================================ Always remember that you are unique...just like everyone else... From owner-ccamp@ops.ietf.org Tue Dec 2 08:19:41 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D2F43A69E7 for ; Tue, 2 Dec 2008 08:19:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.197 X-Spam-Level: X-Spam-Status: No, score=-2.197 tagged_above=-999 required=5 tests=[AWL=-1.052, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_LOW=-1, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W2jUOOU86DrW for ; Tue, 2 Dec 2008 08:19:40 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 066743A69D3 for ; Tue, 2 Dec 2008 08:19:40 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7Xuh-000678-4K for ccamp-data@psg.com; Tue, 02 Dec 2008 16:15:51 +0000 Received: from [195.101.245.16] (helo=p-mail2.rd.francetelecom.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7Xuc-00066p-63 for ccamp@ops.ietf.org; Tue, 02 Dec 2008 16:15:48 +0000 Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Dec 2008 17:15:30 +0100 X-MIMEOLE: Produced By Microsoft Exchange V6.5 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: [BULK] VCAT/LCAS draft update... Date: Tue, 2 Dec 2008 17:15:28 +0100 Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB026060DE939@ftrdmel2> In-Reply-To: <49355C72.2070407@chello.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BULK] VCAT/LCAS draft update... Thread-index: AclUmEaWvfWTGkpbTNGTjpussHebnQAAD9Jw References: <49230B3F.9010405@grotto-networking.com> <49355C72.2070407@chello.nl> From: To: , Cc: , , X-OriginalArrivalTime: 02 Dec 2008 16:15:30.0541 (UTC) FILETIME=[322E89D0:01C95499] Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Hi all. I would even add that the diversely routing scenario is not different in = GMPLS from configuration-based provisioning: from the data plane point = of view, nothing is new. Regards, Julien -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On = Behalf Of Huub van Helvoort Hi Deborah, You replied: > Shouldn't be a problem if the data plane is based on ITU - so it would > need to support (at minimum) ITU's G.707 minimum differential delay > requirements for VCAT. Minimum delay in G.707 is 125 usec (micro-seconds)... Maximum differential delay depends on implementation. Differential is the difference between the largest propagation delay of one of the members and the smallest propagation delay of one of the members. The sink VCAT/LCAS function is capable of detecting and reporting whether one or more members does not fit the differential delay capability. Cheers, Huub. > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On >=20 > Dear Greg, > One additional problem with VCAT/LCAS is the amount of differential > delay > supported at the destination node. Can it be mentioned as a note that > co-routing or diversely routing is also based on the availability of > enough > sufficient differential delay buffer size at the destination node?=20 >=20 > Regards, > Jishnu A >=20 > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On > Behalf > Of Greg Bernstein > Sent: Wednesday, November 19, 2008 12:07 AM > To: ccamp > Subject: [BULK] VCAT/LCAS draft update... > Importance: Low >=20 > Hi folks, I edited the VCAT/LCAS draft to use the CALL_ATTRIBUTES = object >=20 > from the MLN extensions draft. > We define a new VCAT TLV for use in the aforementioned object. All=20 > procedures and encodings otherwise are the same as the previous draft. = > Note that the draft will now be contingent on the MLN extensions draft = > moving forward. >=20 > A URL for the Internet-Draft is: > = http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-vcat-lcas-06. > txt >=20 >=20 > Regards >=20 > Greg >=20 --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D http://www.van-helvoort.eu/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Always remember that you are unique...just like everyone else... From owner-ccamp@ops.ietf.org Tue Dec 2 08:25:41 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 945B23A696E for ; Tue, 2 Dec 2008 08:25:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.495 X-Spam-Level: X-Spam-Status: No, score=-4.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bovsorTB7ZEC for ; Tue, 2 Dec 2008 08:25:40 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B44AE3A6872 for ; Tue, 2 Dec 2008 08:25:40 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7Y1H-0006ZF-I1 for ccamp-data@psg.com; Tue, 02 Dec 2008 16:22:39 +0000 Received: from [47.129.242.57] (helo=zcars04f.nortel.com) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7Y19-0006XV-PM for ccamp@ops.ietf.org; Tue, 02 Dec 2008 16:22:35 +0000 Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id mB2GMOq27730; Tue, 2 Dec 2008 16:22:24 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: CCAMP drafts for adoption Date: Tue, 2 Dec 2008 11:22:20 -0500 Message-ID: <87AC5F88F03E6249AEA68D40BD3E00BE1683249C@zcarhxm2.corp.nortel.com> In-Reply-To: <2089B64D43144AEEA390F5C4C7232087@your029b8cecfe> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: CCAMP drafts for adoption Thread-Index: AclUmA/eD/0mh5J7SOi83MWHhH1JMwAAerzA References: <2089B64D43144AEEA390F5C4C7232087@your029b8cecfe> From: "David Allan" To: "Adrian Farrel" , Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Hi Adrian: Support oam-conf Support oam-ext Abstain wson-encode Cheers Dave=20 -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel Sent: Tuesday, December 02, 2008 11:02 AM To: ccamp@ops.ietf.org Subject: CCAMP drafts for adoption Hi, Can you please express your opinion on the adoption of the following three drafts as WG drafts. Thanks, Adrian draft-takacs-ccamp-oam-configuration-fwk-01.txt draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt draft-bernstein-ccamp-wson-encode-01.txt (to become -rwa-encode-00) Cheers, Adrian and Deborah=20 From owner-ccamp@ops.ietf.org Tue Dec 2 08:33:58 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B95863A6902 for ; Tue, 2 Dec 2008 08:33:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jRmZtOTW8+hF for ; Tue, 2 Dec 2008 08:33:57 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C58CF3A6825 for ; Tue, 2 Dec 2008 08:33:57 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7Y7O-0006yv-5p for ccamp-data@psg.com; Tue, 02 Dec 2008 16:28:58 +0000 Received: from [164.164.94.83] (helo=webmail.india.tejasnetworks.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7Y7I-0006yJ-CV for ccamp@ops.ietf.org; Tue, 02 Dec 2008 16:28:55 +0000 Received: from localhost (unknown [127.0.0.1]) by webmail.india.tejasnetworks.com (india.tejasnetworks.com) with ESMTP id 32B632619E5; Tue, 2 Dec 2008 21:58:35 +0530 (IST) X-Virus-Scanned: amavisd-new at india.tejasnetworks.com Received: from webmail.india.tejasnetworks.com ([127.0.0.1]) by localhost (anche.india.tejasnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v8vw1ddPwacW; Tue, 2 Dec 2008 21:58:31 +0530 (IST) Received: from Jishnu (unknown [192.168.0.10]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by webmail.india.tejasnetworks.com (india.tejasnetworks.com) with ESMTPSA id AA5422619E3; Tue, 2 Dec 2008 21:58:28 +0530 (IST) From: "Jishnu A" To: , "'BRUNGARD, DEBORAH A, ATTLABS'" Cc: "'Greg Bernstein'" , "'ccamp'" Subject: RE: [BULK] VCAT/LCAS draft update... Date: Tue, 2 Dec 2008 21:58:34 +0530 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AclUl5mR37OxKWhbQ0KerxW797yJpgAAwJYg In-Reply-To: <49355C72.2070407@chello.nl> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Adding to Hubb's reply below The MFI field in LCAS allows support upto a maximum of 256ms differential delay compensation for HO VC. But the exact value is completely depending on the vendor implementation and can be anything between 125us to 256ms. Regards, Jishnu A -----Original Message----- From: Huub van Helvoort [mailto:hhelvoort@chello.nl] Sent: Tuesday, December 02, 2008 9:34 PM To: BRUNGARD, DEBORAH A, ATTLABS Cc: Jishnu A; Greg Bernstein; ccamp Subject: Re: [BULK] VCAT/LCAS draft update... Importance: Low Hi Deborah, You replied: > Shouldn't be a problem if the data plane is based on ITU - so it would > need to support (at minimum) ITU's G.707 minimum differential delay > requirements for VCAT. Minimum delay in G.707 is 125 usec (micro-seconds)... Maximum differential delay depends on implementation. Differential is the difference between the largest propagation delay of one of the members and the smallest propagation delay of one of the members. The sink VCAT/LCAS function is capable of detecting and reporting whether one or more members does not fit the differential delay capability. Cheers, Huub. > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On > Behalf Of Jishnu A > Sent: Tuesday, December 02, 2008 10:03 AM > To: 'Greg Bernstein' > Cc: 'ccamp' > Subject: RE: [BULK] VCAT/LCAS draft update... > > Dear Greg, > One additional problem with VCAT/LCAS is the amount of differential > delay > supported at the destination node. Can it be mentioned as a note that > co-routing or diversely routing is also based on the availability of > enough > sufficient differential delay buffer size at the destination node? > > Regards, > Jishnu A > > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On > Behalf > Of Greg Bernstein > Sent: Wednesday, November 19, 2008 12:07 AM > To: ccamp > Subject: [BULK] VCAT/LCAS draft update... > Importance: Low > > Hi folks, I edited the VCAT/LCAS draft to use the CALL_ATTRIBUTES object > > from the MLN extensions draft. > We define a new VCAT TLV for use in the aforementioned object. All > procedures and encodings otherwise are the same as the previous draft. > Note that the draft will now be contingent on the MLN extensions draft > moving forward. > > A URL for the Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-vcat-lcas-06. > txt > > > Regards > > Greg > -- ================================================================ http://www.van-helvoort.eu/ ================================================================ Always remember that you are unique...just like everyone else... __________ Information from ESET NOD32 Antivirus, version of virus signature database 3658 (20081202) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __________ Information from ESET NOD32 Antivirus, version of virus signature database 3658 (20081202) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com From owner-ccamp@ops.ietf.org Tue Dec 2 08:39:29 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D0393A6B3D for ; Tue, 2 Dec 2008 08:39:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.633 X-Spam-Level: X-Spam-Status: No, score=-1.633 tagged_above=-999 required=5 tests=[AWL=-0.586, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oqXmdKQilQ7l for ; Tue, 2 Dec 2008 08:39:28 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3182D3A67D6 for ; Tue, 2 Dec 2008 08:39:28 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7YDv-0007QD-6E for ccamp-data@psg.com; Tue, 02 Dec 2008 16:35:43 +0000 Received: from [156.106.192.41] (helo=protext01.itu.ch) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7YDp-0007PU-6x for ccamp@ops.ietf.org; Tue, 02 Dec 2008 16:35:40 +0000 Received: from protext01.itu.ch ([156.106.192.41]) by protext01.itu.ch with Microsoft SMTPSVC(5.0.2195.6713); Tue, 2 Dec 2008 17:35:35 +0100 Received: From mail6.itu.ch ([156.106.192.22]) by protext01.itu.ch (WebShield SMTP v4.5 MR3) id 1228235734570; Tue, 2 Dec 2008 17:35:34 +0100 Received: from your029b8cecfe ([156.106.216.176]) by mail6.itu.ch (8.14.3/8.14.3) with ESMTP id mB2GZX2i375016 for ; Tue, 2 Dec 2008 17:35:34 +0100 (MET) Message-ID: <4E1CBFB4740C4D4FA530A1F84FE537D6@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "'ccamp'" References: Subject: Re: VCAT/LCAS draft update... Date: Tue, 2 Dec 2008 16:35:30 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (mail6.itu.ch [156.106.192.22]); Tue, 02 Dec 2008 17:35:34 +0100 (MET) X-OriginalArrivalTime: 02 Dec 2008 16:35:35.0367 (UTC) FILETIME=[00506570:01C9549C] Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Questions: Is this something that anyone would ever do without LCAS? Are there information elements we need to exchange before LSPs are set up (i.e. on the Call)? How much of this is dependent on measurements once LSPs are set up, rather than before they are set up? Thanks, Adrian ----- Original Message ----- From: "Jishnu A" To: ; "'BRUNGARD, DEBORAH A, ATTLABS'" Cc: "'Greg Bernstein'" ; "'ccamp'" Sent: Tuesday, December 02, 2008 4:28 PM Subject: RE: [BULK] VCAT/LCAS draft update... > Adding to Hubb's reply below > The MFI field in LCAS allows support upto a maximum of 256ms differential > delay compensation for HO VC. But the exact value is completely depending > on > the vendor implementation and can be anything between 125us to 256ms. > Regards, > Jishnu A > > -----Original Message----- > From: Huub van Helvoort [mailto:hhelvoort@chello.nl] > Sent: Tuesday, December 02, 2008 9:34 PM > To: BRUNGARD, DEBORAH A, ATTLABS > Cc: Jishnu A; Greg Bernstein; ccamp > Subject: Re: [BULK] VCAT/LCAS draft update... > Importance: Low > > Hi Deborah, > > You replied: > >> Shouldn't be a problem if the data plane is based on ITU - so it would >> need to support (at minimum) ITU's G.707 minimum differential delay >> requirements for VCAT. > > Minimum delay in G.707 is 125 usec (micro-seconds)... > > Maximum differential delay depends on implementation. > Differential is the difference between the largest > propagation delay of one of the members and the > smallest propagation delay of one of the members. > The sink VCAT/LCAS function is capable of detecting > and reporting whether one or more members does not fit > the differential delay capability. > > Cheers, Huub. > >> -----Original Message----- >> From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On >> Behalf Of Jishnu A >> Sent: Tuesday, December 02, 2008 10:03 AM >> To: 'Greg Bernstein' >> Cc: 'ccamp' >> Subject: RE: [BULK] VCAT/LCAS draft update... >> >> Dear Greg, >> One additional problem with VCAT/LCAS is the amount of differential >> delay >> supported at the destination node. Can it be mentioned as a note that >> co-routing or diversely routing is also based on the availability of >> enough >> sufficient differential delay buffer size at the destination node? >> >> Regards, >> Jishnu A >> >> -----Original Message----- >> From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On >> Behalf >> Of Greg Bernstein >> Sent: Wednesday, November 19, 2008 12:07 AM >> To: ccamp >> Subject: [BULK] VCAT/LCAS draft update... >> Importance: Low >> >> Hi folks, I edited the VCAT/LCAS draft to use the CALL_ATTRIBUTES object >> >> from the MLN extensions draft. >> We define a new VCAT TLV for use in the aforementioned object. All >> procedures and encodings otherwise are the same as the previous draft. >> Note that the draft will now be contingent on the MLN extensions draft >> moving forward. >> >> A URL for the Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-vcat-lcas-06. >> txt >> >> >> Regards >> >> Greg >> > > -- > ================================================================ > http://www.van-helvoort.eu/ > ================================================================ > Always remember that you are unique...just like everyone else... > > > __________ Information from ESET NOD32 Antivirus, version of virus > signature > database 3658 (20081202) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > > > > __________ Information from ESET NOD32 Antivirus, version of virus > signature > database 3658 (20081202) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > > > From owner-ccamp@ops.ietf.org Tue Dec 2 08:43:55 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6298628C155 for ; Tue, 2 Dec 2008 08:43:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.961 X-Spam-Level: X-Spam-Status: No, score=0.961 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_DK=1.009, HELO_MISMATCH_DK=1.7, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pr4rvQs2H23g for ; Tue, 2 Dec 2008 08:43:54 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 97EC73A6B8A for ; Tue, 2 Dec 2008 08:43:54 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7YHY-0007gw-8P for ccamp-data@psg.com; Tue, 02 Dec 2008 16:39:28 +0000 Received: from [213.150.41.59] (helo=dkcphmx22.softcom.dk) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7YHR-0007gD-9b for ccamp@ops.ietf.org; Tue, 02 Dec 2008 16:39:23 +0000 Received: (qmail 1927 invoked by uid 74); 2 Dec 2008 16:39:19 -0000 Received: from mail.acreo.se (217.151.195.216) by dkcphmx22.softcom.dk (envelope-from ) with ESMTP. tag msg.1228235959.508426.10883 (Processed in 0.111655 secs); 02 Dec 2008 16:39:19 -0000 X-SoftScan-Status: clean X-Secure-TLS: Yes, message received through TLS by dkcphmx22.softcom.dk (RC4-MD5) Received: from mail.acreo.se (HELO mail.acreo.se) (217.151.195.216) by dkcphmx22.softcom.dk over TLS secured channel with (RC4-MD5 encrypted) ESMTPS; Tue, 02 Dec 2008 17:39:19 +0100 Received: from acreoexc01.ad.acreo.se ([10.4.148.12]) by acreoexc01.ad.acreo.se ([10.4.148.12]) with mapi; Tue, 2 Dec 2008 17:39:19 +0100 From: =?iso-8859-1?Q?Jonas_M=E5rtensson?= To: Adrian Farrel , "ccamp@ops.ietf.org" Date: Tue, 2 Dec 2008 17:39:17 +0100 Subject: RE: CCAMP drafts for adoption Thread-Topic: CCAMP drafts for adoption Thread-Index: AclUmEwhRI0kNFCISLuCBtlvS1LnPgABAVmw Message-ID: <1EC35EEAF3A9FA439C7D6AE45BF43787DB083005A8@acreoexc01.ad.acreo.se> References: <2089B64D43144AEEA390F5C4C7232087@your029b8cecfe> In-Reply-To: <2089B64D43144AEEA390F5C4C7232087@your029b8cecfe> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Hi, I support wson-encode. Regards, Jonas > -----Original Message----- > From: owner-ccamp@ops.ietf.org > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel > Sent: den 2 december 2008 17:02 > To: ccamp@ops.ietf.org > Subject: CCAMP drafts for adoption > > Hi, > > Can you please express your opinion on the adoption of the > following three drafts as WG drafts. > > Thanks, > Adrian > > draft-takacs-ccamp-oam-configuration-fwk-01.txt > draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt > draft-bernstein-ccamp-wson-encode-01.txt (to become -rwa-encode-00) > > Cheers, > Adrian and Deborah > > > > > > From owner-ccamp@ops.ietf.org Tue Dec 2 08:48:49 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FB6C3A6B8A for ; Tue, 2 Dec 2008 08:48:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.698 X-Spam-Level: X-Spam-Status: No, score=-4.698 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vjgLODAkjm5F for ; Tue, 2 Dec 2008 08:48:48 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id ABFDE3A6B16 for ; Tue, 2 Dec 2008 08:48:48 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7YNf-0008FI-2N for ccamp-data@psg.com; Tue, 02 Dec 2008 16:45:47 +0000 Received: from [193.180.251.60] (helo=mailgw3.ericsson.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7YNZ-0008Eq-8p for ccamp@ops.ietf.org; Tue, 02 Dec 2008 16:45:43 +0000 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 6286D20ABD; Tue, 2 Dec 2008 17:45:39 +0100 (CET) X-AuditID: c1b4fb3c-aff62bb00000304c-d4-493566338c81 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 5236A2061F; Tue, 2 Dec 2008 17:45:39 +0100 (CET) Received: from esealmw110.eemea.ericsson.se ([153.88.200.78]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Dec 2008 17:45:38 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 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: CCAMP drafts for adoption Date: Tue, 2 Dec 2008 17:44:17 +0100 Message-ID: <0428AC48A879ED46A94F39D5665DF684021E0C2E@esealmw110.eemea.ericsson.se> In-Reply-To: <2089B64D43144AEEA390F5C4C7232087@your029b8cecfe> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: CCAMP drafts for adoption Thread-Index: AclUl89qKcq7JtMySGqkaJgwx7j8RwABWK5w References: <2089B64D43144AEEA390F5C4C7232087@your029b8cecfe> From: "Diego Caviglia" To: "Adrian Farrel" , X-OriginalArrivalTime: 02 Dec 2008 16:45:38.0624 (UTC) FILETIME=[67E21C00:01C9549D] X-Brightmail-Tracker: AAAAAA== Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Yes to all. BR Diego > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On = Behalf > Of Adrian Farrel > Sent: marted=EC 2 dicembre 2008 17.02 > To: ccamp@ops.ietf.org > Subject: CCAMP drafts for adoption >=20 > Hi, >=20 > Can you please express your opinion on the adoption of the following = three > drafts as WG drafts. >=20 > Thanks, > Adrian >=20 > draft-takacs-ccamp-oam-configuration-fwk-01.txt > draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt > draft-bernstein-ccamp-wson-encode-01.txt (to become -rwa-encode-00) >=20 > Cheers, > Adrian and Deborah >=20 >=20 From owner-ccamp@ops.ietf.org Tue Dec 2 08:52:14 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32AE23A67D6 for ; Tue, 2 Dec 2008 08:52:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.547 X-Spam-Level: X-Spam-Status: No, score=-5.547 tagged_above=-999 required=5 tests=[AWL=-1.052, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dNtTNOdnd1y3 for ; Tue, 2 Dec 2008 08:52:13 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 265D73A6B7A for ; Tue, 2 Dec 2008 08:51:02 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7YPh-0008Nq-9e for ccamp-data@psg.com; Tue, 02 Dec 2008 16:47:53 +0000 Received: from [198.24.6.3] (helo=imr2.ericy.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7YPc-0008NK-FM for ccamp@ops.ietf.org; Tue, 02 Dec 2008 16:47:50 +0000 Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id mB2Glg9i032156; Tue, 2 Dec 2008 10:47:42 -0600 Received: from EUSRCMW722.eamcs.ericsson.se ([138.85.77.22]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Dec 2008 10:47:41 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: CCAMP drafts for adoption Date: Tue, 2 Dec 2008 10:47:41 -0600 Message-ID: In-Reply-To: <2089B64D43144AEEA390F5C4C7232087@your029b8cecfe> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: CCAMP drafts for adoption Thread-Index: AclUl9x1bFCf9+tlQ5yJ7vl0/FoH+wABXFFA References: <2089B64D43144AEEA390F5C4C7232087@your029b8cecfe> From: "Howard Green" To: "Adrian Farrel" , X-OriginalArrivalTime: 02 Dec 2008 16:47:42.0040 (UTC) FILETIME=[B171E580:01C9549D] Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Yes to all three. Howard -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel Sent: Tuesday, December 02, 2008 8:02 AM To: ccamp@ops.ietf.org Subject: CCAMP drafts for adoption Hi, Can you please express your opinion on the adoption of the following three drafts as WG drafts. Thanks, Adrian draft-takacs-ccamp-oam-configuration-fwk-01.txt draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt draft-bernstein-ccamp-wson-encode-01.txt (to become -rwa-encode-00) Cheers, Adrian and Deborah=20 From owner-ccamp@ops.ietf.org Tue Dec 2 08:55:42 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D82B3A67D0 for ; Tue, 2 Dec 2008 08:55:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ResaqSNo958K for ; Tue, 2 Dec 2008 08:55:41 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 77C733A6774 for ; Tue, 2 Dec 2008 08:55:41 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7YU0-0008gK-9F for ccamp-data@psg.com; Tue, 02 Dec 2008 16:52:20 +0000 Received: from [66.226.64.47] (helo=pro46.abac.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7YTt-0008fl-7v for ccamp@ops.ietf.org; Tue, 02 Dec 2008 16:52:15 +0000 Received: from [192.168.0.131] (c-71-202-41-42.hsd1.ca.comcast.net [71.202.41.42]) (authenticated bits=0) by pro46.abac.com (8.14.3/8.14.3) with ESMTP id mB2GpboF040815 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Dec 2008 08:51:40 -0800 (PST) (envelope-from gregb@grotto-networking.com) Message-ID: <4935679C.1030201@grotto-networking.com> Date: Tue, 02 Dec 2008 08:51:40 -0800 From: Greg Bernstein User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Adrian Farrel CC: ccamp@ops.ietf.org Subject: Re: CCAMP drafts for adoption References: <2089B64D43144AEEA390F5C4C7232087@your029b8cecfe> In-Reply-To: <2089B64D43144AEEA390F5C4C7232087@your029b8cecfe> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Support wson-encode. Yes, I'm a co-author... Greg Adrian Farrel wrote: > Hi, > > Can you please express your opinion on the adoption of the following > three drafts as WG drafts. > > Thanks, > Adrian > > draft-takacs-ccamp-oam-configuration-fwk-01.txt > draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt > draft-bernstein-ccamp-wson-encode-01.txt (to become -rwa-encode-00) > > Cheers, > Adrian and Deborah > > > -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 From morgan@alienskin.co.uk Tue Dec 2 09:00:48 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2307328C13B for ; Tue, 2 Dec 2008 09:00:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -45.083 X-Spam-Level: X-Spam-Status: No, score=-45.083 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RDNS_NONE=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mdcLXUql+LLY for ; Tue, 2 Dec 2008 09:00:47 -0800 (PST) Received: from ameristarcasinos.com (unknown [212.25.53.53]) by core3.amsl.com (Postfix) with SMTP id 4E8BE3A67D0 for ; Tue, 2 Dec 2008 09:00:45 -0800 (PST) To: Subject: Your order From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081202170046.4E8BE3A67D0@core3.amsl.com> Date: Tue, 2 Dec 2008 09:00:45 -0800 (PST) Click here to view as a webpage. From owner-ccamp@ops.ietf.org Tue Dec 2 09:02:04 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E021C3A67D6 for ; Tue, 2 Dec 2008 09:02:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uklk48iILZbz for ; Tue, 2 Dec 2008 09:02:04 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 26C373A67D0 for ; Tue, 2 Dec 2008 09:02:04 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7YZy-0009GS-Rp for ccamp-data@psg.com; Tue, 02 Dec 2008 16:58:30 +0000 Received: from [206.16.17.70] (helo=usaga02-in.huawei.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7YZu-0009Fz-Kb for ccamp@ops.ietf.org; Tue, 02 Dec 2008 16:58:28 +0000 Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KB900C3KDTBBS@usaga02-in.huawei.com> for ccamp@ops.ietf.org; Tue, 02 Dec 2008 08:58:23 -0800 (PST) Received: from L73682 ([10.124.12.74]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KB900HBDDT36O@usaga02-in.huawei.com> for ccamp@ops.ietf.org; Tue, 02 Dec 2008 08:58:22 -0800 (PST) Date: Tue, 02 Dec 2008 10:58:15 -0600 From: Young Lee Subject: RE: CCAMP drafts for adoption In-reply-to: <2089B64D43144AEEA390F5C4C7232087@your029b8cecfe> To: 'Adrian Farrel' , ccamp@ops.ietf.org Message-id: <001201c9549f$2dac4e50$d626fea9@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Thread-index: AclUl6mpWAW2o7P/QfKhDBZKhoe9CgABkY3A References: <2089B64D43144AEEA390F5C4C7232087@your029b8cecfe> Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Support for all. Young (I'm co-author of wson-encode) -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel Sent: Tuesday, December 02, 2008 10:02 AM To: ccamp@ops.ietf.org Subject: CCAMP drafts for adoption Hi, Can you please express your opinion on the adoption of the following three drafts as WG drafts. Thanks, Adrian draft-takacs-ccamp-oam-configuration-fwk-01.txt draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt draft-bernstein-ccamp-wson-encode-01.txt (to become -rwa-encode-00) Cheers, Adrian and Deborah From owner-ccamp@ops.ietf.org Tue Dec 2 09:37:23 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1711628C1A4 for ; Tue, 2 Dec 2008 09:37:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.565 X-Spam-Level: X-Spam-Status: No, score=-1.565 tagged_above=-999 required=5 tests=[AWL=-0.517, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TDK53Q9Rg-qm for ; Tue, 2 Dec 2008 09:37:22 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E9D6128C1BA for ; Tue, 2 Dec 2008 09:37:21 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7Z6i-000BkP-Dv for ccamp-data@psg.com; Tue, 02 Dec 2008 17:32:20 +0000 Received: from [156.106.192.41] (helo=protext01.itu.ch) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7Z6c-000Bjk-O1 for ccamp@ops.ietf.org; Tue, 02 Dec 2008 17:32:16 +0000 Received: from protext01.itu.ch ([156.106.192.41]) by protext01.itu.ch with Microsoft SMTPSVC(5.0.2195.6713); Tue, 2 Dec 2008 18:32:13 +0100 Received: From mail6.itu.ch ([156.106.192.22]) by protext01.itu.ch (WebShield SMTP v4.5 MR3) id 1228239132367; Tue, 2 Dec 2008 18:32:12 +0100 Received: from n172005.ep.ad.eplus.de ([156.106.216.152]) by mail6.itu.ch (8.14.3/8.14.3) with ESMTP id mB2HW8l6375771; Tue, 2 Dec 2008 18:32:10 +0100 (MET) Message-ID: <49357118.7020709@chello.nl> Date: Tue, 02 Dec 2008 18:32:08 +0100 From: Huub van Helvoort Reply-To: hhelvoort@chello.nl User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: Jishnu A CC: "'Greg Bernstein'" , "'ccamp'" Subject: Re: [BULK] VCAT/LCAS draft update... References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (mail6.itu.ch [156.106.192.22]); Tue, 02 Dec 2008 18:32:12 +0100 (MET) X-OriginalArrivalTime: 02 Dec 2008 17:32:13.0117 (UTC) FILETIME=[E987E6D0:01C954A3] Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Hi Jishnu, you replied: > Adding to Hubb's reply below > The MFI field in LCAS allows support upto a maximum of 256ms differential > delay compensation for HO VC. But the exact value is completely depending on > the vendor implementation and can be anything between 125us to 256ms. This is information that is well known. Reading your initial email again I am confused by the additional reponse. Can you please inform us of what the issue is that you would like to resolve. And make a distinction between the two modes: == VCAT without LCAS == VCAT with LCAS. Thank you, Huub. > -----Original Message----- > From: Huub van Helvoort [mailto:hhelvoort@chello.nl] > Sent: Tuesday, December 02, 2008 9:34 PM > To: BRUNGARD, DEBORAH A, ATTLABS > Cc: Jishnu A; Greg Bernstein; ccamp > Subject: Re: [BULK] VCAT/LCAS draft update... > Importance: Low > > Hi Deborah, > > You replied: > >> Shouldn't be a problem if the data plane is based on ITU - so it would >> need to support (at minimum) ITU's G.707 minimum differential delay >> requirements for VCAT. > > Minimum delay in G.707 is 125 usec (micro-seconds)... > > Maximum differential delay depends on implementation. > Differential is the difference between the largest > propagation delay of one of the members and the > smallest propagation delay of one of the members. > The sink VCAT/LCAS function is capable of detecting > and reporting whether one or more members does not fit > the differential delay capability. > > Cheers, Huub. > >> -----Original Message----- >> From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On >> Behalf Of Jishnu A >> Sent: Tuesday, December 02, 2008 10:03 AM >> To: 'Greg Bernstein' >> Cc: 'ccamp' >> Subject: RE: [BULK] VCAT/LCAS draft update... >> >> Dear Greg, >> One additional problem with VCAT/LCAS is the amount of differential >> delay >> supported at the destination node. Can it be mentioned as a note that >> co-routing or diversely routing is also based on the availability of >> enough >> sufficient differential delay buffer size at the destination node? >> >> Regards, >> Jishnu A >> >> -----Original Message----- >> From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On >> Behalf >> Of Greg Bernstein >> Sent: Wednesday, November 19, 2008 12:07 AM >> To: ccamp >> Subject: [BULK] VCAT/LCAS draft update... >> Importance: Low >> >> Hi folks, I edited the VCAT/LCAS draft to use the CALL_ATTRIBUTES object >> >> from the MLN extensions draft. >> We define a new VCAT TLV for use in the aforementioned object. All >> procedures and encodings otherwise are the same as the previous draft. >> Note that the draft will now be contingent on the MLN extensions draft >> moving forward. >> >> A URL for the Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-vcat-lcas-06. >> txt >> >> >> Regards >> >> Greg >> > -- ================================================================ http://www.van-helvoort.eu/ ================================================================ Always remember that you are unique...just like everyone else... From owner-ccamp@ops.ietf.org Tue Dec 2 10:41:55 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAFA63A6A0A for ; Tue, 2 Dec 2008 10:41:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T4ULWOHqmKGt for ; Tue, 2 Dec 2008 10:41:55 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 987B43A692B for ; Tue, 2 Dec 2008 10:41:54 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7a7V-000GP8-5P for ccamp-data@psg.com; Tue, 02 Dec 2008 18:37:13 +0000 Received: from [164.164.94.83] (helo=webmail.india.tejasnetworks.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7a7P-000GOa-9F for ccamp@ops.ietf.org; Tue, 02 Dec 2008 18:37:10 +0000 Received: from localhost (unknown [127.0.0.1]) by webmail.india.tejasnetworks.com (india.tejasnetworks.com) with ESMTP id 17B302619E5; Wed, 3 Dec 2008 00:06:50 +0530 (IST) X-Virus-Scanned: amavisd-new at india.tejasnetworks.com Received: from webmail.india.tejasnetworks.com ([127.0.0.1]) by localhost (anche.india.tejasnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BnqSyogtrrb8; Wed, 3 Dec 2008 00:06:45 +0530 (IST) Received: from Jishnu (unknown [192.168.0.10]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by webmail.india.tejasnetworks.com (india.tejasnetworks.com) with ESMTPSA id 11F6F2619E3; Wed, 3 Dec 2008 00:06:42 +0530 (IST) From: "Jishnu A" To: Cc: "'Greg Bernstein'" , "'ccamp'" Subject: RE: [BULK] VCAT/LCAS draft update... Date: Wed, 3 Dec 2008 00:06:48 +0530 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <49357118.7020709@chello.nl> Thread-index: AclUo+XiR/6yjP3UQMm+L1afQAP0JQAB0LKg Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Dear Hubb, As there is a note on Fixed co-routed about this being needed to minimize the differential delay, same could be added for Dynamic, co-routed also. "Dynamic, co-routed: A dynamic VCG (bandwidth can be increased or decreased via the addition or removal of member signals), transported over a co-routed set of members. The intent here is dynamic resizing and resilience of bandwidth at the same time minimizing the differential delay." Is it left out as it is obvious? Also the document does not mention why one needs to minimize the differential delay. Again, is it assumed that this is well known and left out? Regards, Jishnu A -----Original Message----- From: Huub van Helvoort [mailto:hhelvoort@chello.nl] Sent: Tuesday, December 02, 2008 11:02 PM To: Jishnu A Cc: 'Greg Bernstein'; 'ccamp' Subject: Re: [BULK] VCAT/LCAS draft update... Importance: Low Hi Jishnu, you replied: > Adding to Hubb's reply below > The MFI field in LCAS allows support upto a maximum of 256ms differential > delay compensation for HO VC. But the exact value is completely depending on > the vendor implementation and can be anything between 125us to 256ms. This is information that is well known. Reading your initial email again I am confused by the additional reponse. Can you please inform us of what the issue is that you would like to resolve. And make a distinction between the two modes: == VCAT without LCAS == VCAT with LCAS. Thank you, Huub. > -----Original Message----- > From: Huub van Helvoort [mailto:hhelvoort@chello.nl] > Sent: Tuesday, December 02, 2008 9:34 PM > To: BRUNGARD, DEBORAH A, ATTLABS > Cc: Jishnu A; Greg Bernstein; ccamp > Subject: Re: [BULK] VCAT/LCAS draft update... > Importance: Low > > Hi Deborah, > > You replied: > >> Shouldn't be a problem if the data plane is based on ITU - so it would >> need to support (at minimum) ITU's G.707 minimum differential delay >> requirements for VCAT. > > Minimum delay in G.707 is 125 usec (micro-seconds)... > > Maximum differential delay depends on implementation. > Differential is the difference between the largest > propagation delay of one of the members and the > smallest propagation delay of one of the members. > The sink VCAT/LCAS function is capable of detecting > and reporting whether one or more members does not fit > the differential delay capability. > > Cheers, Huub. > >> -----Original Message----- >> From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On >> Behalf Of Jishnu A >> Sent: Tuesday, December 02, 2008 10:03 AM >> To: 'Greg Bernstein' >> Cc: 'ccamp' >> Subject: RE: [BULK] VCAT/LCAS draft update... >> >> Dear Greg, >> One additional problem with VCAT/LCAS is the amount of differential >> delay >> supported at the destination node. Can it be mentioned as a note that >> co-routing or diversely routing is also based on the availability of >> enough >> sufficient differential delay buffer size at the destination node? >> >> Regards, >> Jishnu A >> >> -----Original Message----- >> From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On >> Behalf >> Of Greg Bernstein >> Sent: Wednesday, November 19, 2008 12:07 AM >> To: ccamp >> Subject: [BULK] VCAT/LCAS draft update... >> Importance: Low >> >> Hi folks, I edited the VCAT/LCAS draft to use the CALL_ATTRIBUTES object >> >> from the MLN extensions draft. >> We define a new VCAT TLV for use in the aforementioned object. All >> procedures and encodings otherwise are the same as the previous draft. >> Note that the draft will now be contingent on the MLN extensions draft >> moving forward. >> >> A URL for the Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-vcat-lcas-06. >> txt >> >> >> Regards >> >> Greg >> > -- ================================================================ http://www.van-helvoort.eu/ ================================================================ Always remember that you are unique...just like everyone else... __________ Information from ESET NOD32 Antivirus, version of virus signature database 3658 (20081202) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __________ Information from ESET NOD32 Antivirus, version of virus signature database 3658 (20081202) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com From owner-ccamp@ops.ietf.org Tue Dec 2 10:44:46 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 038B53A6B57 for ; Tue, 2 Dec 2008 10:44:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZhW-iWLRYfhN for ; Tue, 2 Dec 2008 10:44:45 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 066323A6B51 for ; Tue, 2 Dec 2008 10:44:45 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7aBf-000GeC-RY for ccamp-data@psg.com; Tue, 02 Dec 2008 18:41:31 +0000 Received: from [66.226.64.47] (helo=pro46.abac.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7aBa-000Gdf-E1 for ccamp@ops.ietf.org; Tue, 02 Dec 2008 18:41:28 +0000 Received: from [192.168.0.131] (c-71-202-41-42.hsd1.ca.comcast.net [71.202.41.42]) (authenticated bits=0) by pro46.abac.com (8.14.3/8.14.3) with ESMTP id mB2IfHVa090012 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Dec 2008 10:41:19 -0800 (PST) (envelope-from gregb@grotto-networking.com) Message-ID: <4935814F.4060705@grotto-networking.com> Date: Tue, 02 Dec 2008 10:41:19 -0800 From: Greg Bernstein User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: hhelvoort@chello.nl CC: Jishnu A , "'ccamp'" Subject: Re: [BULK] VCAT/LCAS draft update... References: <49357118.7020709@chello.nl> In-Reply-To: <49357118.7020709@chello.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Hi folks, the differential delay compensation capability is a property of VCAT (not LCAS) hence independent of whether LCAS is implemented or not. In SDH the MFI is used with VCAT (part of the H4 byte). This issue has come up before. And at the time it seemed to belong with some the MLN work that kept track of "adaptation" properties. Right now it seems that differential delay compensation limits would need to be handled by network planning rather than the control plane. Regards Greg Huub van Helvoort wrote: > Hi Jishnu, > > you replied: > >> Adding to Hubb's reply below >> The MFI field in LCAS allows support upto a maximum of 256ms >> differential >> delay compensation for HO VC. But the exact value is completely >> depending on >> the vendor implementation and can be anything between 125us to 256ms. > > This is information that is well known. > > Reading your initial email again I am confused by the > additional reponse. > > Can you please inform us of what the issue is that you > would like to resolve. > And make a distinction between the two modes: > == VCAT without LCAS > == VCAT with LCAS. > > Thank you, Huub. > >> -----Original Message----- >> From: Huub van Helvoort [mailto:hhelvoort@chello.nl] Sent: Tuesday, >> December 02, 2008 9:34 PM >> To: BRUNGARD, DEBORAH A, ATTLABS >> Cc: Jishnu A; Greg Bernstein; ccamp >> Subject: Re: [BULK] VCAT/LCAS draft update... >> Importance: Low >> >> Hi Deborah, >> >> You replied: >> >>> Shouldn't be a problem if the data plane is based on ITU - so it would >>> need to support (at minimum) ITU's G.707 minimum differential delay >>> requirements for VCAT. >> >> Minimum delay in G.707 is 125 usec (micro-seconds)... >> >> Maximum differential delay depends on implementation. >> Differential is the difference between the largest >> propagation delay of one of the members and the >> smallest propagation delay of one of the members. >> The sink VCAT/LCAS function is capable of detecting >> and reporting whether one or more members does not fit >> the differential delay capability. >> >> Cheers, Huub. >> >>> -----Original Message----- >>> From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On >>> Behalf Of Jishnu A >>> Sent: Tuesday, December 02, 2008 10:03 AM >>> To: 'Greg Bernstein' >>> Cc: 'ccamp' >>> Subject: RE: [BULK] VCAT/LCAS draft update... >>> >>> Dear Greg, >>> One additional problem with VCAT/LCAS is the amount of differential >>> delay >>> supported at the destination node. Can it be mentioned as a note that >>> co-routing or diversely routing is also based on the availability of >>> enough >>> sufficient differential delay buffer size at the destination node? >>> Regards, >>> Jishnu A >>> >>> -----Original Message----- >>> From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On >>> Behalf >>> Of Greg Bernstein >>> Sent: Wednesday, November 19, 2008 12:07 AM >>> To: ccamp >>> Subject: [BULK] VCAT/LCAS draft update... >>> Importance: Low >>> >>> Hi folks, I edited the VCAT/LCAS draft to use the CALL_ATTRIBUTES >>> object >>> >>> from the MLN extensions draft. >>> We define a new VCAT TLV for use in the aforementioned object. All >>> procedures and encodings otherwise are the same as the previous >>> draft. Note that the draft will now be contingent on the MLN >>> extensions draft moving forward. >>> >>> A URL for the Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-vcat-lcas-06. >>> >>> txt >>> >>> >>> Regards >>> >>> Greg >>> >> > -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 From owner-ccamp@ops.ietf.org Tue Dec 2 13:04:43 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6259E28C1C7 for ; Tue, 2 Dec 2008 13:04:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YMcHfa0oSYiP for ; Tue, 2 Dec 2008 13:04:42 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8C5BE3A6BD5 for ; Tue, 2 Dec 2008 13:04:42 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7cKz-000PjF-AG for ccamp-data@psg.com; Tue, 02 Dec 2008 20:59:17 +0000 Received: from [206.16.17.180] (helo=usaga04-in.huawei.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7cKu-000Piv-VY for ccamp@ops.ietf.org; Tue, 02 Dec 2008 20:59:14 +0000 Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KB90072BOYN9S@usaga04-in.huawei.com> for ccamp@ops.ietf.org; Tue, 02 Dec 2008 14:59:12 -0600 (CST) Received: from Y73674 ([10.124.12.71]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KB9000P8OYJVF@usaga04-in.huawei.com> for ccamp@ops.ietf.org; Tue, 02 Dec 2008 14:59:11 -0600 (CST) Date: Tue, 02 Dec 2008 14:59:07 -0600 From: Lucy Yong Subject: RE: CCAMP drafts for adoption In-reply-to: <001201c9549f$2dac4e50$d626fea9@china.huawei.com> To: ccamp@ops.ietf.org Message-id: <001601c954c0$d165bf10$470c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AclUl6mpWAW2o7P/QfKhDBZKhoe9CgABkY3AAAiyQSA= References: <2089B64D43144AEEA390F5C4C7232087@your029b8cecfe> <001201c9549f$2dac4e50$d626fea9@china.huawei.com> Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Support all to become WG documents. Cheer, Lucy > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf > Of Young Lee > Sent: Tuesday, December 02, 2008 10:58 AM > To: 'Adrian Farrel'; ccamp@ops.ietf.org > Subject: RE: CCAMP drafts for adoption > > Support for all. > > Young (I'm co-author of wson-encode) > > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf > Of Adrian Farrel > Sent: Tuesday, December 02, 2008 10:02 AM > To: ccamp@ops.ietf.org > Subject: CCAMP drafts for adoption > > Hi, > > Can you please express your opinion on the adoption of the following three > drafts as WG drafts. > > Thanks, > Adrian > > draft-takacs-ccamp-oam-configuration-fwk-01.txt > draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt > draft-bernstein-ccamp-wson-encode-01.txt (to become -rwa-encode-00) > > Cheers, > Adrian and Deborah > > > > > From owner-ccamp@ops.ietf.org Tue Dec 2 13:42:18 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E04D3A6C1F for ; Tue, 2 Dec 2008 13:42:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.547 X-Spam-Level: X-Spam-Status: No, score=-5.547 tagged_above=-999 required=5 tests=[AWL=-1.052, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HGCQ9Q1dQOu5 for ; Tue, 2 Dec 2008 13:42:17 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4AA793A6C1E for ; Tue, 2 Dec 2008 13:42:17 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7cwD-00023r-9u for ccamp-data@psg.com; Tue, 02 Dec 2008 21:37:45 +0000 Received: from [64.18.2.159] (helo=exprod7og103.obsmtp.com) by psg.com with smtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7cw8-00023V-2j for ccamp@ops.ietf.org; Tue, 02 Dec 2008 21:37:41 +0000 Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKSTWqocWLvuMtI7jq9TrwQmHx0usqEp/O@postini.com; Tue, 02 Dec 2008 13:37:40 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.71) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.311.2; Tue, 2 Dec 2008 13:35:20 -0800 Received: from emailcorp3.jnpr.net ([66.129.254.13]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Dec 2008 13:35:20 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: CCAMP drafts for adoption Date: Tue, 2 Dec 2008 13:35:19 -0800 Message-ID: <7FA0C743C38E5340BFC2873488FA1E8E025DDF5E@emailcorp3.jnpr.net> In-Reply-To: <001601c954c0$d165bf10$470c7c0a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: CCAMP drafts for adoption thread-index: AclUl6mpWAW2o7P/QfKhDBZKhoe9CgABkY3AAAiyQSAAAP4GoA== References: <001201c9549f$2dac4e50$d626fea9@china.huawei.com> <001601c954c0$d165bf10$470c7c0a@china.huawei.com> From: Nitin Bahadur To: "Adrian Farrel" , X-OriginalArrivalTime: 02 Dec 2008 21:35:20.0321 (UTC) FILETIME=[E02E9710:01C954C5] Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: > > draft-takacs-ccamp-oam-configuration-fwk-01.txt > > draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt Do not support either of these. >From the oam-config-fwk draft: > A new useful application of RSVP-TE is OAM configuration > and control for transport networks. LSP-ping was designed as an OAM mechansim for MPLS LSPs. Why do we need another mechanism? What are the limitations of lsp-ping that warrant this new mechanism? > When RSVP-TE is used for LSP establishment it is desirable to bind > OAM setup to connection establishment signalling to avoid two > separate management/configuration steps draft-ietf-bfd-mpls specifies how to use LSP-Ping for automatic setup of BFD-based OAM. We should go along the same path for Ethernet OAM. Thanks Nitin From owner-ccamp@ops.ietf.org Tue Dec 2 13:52:06 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AAA03A6B41 for ; Tue, 2 Dec 2008 13:52:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.491 X-Spam-Level: X-Spam-Status: No, score=-5.491 tagged_above=-999 required=5 tests=[AWL=-0.996, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GR4nbN1VxCYK for ; Tue, 2 Dec 2008 13:52:05 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9C3583A6C1D for ; Tue, 2 Dec 2008 13:52:05 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7d74-0002ju-Ff for ccamp-data@psg.com; Tue, 02 Dec 2008 21:48:58 +0000 Received: from [64.18.2.157] (helo=exprod7og102.obsmtp.com) by psg.com with smtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7d6z-0002jO-Jh for ccamp@ops.ietf.org; Tue, 02 Dec 2008 21:48:55 +0000 Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKSTWtQCwP0+Yu3KFczgLQN+J3bfJp7gmM@postini.com; Tue, 02 Dec 2008 13:48:53 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.311.2; Tue, 2 Dec 2008 13:45:53 -0800 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Dec 2008 13:45:52 -0800 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Dec 2008 13:45:52 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Dec 2008 13:45:51 -0800 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id mB2LjpM29157; Tue, 2 Dec 2008 13:45:51 -0800 (PST) (envelope-from yakov@juniper.net) Message-ID: <200812022145.mB2LjpM29157@magenta.juniper.net> To: "Adrian Farrel" CC: ccamp@ops.ietf.org Subject: Re: CCAMP drafts for adoption MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <67307.1228254351.1@juniper.net> Date: Tue, 2 Dec 2008 13:45:51 -0800 From: Yakov Rekhter X-OriginalArrivalTime: 02 Dec 2008 21:45:51.0657 (UTC) FILETIME=[587CD190:01C954C7] Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Adrian, > Hi, > > Can you please express your opinion on the adoption of the following > three drafts as WG drafts. > > Thanks, > Adrian > > draft-takacs-ccamp-oam-configuration-fwk-01.txt > draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt I am opposed accepting these drafts as WG drafts. Yakov. From owner-ccamp@ops.ietf.org Tue Dec 2 13:52:30 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 949423A6B58 for ; Tue, 2 Dec 2008 13:52:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.572 X-Spam-Level: X-Spam-Status: No, score=0.572 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_LOW=-1, RCVD_NUMERIC_HELO=2.067, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ev-Ja5PJRWQL for ; Tue, 2 Dec 2008 13:52:30 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C47163A6B42 for ; Tue, 2 Dec 2008 13:52:29 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7d7c-0002lZ-0q for ccamp-data@psg.com; Tue, 02 Dec 2008 21:49:32 +0000 Received: from [217.32.164.138] (helo=smtp3.smtp.bt.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7d7R-0002kX-Mv for ccamp@ops.ietf.org; Tue, 02 Dec 2008 21:49:28 +0000 Received: from E03MVA4-UKBR.domain1.systemhost.net ([193.113.197.105]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Dec 2008 21:49:18 +0000 Received: from 217.32.164.184 ([217.32.164.184]) by E03MVA4-UKBR.domain1.systemhost.net ([193.113.197.56]) via Exchange Front-End Server mail.bt.com ([193.113.197.28]) with Microsoft Exchange Server HTTP-DAV ; Tue, 2 Dec 2008 21:49:18 +0000 User-Agent: Microsoft-Entourage/12.14.0.081024 Date: Tue, 02 Dec 2008 16:49:15 -0500 Subject: Re: CCAMP drafts for adoption From: "Thomas D. Nadeau" To: Nitin Bahadur , Adrian Farrel , Message-ID: Thread-Topic: CCAMP drafts for adoption Thread-Index: AclUl6mpWAW2o7P/QfKhDBZKhoe9CgABkY3AAAiyQSAAAP4GoAAAyC2E In-Reply-To: <7FA0C743C38E5340BFC2873488FA1E8E025DDF5E@emailcorp3.jnpr.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 02 Dec 2008 21:49:18.0518 (UTC) FILETIME=[D3C94D60:01C954C7] Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: I agree with Nitin and do not support the adoption of these drafts. --Tom On 12/2/08 4:35 PM, "Nitin Bahadur" wrote: >>> draft-takacs-ccamp-oam-configuration-fwk-01.txt >>> draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt > > Do not support either of these. > > From the oam-config-fwk draft: >> A new useful application of RSVP-TE is OAM configuration >> and control for transport networks. > > LSP-ping was designed as an OAM mechansim for MPLS LSPs. Why do we need > another mechanism? What are the limitations of lsp-ping that warrant > this new mechanism? > >> When RSVP-TE is used for LSP establishment it is desirable to bind >> OAM setup to connection establishment signalling to avoid two >> separate management/configuration steps > > draft-ietf-bfd-mpls specifies how to use LSP-Ping for automatic setup of > BFD-based OAM. > We should go along the same path for Ethernet OAM. > > Thanks > Nitin > From owner-ccamp@ops.ietf.org Tue Dec 2 13:55:58 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26B563A67D4 for ; Tue, 2 Dec 2008 13:55:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.698 X-Spam-Level: X-Spam-Status: No, score=-4.698 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fIAsVq-Ua34A for ; Tue, 2 Dec 2008 13:55:57 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 419773A6767 for ; Tue, 2 Dec 2008 13:55:57 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7dAm-00030e-DR for ccamp-data@psg.com; Tue, 02 Dec 2008 21:52:48 +0000 Received: from [193.180.251.62] (helo=mailgw4.ericsson.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7dAh-00030B-9C for ccamp@ops.ietf.org; Tue, 02 Dec 2008 21:52:45 +0000 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id E95492039B; Tue, 2 Dec 2008 22:52:40 +0100 (CET) X-AuditID: c1b4fb3e-ab77fbb00000537b-da-4935ae28adf0 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id CAE4E200F6; Tue, 2 Dec 2008 22:52:40 +0100 (CET) Received: from esealmw116.eemea.ericsson.se ([153.88.200.7]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Dec 2008 22:52:40 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: CCAMP drafts for adoption Date: Tue, 2 Dec 2008 22:51:49 +0100 Message-ID: <53CCFDD6E346CB43994852666C210E9105B70D91@esealmw116.eemea.ericsson.se> In-Reply-To: <7FA0C743C38E5340BFC2873488FA1E8E025DDF5E@emailcorp3.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: CCAMP drafts for adoption thread-index: AclUl6mpWAW2o7P/QfKhDBZKhoe9CgABkY3AAAiyQSAAAP4GoAAAuZww References: <001201c9549f$2dac4e50$d626fea9@china.huawei.com> <001601c954c0$d165bf10$470c7c0a@china.huawei.com> <7FA0C743C38E5340BFC2873488FA1E8E025DDF5E@emailcorp3.jnpr.net> From: "Attila Takacs" To: "Nitin Bahadur" , "Adrian Farrel" , X-OriginalArrivalTime: 02 Dec 2008 21:52:40.0815 (UTC) FILETIME=[4C5D5FF0:01C954C8] X-Brightmail-Tracker: AAAAAA== Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Hi Nitin, Please note that these mechanisms are proposed for GMPLS and as such to provide support for any data plane technology specific OAM mechanism. As you noted LSP Ping is for MPLS and BFD only. =20 Best regards, Attila > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Nitin Bahadur > Sent: Tuesday, December 02, 2008 10:35 PM > To: Adrian Farrel; ccamp@ops.ietf.org > Subject: RE: CCAMP drafts for adoption >=20 >=20 >=20 > > > draft-takacs-ccamp-oam-configuration-fwk-01.txt > > > draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt >=20 > Do not support either of these. >=20 > From the oam-config-fwk draft: > > A new useful application of RSVP-TE is OAM configuration=20 > and control=20 > > for transport networks. >=20 > LSP-ping was designed as an OAM mechansim for MPLS LSPs. Why=20 > do we need another mechanism? What are the limitations of=20 > lsp-ping that warrant this new mechanism? >=20 > > When RSVP-TE is used for LSP establishment it is desirable=20 > to bind OAM=20 > > setup to connection establishment signalling to avoid two separate=20 > > management/configuration steps >=20 > draft-ietf-bfd-mpls specifies how to use LSP-Ping for=20 > automatic setup of BFD-based OAM. > We should go along the same path for Ethernet OAM. >=20 > Thanks > Nitin >=20 >=20 From owner-ccamp@ops.ietf.org Tue Dec 2 14:08:18 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E96323A68E6 for ; Tue, 2 Dec 2008 14:08:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.337 X-Spam-Level: X-Spam-Status: No, score=-5.337 tagged_above=-999 required=5 tests=[AWL=-0.842, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UtX8zTu4aaAY for ; Tue, 2 Dec 2008 14:08:18 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EC3603A685E for ; Tue, 2 Dec 2008 14:08:17 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7dLY-0003cj-2u for ccamp-data@psg.com; Tue, 02 Dec 2008 22:03:56 +0000 Received: from [64.18.2.171] (helo=exprod7og109.obsmtp.com) by psg.com with smtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7dLS-0003cC-BT for ccamp@ops.ietf.org; Tue, 02 Dec 2008 22:03:52 +0000 Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKSTWwxL2shw+VWuwWaa24Or1bnoNSBa6C@postini.com; Tue, 02 Dec 2008 14:03:50 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.311.2; Tue, 2 Dec 2008 14:01:12 -0800 Received: from emailcorp3.jnpr.net ([66.129.254.13]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Dec 2008 14:01:12 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: CCAMP drafts for adoption Date: Tue, 2 Dec 2008 14:01:11 -0800 Message-ID: <7FA0C743C38E5340BFC2873488FA1E8E025DDF68@emailcorp3.jnpr.net> In-Reply-To: <53CCFDD6E346CB43994852666C210E9105B70D91@esealmw116.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: CCAMP drafts for adoption thread-index: AclUl6mpWAW2o7P/QfKhDBZKhoe9CgABkY3AAAiyQSAAAP4GoAAAuZwwAABaoIA= References: <001201c9549f$2dac4e50$d626fea9@china.huawei.com> <001601c954c0$d165bf10$470c7c0a@china.huawei.com> <7FA0C743C38E5340BFC2873488FA1E8E025DDF5E@emailcorp3.jnpr.net> <53CCFDD6E346CB43994852666C210E9105B70D91@esealmw116.eemea.ericsson.se> From: Nitin Bahadur To: "Attila Takacs" , "Adrian Farrel" , X-OriginalArrivalTime: 02 Dec 2008 22:01:12.0471 (UTC) FILETIME=[7D55E270:01C954C9] Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Hi Attlia, What is the limitation of lsp-ping that prevents it from being applied to GMPLS? If an existing mechanism can be applied, then why not? If lsp-ping needs extensions to support GMPLS LSPs, feel free to make/specify those extensions. Thanks Nitin =20 > -----Original Message----- > From: Attila Takacs [mailto:Attila.Takacs@ericsson.com]=20 > Sent: Tuesday, December 02, 2008 1:52 PM > To: Nitin Bahadur; Adrian Farrel; ccamp@ops.ietf.org > Subject: RE: CCAMP drafts for adoption >=20 > Hi Nitin, >=20 > Please note that these mechanisms are proposed for GMPLS and=20 > as such to provide support for any data plane technology=20 > specific OAM mechanism. As you noted LSP Ping is for MPLS and=20 > BFD only. =20 >=20 > Best regards, > Attila >=20 > > -----Original Message----- > > From: owner-ccamp@ops.ietf.org > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Nitin Bahadur > > Sent: Tuesday, December 02, 2008 10:35 PM > > To: Adrian Farrel; ccamp@ops.ietf.org > > Subject: RE: CCAMP drafts for adoption > >=20 > >=20 > >=20 > > > > draft-takacs-ccamp-oam-configuration-fwk-01.txt > > > > draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt > >=20 > > Do not support either of these. > >=20 > > From the oam-config-fwk draft: > > > A new useful application of RSVP-TE is OAM configuration > > and control > > > for transport networks. > >=20 > > LSP-ping was designed as an OAM mechansim for MPLS LSPs. Why do we=20 > > need another mechanism? What are the limitations of lsp-ping that=20 > > warrant this new mechanism? > >=20 > > > When RSVP-TE is used for LSP establishment it is desirable > > to bind OAM > > > setup to connection establishment signalling to avoid two=20 > separate=20 > > > management/configuration steps > >=20 > > draft-ietf-bfd-mpls specifies how to use LSP-Ping for=20 > automatic setup=20 > > of BFD-based OAM. > > We should go along the same path for Ethernet OAM. > >=20 > > Thanks > > Nitin > >=20 > >=20 >=20 From owner-ccamp@ops.ietf.org Tue Dec 2 14:13:00 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A5F028C0F6 for ; Tue, 2 Dec 2008 14:13:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.495 X-Spam-Level: X-Spam-Status: No, score=-4.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Axcqh3Tp0xMG for ; Tue, 2 Dec 2008 14:12:59 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A6B8528C0F3 for ; Tue, 2 Dec 2008 14:12:59 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7dR0-0003tj-6L for ccamp-data@psg.com; Tue, 02 Dec 2008 22:09:34 +0000 Received: from [47.140.192.55] (helo=zrtps0kn.nortel.com) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7dQu-0003tG-1Z for ccamp@ops.ietf.org; Tue, 02 Dec 2008 22:09:31 +0000 Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id mB2M9Hr25606; Tue, 2 Dec 2008 22:09:17 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: CCAMP drafts for adoption Date: Tue, 2 Dec 2008 17:08:53 -0500 Message-ID: <87AC5F88F03E6249AEA68D40BD3E00BE168324A4@zcarhxm2.corp.nortel.com> In-Reply-To: <7FA0C743C38E5340BFC2873488FA1E8E025DDF5E@emailcorp3.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: CCAMP drafts for adoption Thread-Index: AclUl6mpWAW2o7P/QfKhDBZKhoe9CgABkY3AAAiyQSAAAP4GoAAApjZg References: <001201c9549f$2dac4e50$d626fea9@china.huawei.com> <001601c954c0$d165bf10$470c7c0a@china.huawei.com> <7FA0C743C38E5340BFC2873488FA1E8E025DDF5E@emailcorp3.jnpr.net> From: "David Allan" To: "Nitin Bahadur" , "Adrian Farrel" , Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Hi Nitin: You wrote: > LSP-ping was designed as an OAM mechansim for MPLS LSPs. Why do we need another mechanism? What are the limitations of=20 > lsp-ping that warrant this new mechanism? We should go along the same path for Ethernet OAM. It is not applicable to either a PBB-TE switched path or, if you are of that persuasion, an MPLS-TP switched path...as it stands today. And it only goes downhill from there.... I would think the inappropriateness of applying LSP-PING to Ethernet OAM would be self evident...Ethernet OAM already has it's own LB/LT functionality so mandating another loopback exclusively for OAM configuration is gratuitously complex. As for MPLS-TP, LSP-PING would need recasting as a "non-IP" protocol to fit the mandated profile from the joint design team and likely would benefit from a trip to the fat farm to shed the other features it did not need within said profile... Dave From owner-ccamp@ops.ietf.org Tue Dec 2 14:18:50 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6439628C0F3 for ; Tue, 2 Dec 2008 14:18:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.698 X-Spam-Level: X-Spam-Status: No, score=-4.698 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BAN7XueFNbhI for ; Tue, 2 Dec 2008 14:18:49 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 995D03A6836 for ; Tue, 2 Dec 2008 14:18:48 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7dWE-0004CO-EU for ccamp-data@psg.com; Tue, 02 Dec 2008 22:14:58 +0000 Received: from [193.180.251.60] (helo=mailgw3.ericsson.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7dW8-0004C0-8v for ccamp@ops.ietf.org; Tue, 02 Dec 2008 22:14:55 +0000 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 775E0203E0; Tue, 2 Dec 2008 23:14:50 +0100 (CET) X-AuditID: c1b4fb3c-aff62bb00000304c-a8-4935b35a651b Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 5297720058; Tue, 2 Dec 2008 23:14:50 +0100 (CET) Received: from esealmw116.eemea.ericsson.se ([153.88.200.7]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Dec 2008 23:14:50 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: CCAMP drafts for adoption Date: Tue, 2 Dec 2008 23:14:01 +0100 Message-ID: <53CCFDD6E346CB43994852666C210E9105B70DA5@esealmw116.eemea.ericsson.se> In-Reply-To: <7FA0C743C38E5340BFC2873488FA1E8E025DDF68@emailcorp3.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: CCAMP drafts for adoption thread-index: AclUl6mpWAW2o7P/QfKhDBZKhoe9CgABkY3AAAiyQSAAAP4GoAAAuZwwAABaoIAAACzaAA== References: <001201c9549f$2dac4e50$d626fea9@china.huawei.com> <001601c954c0$d165bf10$470c7c0a@china.huawei.com> <7FA0C743C38E5340BFC2873488FA1E8E025DDF5E@emailcorp3.jnpr.net> <53CCFDD6E346CB43994852666C210E9105B70D91@esealmw116.eemea.ericsson.se> <7FA0C743C38E5340BFC2873488FA1E8E025DDF68@emailcorp3.jnpr.net> From: "Attila Takacs" To: "Nitin Bahadur" , "Adrian Farrel" , X-OriginalArrivalTime: 02 Dec 2008 22:14:50.0072 (UTC) FILETIME=[64A9E580:01C954CB] X-Brightmail-Tracker: AAAAAA== Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Hi Nitin, I would formulate this form the other way around. If we already have a technology agnostic solution, read GMPLS, it seems to be straightforward to continue using it. Then why not? :-) One key benefit of using RSVP-TE is that OAM configuration is bound to the actual LSP establishment this simplifies management and avoids misconfiguration. With LSP Ping we would need one mechanism to setup the LSPs (read *not* just MPLS) using GMPLS and then apply another solution say Generalized-LSP Ping to configure OAM; if I understand your proposal right. >From another perspective, what would be the use of LSP Ping over, e.g., an optical network or Ethernet using CFM? Best regards, Attila > -----Original Message----- > From: Nitin Bahadur [mailto:nitinb@juniper.net]=20 > Sent: Tuesday, December 02, 2008 11:01 PM > To: Attila Takacs; Adrian Farrel; ccamp@ops.ietf.org > Subject: RE: CCAMP drafts for adoption >=20 >=20 > Hi Attlia, >=20 > What is the limitation of lsp-ping that prevents it from=20 > being applied to GMPLS? > If an existing mechanism can be applied, then why not? If=20 > lsp-ping needs extensions to support GMPLS LSPs, feel free to=20 > make/specify those extensions. >=20 > Thanks > Nitin =20 >=20 > > -----Original Message----- > > From: Attila Takacs [mailto:Attila.Takacs@ericsson.com] > > Sent: Tuesday, December 02, 2008 1:52 PM > > To: Nitin Bahadur; Adrian Farrel; ccamp@ops.ietf.org > > Subject: RE: CCAMP drafts for adoption > >=20 > > Hi Nitin, > >=20 > > Please note that these mechanisms are proposed for GMPLS=20 > and as such=20 > > to provide support for any data plane technology specific OAM=20 > > mechanism. As you noted LSP Ping is for MPLS and BFD only. > >=20 > > Best regards, > > Attila > >=20 > > > -----Original Message----- > > > From: owner-ccamp@ops.ietf.org > > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Nitin Bahadur > > > Sent: Tuesday, December 02, 2008 10:35 PM > > > To: Adrian Farrel; ccamp@ops.ietf.org > > > Subject: RE: CCAMP drafts for adoption > > >=20 > > >=20 > > >=20 > > > > > draft-takacs-ccamp-oam-configuration-fwk-01.txt > > > > > draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt > > >=20 > > > Do not support either of these. > > >=20 > > > From the oam-config-fwk draft: > > > > A new useful application of RSVP-TE is OAM configuration > > > and control > > > > for transport networks. > > >=20 > > > LSP-ping was designed as an OAM mechansim for MPLS LSPs.=20 > Why do we=20 > > > need another mechanism? What are the limitations of lsp-ping that=20 > > > warrant this new mechanism? > > >=20 > > > > When RSVP-TE is used for LSP establishment it is desirable > > > to bind OAM > > > > setup to connection establishment signalling to avoid two > > separate > > > > management/configuration steps > > >=20 > > > draft-ietf-bfd-mpls specifies how to use LSP-Ping for > > automatic setup > > > of BFD-based OAM. > > > We should go along the same path for Ethernet OAM. > > >=20 > > > Thanks > > > Nitin > > >=20 > > >=20 > >=20 >=20 From owner-ccamp@ops.ietf.org Tue Dec 2 14:23:52 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BFFB28C0F3 for ; Tue, 2 Dec 2008 14:23:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.397 X-Spam-Level: X-Spam-Status: No, score=-2.397 tagged_above=-999 required=5 tests=[AWL=-0.902, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_LOW=-1, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kzC5MhV8VhRR for ; Tue, 2 Dec 2008 14:23:51 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AC4863A6877 for ; Tue, 2 Dec 2008 14:23:51 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7dc8-0004YG-Ui for ccamp-data@psg.com; Tue, 02 Dec 2008 22:21:04 +0000 Received: from [217.32.164.150] (helo=smtp2.smtp.bt.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7dc2-0004Xn-TR for ccamp@ops.ietf.org; Tue, 02 Dec 2008 22:21:01 +0000 Received: from E03MVB2-UKBR.domain1.systemhost.net ([193.113.197.107]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Dec 2008 22:20:57 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: CCAMP drafts for adoption Date: Tue, 2 Dec 2008 22:20:52 -0000 Message-ID: <2ECAA42C79676B42AEBAC11229CA7D0C03B2F399@E03MVB2-UKBR.domain1.systemhost.net> In-Reply-To: <7FA0C743C38E5340BFC2873488FA1E8E025DDF68@emailcorp3.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: CCAMP drafts for adoption thread-index: AclUl6mpWAW2o7P/QfKhDBZKhoe9CgABkY3AAAiyQSAAAP4GoAAAuZwwAABaoIAAAIBcIA== From: To: , , , X-OriginalArrivalTime: 02 Dec 2008 22:20:57.0813 (UTC) FILETIME=[3FDAB850:01C954CC] Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: You should not be using one DP OAM (heavyweight) function to activate (deactivate??) another DP OAM (lightweight) function. However, since LDP does not create proper connections there is no concept of LSP (path) set-up/tear-down...ergo LSP ping tries to treat it like a cl-ps mode network case. This is NOT the case for GMPLS...esp when applied to any co-cs mode technology (here proper connections are forced), and it is not the case for the co-ps mode when proper connections are used (eg RSVP-TE in MPLS). Hopwever to be very clear here...it is operationally critical to be able to activate/decativate OAM flows in sync with whatever CP or MP process is responsible for connection set-up/tear-down in both co-cs and co-ps mode layer networks....and LSP ping simply does not fit the bill here. regards, Neil > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Nitin Bahadur > Sent: 02 December 2008 22:01 > To: Attila Takacs; Adrian Farrel; ccamp@ops.ietf.org > Subject: RE: CCAMP drafts for adoption >=20 >=20 > Hi Attlia, >=20 > What is the limitation of lsp-ping that prevents it from=20 > being applied to GMPLS? > If an existing mechanism can be applied, then why not? If=20 > lsp-ping needs extensions to support GMPLS LSPs, feel free to=20 > make/specify those extensions. >=20 > Thanks > Nitin =20 >=20 > > -----Original Message----- > > From: Attila Takacs [mailto:Attila.Takacs@ericsson.com] > > Sent: Tuesday, December 02, 2008 1:52 PM > > To: Nitin Bahadur; Adrian Farrel; ccamp@ops.ietf.org > > Subject: RE: CCAMP drafts for adoption > >=20 > > Hi Nitin, > >=20 > > Please note that these mechanisms are proposed for GMPLS=20 > and as such=20 > > to provide support for any data plane technology specific OAM=20 > > mechanism. As you noted LSP Ping is for MPLS and BFD only. > >=20 > > Best regards, > > Attila > >=20 > > > -----Original Message----- > > > From: owner-ccamp@ops.ietf.org > > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Nitin Bahadur > > > Sent: Tuesday, December 02, 2008 10:35 PM > > > To: Adrian Farrel; ccamp@ops.ietf.org > > > Subject: RE: CCAMP drafts for adoption > > >=20 > > >=20 > > >=20 > > > > > draft-takacs-ccamp-oam-configuration-fwk-01.txt > > > > > draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt > > >=20 > > > Do not support either of these. > > >=20 > > > From the oam-config-fwk draft: > > > > A new useful application of RSVP-TE is OAM configuration > > > and control > > > > for transport networks. > > >=20 > > > LSP-ping was designed as an OAM mechansim for MPLS LSPs.=20 > Why do we=20 > > > need another mechanism? What are the limitations of lsp-ping that=20 > > > warrant this new mechanism? > > >=20 > > > > When RSVP-TE is used for LSP establishment it is desirable > > > to bind OAM > > > > setup to connection establishment signalling to avoid two > > separate > > > > management/configuration steps > > >=20 > > > draft-ietf-bfd-mpls specifies how to use LSP-Ping for > > automatic setup > > > of BFD-based OAM. > > > We should go along the same path for Ethernet OAM. > > >=20 > > > Thanks > > > Nitin > > >=20 > > >=20 > >=20 >=20 >=20 From owner-ccamp@ops.ietf.org Tue Dec 2 14:26:04 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5119A3A6877 for ; Tue, 2 Dec 2008 14:26:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.494 X-Spam-Level: X-Spam-Status: No, score=-0.494 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jLSVWBmKQvAy for ; Tue, 2 Dec 2008 14:26:03 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0CBB628C0F7 for ; Tue, 2 Dec 2008 14:26:03 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7dd0-0004bs-VR for ccamp-data@psg.com; Tue, 02 Dec 2008 22:21:58 +0000 Received: from [209.191.85.56] (helo=web36805.mail.mud.yahoo.com) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7dcu-0004bU-EB for ccamp@ops.ietf.org; Tue, 02 Dec 2008 22:21:56 +0000 Received: (qmail 95732 invoked by uid 60001); 2 Dec 2008 22:21:51 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=v/bPulpuQNgBteS+q2Vgz3jomFVNKBXMvJ+Qz4EvOoekt8VJ58aBbR/j7sdo3WlGG844MD669vGyO1BrOUPFCOl0kl5ik4f2KptKdpFlhLcGvxEJoZiYBEch9NG6ZC/QMSYQlMyuurx4T6xSD+x1RVbuyRDK/9YO9hzvozgh2Q0=; X-YMail-OSG: yEGV1aMVM1kbZGMjeg1JP0x0BBPlJzkZPP3DbZBTH4J4P.jv7dylsGXk0nz9Vv84XX0JmJ30jRWIQ2G4VfEvXoLJ4bSUrzwPyQKGgWsfWTWnbPo5JaUp6dRRDmUsQRABaJcpO320oED.5Qrc4J_DiG6f3PN_7jmGGT6jXn5AkQUO0w-- Received: from [67.102.145.11] by web36805.mail.mud.yahoo.com via HTTP; Tue, 02 Dec 2008 14:21:51 PST X-Mailer: YahooMailRC/1155.32 YahooMailWebService/0.7.260.1 References: <001201c9549f$2dac4e50$d626fea9@china.huawei.com> <001601c954c0$d165bf10$470c7c0a@china.huawei.com> <7FA0C743C38E5340BFC2873488FA1E8E025DDF5E@emailcorp3.jnpr.net> <53CCFDD6E346CB43994852666C210E9105B70D91@esealmw116.eemea.ericsson.se> <7FA0C743C38E5340BFC2873488FA1E8E025DDF68@emailcorp3.jnpr.net> Date: Tue, 2 Dec 2008 14:21:51 -0800 (PST) From: Igor Bryskin Subject: Re: CCAMP drafts for adoption To: Nitin Bahadur , Attila Takacs , Adrian Farrel , ccamp@ops.ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1170914688-1228256511=:95032" Message-ID: <684158.95032.qm@web36805.mail.mud.yahoo.com> Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: --0-1170914688-1228256511=:95032 Content-Type: text/plain; charset=us-ascii Nitin, The difference is that GMPLS is a control plane, while OAM is supposed to work in the data plane. In transport networks control plane and data plane are separated. In fact, OAM should work without and should not depend upon control plane at all. You can not send Ping messages over lambda layer network connection, can you? On the other hand, you can use GMPLS to consistently configire OAM function on the connection NEs, and that's what these drafts as I understand are about. In other words, in MPLS LSP Ping is OAM, while GMPLS can only automate OAM configuration, it can not relalize OAM on its own. Cheers, Igor ________________________________ From: Nitin Bahadur To: Attila Takacs ; Adrian Farrel ; ccamp@ops.ietf.org Sent: Tuesday, December 2, 2008 5:01:11 PM Subject: RE: CCAMP drafts for adoption Hi Attlia, What is the limitation of lsp-ping that prevents it from being applied to GMPLS? If an existing mechanism can be applied, then why not? If lsp-ping needs extensions to support GMPLS LSPs, feel free to make/specify those extensions. Thanks Nitin > -----Original Message----- > From: Attila Takacs [mailto:Attila.Takacs@ericsson.com] > Sent: Tuesday, December 02, 2008 1:52 PM > To: Nitin Bahadur; Adrian Farrel; ccamp@ops.ietf.org > Subject: RE: CCAMP drafts for adoption > > Hi Nitin, > > Please note that these mechanisms are proposed for GMPLS and > as such to provide support for any data plane technology > specific OAM mechanism. As you noted LSP Ping is for MPLS and > BFD only. > > Best regards, > Attila > > > -----Original Message----- > > From: owner-ccamp@ops.ietf.org > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Nitin Bahadur > > Sent: Tuesday, December 02, 2008 10:35 PM > > To: Adrian Farrel; ccamp@ops.ietf.org > > Subject: RE: CCAMP drafts for adoption > > > > > > > > > > draft-takacs-ccamp-oam-configuration-fwk-01.txt > > > > draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt > > > > Do not support either of these. > > > > From the oam-config-fwk draft: > > > A new useful application of RSVP-TE is OAM configuration > > and control > > > for transport networks. > > > > LSP-ping was designed as an OAM mechansim for MPLS LSPs. Why do we > > need another mechanism? What are the limitations of lsp-ping that > > warrant this new mechanism? > > > > > When RSVP-TE is used for LSP establishment it is desirable > > to bind OAM > > > setup to connection establishment signalling to avoid two > separate > > > management/configuration steps > > > > draft-ietf-bfd-mpls specifies how to use LSP-Ping for > automatic setup > > of BFD-based OAM. > > We should go along the same path for Ethernet OAM. > > > > Thanks > > Nitin > > > > > --0-1170914688-1228256511=:95032 Content-Type: text/html; charset=us-ascii
Nitin,

The difference is that GMPLS is a control plane, while OAM is supposed to work in the data plane. In transport networks control plane and data plane are separated. In fact, OAM should work without and should not depend upon control plane at all. You can not send Ping messages over lambda layer network connection, can you?
On the other hand, you can use GMPLS to consistently configire OAM function on the connection NEs, and that's what these drafts as I understand are about.

In other words, in MPLS LSP Ping is OAM, while GMPLS can only automate OAM configuration, it can not relalize OAM on its own.

Cheers,
Igor

From: Nitin Bahadur <nitinb@juniper.net>
To: Attila Takacs <Attila.Takacs@ericsson.com>; Adrian Farrel <adrian@olddog.co.uk>; ccamp@ops.ietf.org
Sent: Tuesday, December 2, 2008 5:01:11 PM
Subject: RE: CCAMP drafts for adoption


Hi Attlia,

  What is the limitation of lsp-ping that prevents it from being
applied to GMPLS?
If an existing mechanism can be applied, then why not? If lsp-ping needs
extensions to support GMPLS LSPs, feel free to make/specify those
extensions.

Thanks
Nitin 

> -----Original Message-----
> From: Attila Takacs [mailto:Attila.Takacs@ericsson.com]
> Sent: Tuesday, December 02, 2008 1:52 PM
> To: Nitin Bahadur; Adrian Farrel; ccamp@ops.ietf.org
> Subject: RE: CCAMP drafts for adoption
>
> Hi Nitin,
>
> Please note that these mechanisms are proposed for GMPLS and
> as such to provide support for any data plane technology
> specific OAM mechanism. As you noted LSP Ping is for MPLS and
> BFD only. 
>
> Best regards,
> Attila
>
> > -----Original Message-----
> > From: owner-ccamp@ops.ietf.org
> > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Nitin Bahadur
> > Sent: Tuesday, December 02, 2008 10:35 PM
> > To: Adrian Farrel; ccamp@ops.ietf.org
> > Subject: RE: CCAMP drafts for adoption
> >
> >
> >
> > > > draft-takacs-ccamp-oam-configuration-fwk-01.txt
> > > > draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt
> >
> > Do not support either of these.
> >
> > From the oam-config-fwk draft:
> > > A new useful application of RSVP-TE is OAM configuration
> > and control
> > > for transport networks.
> >
> > LSP-ping was designed as an OAM mechansim for MPLS LSPs. Why do we
> > need another mechanism? What are the limitations of lsp-ping that
> > warrant this new mechanism?
> >
> > > When RSVP-TE is used for LSP establishment it is desirable
> > to bind OAM
> > > setup to connection establishment signalling to avoid two
> separate
> > > management/configuration steps
> >
> > draft-ietf-bfd-mpls specifies how to use LSP-Ping for
> automatic setup
> > of BFD-based OAM.
> > We should go along the same path for Ethernet OAM.
> >
> > Thanks
> > Nitin
> >
> >
>


--0-1170914688-1228256511=:95032-- From owner-ccamp@ops.ietf.org Tue Dec 2 14:37:19 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45EAA3A68AD for ; Tue, 2 Dec 2008 14:37:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.495 X-Spam-Level: X-Spam-Status: No, score=-4.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v4P9aJi6DypV for ; Tue, 2 Dec 2008 14:37:18 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5B4B73A67C0 for ; Tue, 2 Dec 2008 14:37:18 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7dnH-0005DG-R1 for ccamp-data@psg.com; Tue, 02 Dec 2008 22:32:35 +0000 Received: from [47.129.242.57] (helo=zcars04f.nortel.com) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7dn8-0005Bv-IX for ccamp@ops.ietf.org; Tue, 02 Dec 2008 22:32:30 +0000 Received: from zrtphxm2.corp.nortel.com (zrtphxm2.corp.nortel.com [47.140.202.51]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id mB2MWJq18877; Tue, 2 Dec 2008 22:32:20 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: CCAMP drafts for adoption Date: Tue, 2 Dec 2008 17:32:18 -0500 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA417C1D2F4@zrtphxm2.corp.nortel.com> In-Reply-To: <7FA0C743C38E5340BFC2873488FA1E8E025DDF5E@emailcorp3.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: CCAMP drafts for adoption Thread-Index: AclUl6mpWAW2o7P/QfKhDBZKhoe9CgABkY3AAAiyQSAAAP4GoAABt/Wg References: <001201c9549f$2dac4e50$d626fea9@china.huawei.com> <001601c954c0$d165bf10$470c7c0a@china.huawei.com> <7FA0C743C38E5340BFC2873488FA1E8E025DDF5E@emailcorp3.jnpr.net> From: "Don Fedyk" To: "Nitin Bahadur" , "Adrian Farrel" , Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Hi Nitin=20 > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Nitin Bahadur >=20 >=20 > > > draft-takacs-ccamp-oam-configuration-fwk-01.txt > > > draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt >=20 > Do not support either of these. >=20 > From the oam-config-fwk draft: > > A new useful application of RSVP-TE is OAM configuration > > and control for transport networks. >=20 > LSP-ping was designed as an OAM mechansim for MPLS LSPs. Why=20 > do we need > another mechanism? What are the limitations of lsp-ping that warrant > this new mechanism? These drafts support configuration of data plane OAM functions when you are using RSVP-TE to setup the paths. The alternative is operator configuration. It has nothing to do with LSP Ping.=20 >=20 > > When RSVP-TE is used for LSP establishment it is desirable to bind > > OAM setup to connection establishment signalling to avoid two > > separate management/configuration steps >=20 > draft-ietf-bfd-mpls specifies how to use LSP-Ping for=20 > automatic setup of > BFD-based OAM. So LSP Ping sets up BFD? Interesting. While I can see this might be useful in the case of LDP when debugging a problem you do have issues with LSP-Ping reaching all path combinations and certain error scenarios. I don't think this is a comprehensive mechanism.=20 This is clearly different than what we are specifying in the Ethernet OAM case.=20 Regards, Don =20 > We should go along the same path for Ethernet OAM. >=20 > Thanks > Nitin >=20 >=20 From owner-ccamp@ops.ietf.org Tue Dec 2 14:42:05 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7EDF3A67C0 for ; Tue, 2 Dec 2008 14:42:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.196 X-Spam-Level: X-Spam-Status: No, score=-5.196 tagged_above=-999 required=5 tests=[AWL=-0.701, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nMNYHTQRo9Z5 for ; Tue, 2 Dec 2008 14:42:04 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D4EB328C20C for ; Tue, 2 Dec 2008 14:41:14 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7dsR-0005Vs-Rd for ccamp-data@psg.com; Tue, 02 Dec 2008 22:37:55 +0000 Received: from [64.18.2.175] (helo=exprod7og111.obsmtp.com) by psg.com with smtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7dsM-0005VP-3Z for ccamp@ops.ietf.org; Tue, 02 Dec 2008 22:37:52 +0000 Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKSTW4vdvZ7QJ+SmKiWuuSQ4T0HoErmfcg@postini.com; Tue, 02 Dec 2008 14:37:50 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.311.2; Tue, 2 Dec 2008 14:35:45 -0800 Received: from emailcorp3.jnpr.net ([66.129.254.13]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Dec 2008 14:35:44 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: CCAMP drafts for adoption Date: Tue, 2 Dec 2008 14:35:44 -0800 Message-ID: <7FA0C743C38E5340BFC2873488FA1E8E025DDF6A@emailcorp3.jnpr.net> In-Reply-To: <53CCFDD6E346CB43994852666C210E9105B70DA5@esealmw116.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: CCAMP drafts for adoption thread-index: AclUl6mpWAW2o7P/QfKhDBZKhoe9CgABkY3AAAiyQSAAAP4GoAAAuZwwAABaoIAAACzaAAAAe+hQ References: <001201c9549f$2dac4e50$d626fea9@china.huawei.com> <001601c954c0$d165bf10$470c7c0a@china.huawei.com> <7FA0C743C38E5340BFC2873488FA1E8E025DDF5E@emailcorp3.jnpr.net> <53CCFDD6E346CB43994852666C210E9105B70D91@esealmw116.eemea.ericsson.se> <7FA0C743C38E5340BFC2873488FA1E8E025DDF68@emailcorp3.jnpr.net> <53CCFDD6E346CB43994852666C210E9105B70DA5@esealmw116.eemea.ericsson.se> From: Nitin Bahadur To: "Attila Takacs" , X-OriginalArrivalTime: 02 Dec 2008 22:35:44.0828 (UTC) FILETIME=[508E77C0:01C954CE] Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: > I would formulate this form the other way around. If we=20 > already have a technology agnostic solution, read GMPLS, it=20 > seems to be straightforward to continue using it. Then why not? :-) >=20 > One key benefit of using RSVP-TE is that OAM configuration is=20 > bound to the actual LSP establishment this simplifies=20 > management and avoids misconfiguration. With LSP Ping we=20 > would need one mechanism to setup the LSPs (read *not* just=20 > MPLS) using GMPLS and then apply another solution say=20 > Generalized-LSP Ping to configure OAM; if I understand your=20 > proposal right. Yes...your understanding of my proposal is correct.=20 But it would solve your issue of manual=20 OAM configuration. Agreed, it's a 2-step control-plane process. =20 > From another perspective, what would be the use of LSP Ping=20 > over, e.g., an optical network or Ethernet using CFM? Just for setup of the OAM parameters. Ethernet OAM provides a bunch of capabilities (like LT/LB) and you would use them as-is. The advantage of using lsp-ping is that only the LSP egress sees the OAM parmeters.=20 If you add a new-TLV to the PATH msg, then you need to send it on every PATH msg... You really need to signal the parameters once during LSP-setup time (and perhaps when the parameters are changed). LSP-Ping has a whole bunch of stuff defined. Most of it is not needed/applicable in various scenarios. But the advantage is that it's all there. As you go ahead with defining a new mechanism, you will gradually see other requirements/needs and you might end up re-inventing lsp-ping in another form. > Best regards, > Attila >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: Nitin Bahadur [mailto:nitinb@juniper.net] > > Sent: Tuesday, December 02, 2008 11:01 PM > > To: Attila Takacs; Adrian Farrel; ccamp@ops.ietf.org > > Subject: RE: CCAMP drafts for adoption > >=20 > >=20 > > Hi Attlia, > >=20 > > What is the limitation of lsp-ping that prevents it from being=20 > > applied to GMPLS? > > If an existing mechanism can be applied, then why not? If lsp-ping=20 > > needs extensions to support GMPLS LSPs, feel free to make/specify=20 > > those extensions. > >=20 > > Thanks > > Nitin > >=20 > > > -----Original Message----- > > > From: Attila Takacs [mailto:Attila.Takacs@ericsson.com] > > > Sent: Tuesday, December 02, 2008 1:52 PM > > > To: Nitin Bahadur; Adrian Farrel; ccamp@ops.ietf.org > > > Subject: RE: CCAMP drafts for adoption > > >=20 > > > Hi Nitin, > > >=20 > > > Please note that these mechanisms are proposed for GMPLS > > and as such > > > to provide support for any data plane technology specific OAM=20 > > > mechanism. As you noted LSP Ping is for MPLS and BFD only. > > >=20 > > > Best regards, > > > Attila > > >=20 > > > > -----Original Message----- > > > > From: owner-ccamp@ops.ietf.org > > > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Nitin Bahadur > > > > Sent: Tuesday, December 02, 2008 10:35 PM > > > > To: Adrian Farrel; ccamp@ops.ietf.org > > > > Subject: RE: CCAMP drafts for adoption > > > >=20 > > > >=20 > > > >=20 > > > > > > draft-takacs-ccamp-oam-configuration-fwk-01.txt > > > > > > draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt > > > >=20 > > > > Do not support either of these. > > > >=20 > > > > From the oam-config-fwk draft: > > > > > A new useful application of RSVP-TE is OAM configuration > > > > and control > > > > > for transport networks. > > > >=20 > > > > LSP-ping was designed as an OAM mechansim for MPLS LSPs.=20 > > Why do we > > > > need another mechanism? What are the limitations of=20 > lsp-ping that=20 > > > > warrant this new mechanism? > > > >=20 > > > > > When RSVP-TE is used for LSP establishment it is desirable > > > > to bind OAM > > > > > setup to connection establishment signalling to avoid two > > > separate > > > > > management/configuration steps > > > >=20 > > > > draft-ietf-bfd-mpls specifies how to use LSP-Ping for > > > automatic setup > > > > of BFD-based OAM. > > > > We should go along the same path for Ethernet OAM. > > > >=20 > > > > Thanks > > > > Nitin > > > >=20 > > > >=20 > > >=20 > >=20 >=20 From owner-ccamp@ops.ietf.org Tue Dec 2 14:50:13 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F4B228C207 for ; Tue, 2 Dec 2008 14:50:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.096 X-Spam-Level: X-Spam-Status: No, score=-5.096 tagged_above=-999 required=5 tests=[AWL=-0.601, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CqZCflzUPasH for ; Tue, 2 Dec 2008 14:50:12 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2F24B28C1FF for ; Tue, 2 Dec 2008 14:50:12 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7e0h-000607-9I for ccamp-data@psg.com; Tue, 02 Dec 2008 22:46:27 +0000 Received: from [64.18.2.175] (helo=exprod7og111.obsmtp.com) by psg.com with smtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7e0c-0005zj-04 for ccamp@ops.ietf.org; Tue, 02 Dec 2008 22:46:24 +0000 Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKSTW6vHSE1nMAGkoVVC26b32WNf9syqDE@postini.com; Tue, 02 Dec 2008 14:46:21 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.311.2; Tue, 2 Dec 2008 14:43:22 -0800 Received: from emailcorp3.jnpr.net ([66.129.254.13]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Dec 2008 14:43:22 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: CCAMP drafts for adoption Date: Tue, 2 Dec 2008 14:43:21 -0800 Message-ID: <7FA0C743C38E5340BFC2873488FA1E8E025DDF6B@emailcorp3.jnpr.net> In-Reply-To: <87AC5F88F03E6249AEA68D40BD3E00BE168324A4@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: CCAMP drafts for adoption thread-index: AclUl6mpWAW2o7P/QfKhDBZKhoe9CgABkY3AAAiyQSAAAP4GoAAApjZgAAHEswA= References: <001201c9549f$2dac4e50$d626fea9@china.huawei.com> <001601c954c0$d165bf10$470c7c0a@china.huawei.com> <7FA0C743C38E5340BFC2873488FA1E8E025DDF5E@emailcorp3.jnpr.net> <87AC5F88F03E6249AEA68D40BD3E00BE168324A4@zcarhxm2.corp.nortel.com> From: Nitin Bahadur To: "David Allan" , X-OriginalArrivalTime: 02 Dec 2008 22:43:22.0425 (UTC) FILETIME=[614E3A90:01C954CF] Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: > > LSP-ping was designed as an OAM mechansim for MPLS LSPs. Why do we > need another mechanism? What are the limitations of=20 > > lsp-ping that warrant this new mechanism? We=20 > should go along > the same path for Ethernet OAM. >=20 > It is not applicable to either a PBB-TE switched path or, if=20 > you are of that persuasion, an MPLS-TP switched path...as it=20 > stands today. And it only goes downhill from there.... David, all that I am asking is that one can use the basic-bare-bones definitions=20 in lsp-ping to setup the Ethernet OAM params. I am not talking about applicability nor I am saying that one needs to use ping and trace based off lsp-ping for PBB-TE LSPs.=20 We have a whole bunch of stuff defined in RSVP. Obviously some of them are not applicable for GMPLS LSPs. But that does not mean that we go define G-RSVP (for GMPLS LSPs). =20 > I would think the inappropriateness of applying LSP-PING to=20 > Ethernet OAM would be self evident...Ethernet OAM already has=20 > it's own LB/LT functionality so mandating another loopback=20 > exclusively for OAM configuration is gratuitously complex. I am not asking you to use lsp-ping for LB/LT. I agree that ethernet OAM already has that and indeed once should use that. I am just saying that the setup can be done using lsp-ping. =20 > As for MPLS-TP, LSP-PING would need recasting as a "non-IP"=20 > protocol to fit the mandated profile from the joint design=20 > team and likely would benefit from a trip to the fat farm to=20 > shed the other features it did not need within said profile... LSP-Ping is already non-IP from a *forwarding* perspective. LSP-Ping has a reply-mode of *application channel* which can be used for things like bi-directional LSPs. So for MPLS-TP LSPs, the lsp-ping replies would go on the LSP reverse path (label-switched and not IP forwarded). Thanks Nitin From owner-ccamp@ops.ietf.org Tue Dec 2 15:05:50 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA19628C20D for ; Tue, 2 Dec 2008 15:05:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.495 X-Spam-Level: X-Spam-Status: No, score=-4.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uAaZIjpTlJnh for ; Tue, 2 Dec 2008 15:05:50 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EE7BA28C207 for ; Tue, 2 Dec 2008 15:05:49 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7eG9-0006y4-Ie for ccamp-data@psg.com; Tue, 02 Dec 2008 23:02:25 +0000 Received: from [47.129.242.57] (helo=zcars04f.nortel.com) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7eG4-0006xo-Nv for ccamp@ops.ietf.org; Tue, 02 Dec 2008 23:02:22 +0000 Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id mB2N2Fq21691; Tue, 2 Dec 2008 23:02:15 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: CCAMP drafts for adoption Date: Tue, 2 Dec 2008 18:01:25 -0500 Message-ID: <87AC5F88F03E6249AEA68D40BD3E00BE168324AD@zcarhxm2.corp.nortel.com> In-Reply-To: <7FA0C743C38E5340BFC2873488FA1E8E025DDF6B@emailcorp3.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: CCAMP drafts for adoption Thread-Index: AclUl6mpWAW2o7P/QfKhDBZKhoe9CgABkY3AAAiyQSAAAP4GoAAApjZgAAHEswAAAIicsA== References: <001201c9549f$2dac4e50$d626fea9@china.huawei.com> <001601c954c0$d165bf10$470c7c0a@china.huawei.com> <7FA0C743C38E5340BFC2873488FA1E8E025DDF5E@emailcorp3.jnpr.net> <87AC5F88F03E6249AEA68D40BD3E00BE168324A4@zcarhxm2.corp.nortel.com> <7FA0C743C38E5340BFC2873488FA1E8E025DDF6B@emailcorp3.jnpr.net> From: "David Allan" To: "Nitin Bahadur" , Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: HI Nitin: Thanks for replying.... > David, all that I am asking is that one can use the basic-bare-bones definitions in lsp-ping to setup the Ethernet OAM=20 > params. I am not talking about applicability nor I am saying that one needs to use ping and trace based off lsp-ping for > PBB-TE LSPs.=20 But this still requires implementing a new protocol where it does not already exist, which also requires a *new* bare bones definition... > We have a whole bunch of stuff defined in RSVP. Obviously some of them are not applicable for GMPLS LSPs. But that does > not mean that we go define G-RSVP (for GMPLS LSPs). Isn't that CCAMPs mandate? =20 > I am not asking you to use lsp-ping for LB/LT. I agree that ethernet OAM already has that and indeed once should use=20 > that. I am just saying that the setup can be done using lsp-ping. I think the point was GMPLS applies to a lot of technologies that cannot do LSP-PING in the first place, which means such a signalling extension will be required nonetheless... > LSP-Ping is already non-IP from a *forwarding* perspective. LSP-Ping has a reply-mode of *application channel* which can > be used for things like bi-directional LSPs. So for MPLS-TP LSPs, the lsp-ping replies would go on the LSP reverse path > (label-switched and not IP forwarded). OK, I can see that such an approach could be made to work and would be desirable to some. On that basis, can I suggest you withdraw your objections to the Eth-Oam draft and move the TP parts of this discussion over to the MPLS list? That would seem appropriate... Cheers Dave From owner-ccamp@ops.ietf.org Tue Dec 2 15:15:02 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4874628C213 for ; Tue, 2 Dec 2008 15:15:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.021 X-Spam-Level: X-Spam-Status: No, score=-5.021 tagged_above=-999 required=5 tests=[AWL=-0.526, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z48nCqdFQN4h for ; Tue, 2 Dec 2008 15:15:01 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CBC063A6877 for ; Tue, 2 Dec 2008 15:14:59 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7eOh-0007Ms-VF for ccamp-data@psg.com; Tue, 02 Dec 2008 23:11:15 +0000 Received: from [64.18.2.216] (helo=exprod7og115.obsmtp.com) by psg.com with smtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7eOc-0007MP-1d for ccamp@ops.ietf.org; Tue, 02 Dec 2008 23:11:12 +0000 Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKSTXAjWjfoTthN4tUBqmzikZfErxsb8ZU@postini.com; Tue, 02 Dec 2008 15:11:09 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.311.2; Tue, 2 Dec 2008 15:08:44 -0800 Received: from emailcorp3.jnpr.net ([66.129.254.13]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Dec 2008 15:08:43 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C954D2.EBBD444E" Subject: RE: CCAMP drafts for adoption Date: Tue, 2 Dec 2008 15:08:43 -0800 Message-ID: <7FA0C743C38E5340BFC2873488FA1E8E025DDF6C@emailcorp3.jnpr.net> In-Reply-To: <684158.95032.qm@web36805.mail.mud.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: CCAMP drafts for adoption thread-index: AclUzGKm7SmKujP5QIuH9IiMmVRPCQAA5n1w References: <001201c9549f$2dac4e50$d626fea9@china.huawei.com> <001601c954c0$d165bf10$470c7c0a@china.huawei.com> <7FA0C743C38E5340BFC2873488FA1E8E025DDF5E@emailcorp3.jnpr.net> <53CCFDD6E346CB43994852666C210E9105B70D91@esealmw116.eemea.ericsson.se> <7FA0C743C38E5340BFC2873488FA1E8E025DDF68@emailcorp3.jnpr.net> <684158.95032.qm@web36805.mail.mud.yahoo.com> From: Nitin Bahadur To: "Igor Bryskin" , "Attila Takacs" , X-OriginalArrivalTime: 02 Dec 2008 23:08:43.0935 (UTC) FILETIME=[EC323AF0:01C954D2] Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: ------_=_NextPart_001_01C954D2.EBBD444E Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi Igor, =20 I like your clear explanation (no pun intended). I understand your view-point....my views are as below... =20 > The difference is that GMPLS is a control plane, while OAM is supposed to work in the data plane. In transport =20 > networks control plane and data plane are separated. In fact, OAM should work without and should not depend upon=20 > control plane at all. You can not send Ping messages over lambda layer network connection, can you?=20 =20 Agreed.=20 =20 > On the other hand, you can use GMPLS to consistently configire OAM function on the connection NEs, and that's what =20 > these drafts as I understand are about. =20 I understand the motivation of these drafts and I totally agree with that. =20 > In other words, in MPLS , LSP Ping is OAM, while GMPLS can only automate OAM configuration, it can not relalize =20 > OAM on its own. I agree that LSP-Ping may not be the OAM mechanism for GMPLS LSPs. All I am saying is that LSP-Ping can be used to automate the OAM configuration. There is enough machinery available in lsp-ping to enable that. So why re-invent a new protocol? One could send lsp-ping messages (control-plane routed) containing the information needed to automate OAM. =20 Question: Isn't it simpler to use RSVP path messages to automate this ? Answer: Yes it looks simpler. =20 Question: Then why is Nitin opposed ? Answer: Because as this draft progresses, you will end up adding a whole bunch of TLVs/sub-TLVs and related error codes. And all these have nothing to do with a RSVP path message. The draft already has 3-4 sub-TLVs. In effect, the 2 drafts are defining a mini-OAM-boot-strapping protocol on top of RSVP path message. Nitin=20 =09 =09 =09 ________________________________ From: Nitin Bahadur To: Attila Takacs ; Adrian Farrel ; ccamp@ops.ietf.org Sent: Tuesday, December 2, 2008 5:01:11 PM Subject: RE: CCAMP drafts for adoption =09 =09 Hi Attlia, =09 What is the limitation of lsp-ping that prevents it from being applied to GMPLS? If an existing mechanism can be applied, then why not? If lsp-ping needs extensions to support GMPLS LSPs, feel free to make/specify those extensions. =09 Thanks Nitin =20 =09 > -----Original Message----- > From: Attila Takacs [mailto:Attila.Takacs@ericsson.com]=20 > Sent: Tuesday, December 02, 2008 1:52 PM > To: Nitin Bahadur; Adrian Farrel; ccamp@ops.ietf.org > Subject: RE: CCAMP drafts for adoption >=20 > Hi Nitin, >=20 > Please note that these mechanisms are proposed for GMPLS and=20 > as such to provide support for any data plane technology=20 > specific OAM mechanism. As you noted LSP Ping is for MPLS and=20 > BFD only. =20 >=20 > Best regards, > Attila >=20 > > -----Original Message----- > > From: owner-ccamp@ops.ietf.org > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Nitin Bahadur > > Sent: Tuesday, December 02, 2008 10:35 PM > > To: Adrian Farrel; ccamp@ops.ietf.org > > Subject: RE: CCAMP drafts for adoption > >=20 > >=20 > >=20 > > > > draft-takacs-ccamp-oam-configuration-fwk-01.txt > > > > draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt > >=20 > > Do not support either of these. > >=20 > > From the oam-config-fwk draft: > > > A new useful application of RSVP-TE is OAM configuration > > and control > > > for transport networks. > >=20 > > LSP-ping was designed as an OAM mechansim for MPLS LSPs. Why do we=20 > > need another mechanism? What are the limitations of lsp-ping that=20 > > warrant this new mechanism? > >=20 > > > When RSVP-TE is used for LSP establishment it is desirable > > to bind OAM > > > setup to connection establishment signalling to avoid two=20 > separate=20 > > > management/configuration steps > >=20 > > draft-ietf-bfd-mpls specifies how to use LSP-Ping for=20 > automatic setup=20 > > of BFD-based OAM. > > We should go along the same path for Ethernet OAM. > >=20 > > Thanks > > Nitin > >=20 > >=20 >=20 =09 =09 ------_=_NextPart_001_01C954D2.EBBD444E Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Hi Igor,
 
  I like your clear explanation (no pun = intended). I=20 understand your view-point....my views are as = below...
 
> The=20 difference is that GMPLS is a control plane, while OAM is supposed to = work in=20 the data plane. In transport  
> networks  control plane and data plane are separated. = In fact,=20 OAM should work without and should not depend upon 
>  control plane at all. = You can not=20 send Ping messages over lambda layer network connection, can you? 
 
Agreed. 
 
> =  On the=20 other hand, you can use GMPLS to consistently configire OAM function on = the=20 connection NEs, and that's what  
> these drafts as I = understand are=20 about.
 
I understand the motivation of these drafts and = I totally=20 agree with that.
 
> =  In=20 other words, in MPLS ,  LSP Ping is OAM, = while GMPLS=20 can only automate OAM configuration, it can not relalize  
>  OAM  on its own.
I agree that LSP-Ping may not be the OAM = mechanism for=20 GMPLS LSPs. All = I am saying is=20 that LSP-Ping can be used to automate the OAM configuration. There is = enough=20 machinery available in lsp-ping to enable that. So why re-invent a new = protocol?=20 One could send lsp-ping messages (control-plane routed) containing the=20 information needed to automate OAM.
 
Question: Isn't it simpler to use RSVP path = messages to=20 automate this ?
Answer: Yes it looks = simpler.
 
Question: Then why is Nitin = opposed ?
Answer: Because as this draft progresses, = you will end=20 up adding a whole bunch of TLVs/sub-TLVs and related error codes. And = all=20 these have nothing to do with a RSVP path message. The draft = already=20 has 3-4 sub-TLVs. In effect, the 2 drafts are defining a = mini-OAM-boot-strapping=20 protocol on top of RSVP path message.

Nitin 

From: Nitin Bahadur=20 <nitinb@juniper.net>
To: Attila Takacs=20 <Attila.Takacs@ericsson.com>; Adrian Farrel = <adrian@olddog.co.uk>;=20 ccamp@ops.ietf.org
Sent:=20 Tuesday, December 2, 2008 5:01:11 PM
Subject: RE: CCAMP drafts for=20 adoption


Hi Attlia,

  What is the = limitation of=20 lsp-ping that prevents it from being
applied to GMPLS?
If an = existing=20 mechanism can be applied, then why not? If lsp-ping = needs
extensions to=20 support GMPLS LSPs, feel free to make/specify=20 those
extensions.

Thanks
Nitin 

> = -----Original=20 Message-----
> From: Attila Takacs [mailto:Attila.Takacs@ericsson.com<= /A>]=20
> Sent: Tuesday, December 02, 2008 1:52 PM
> To: Nitin = Bahadur;=20 Adrian Farrel; ccamp@ops.ietf.org
> = Subject:=20 RE: CCAMP drafts for adoption
>
> Hi Nitin,
> =
>=20 Please note that these mechanisms are proposed for GMPLS and
> = as such=20 to provide support for any data plane technology
> specific OAM = mechanism. As you noted LSP Ping is for MPLS and
> BFD = only. =20
>
> Best regards,
> Attila
>
> >=20 -----Original Message-----
> > From: owner-ccamp@ops.ietf.org<= BR>>=20 > [mailto:owner-ccamp@ops.ietf.org]= On=20 Behalf Of Nitin Bahadur
> > Sent: Tuesday, December 02, 2008 = 10:35=20 PM
> > To: Adrian Farrel; ccamp@ops.ietf.org
> = >=20 Subject: RE: CCAMP drafts for adoption
> >
> > =
>=20 >
> > > >=20 draft-takacs-ccamp-oam-configuration-fwk-01.txt
> > > > = draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt
> >
> = > Do=20 not support either of these.
> >
> > From the=20 oam-config-fwk draft:
> > > A new useful application of = RSVP-TE is=20 OAM configuration
> > and control
> > > for = transport=20 networks.
> >
> > LSP-ping was designed as an OAM = mechansim=20 for MPLS LSPs. Why do we
> > need another mechanism? What = are the=20 limitations of lsp-ping that
> > warrant this new = mechanism?
>=20 >
> > > When RSVP-TE is used for LSP establishment it = is=20 desirable
> > to bind OAM
> > > setup to = connection=20 establishment signalling to avoid two
> separate
> > = >=20 management/configuration steps
> >
> > = draft-ietf-bfd-mpls=20 specifies how to use LSP-Ping for
> automatic setup
> = > of=20 BFD-based OAM.
> > We should go along the same path for = Ethernet=20 OAM.
> >
> > Thanks
> > Nitin
> > =
> >
> =


------_=_NextPart_001_01C954D2.EBBD444E-- From owner-ccamp@ops.ietf.org Tue Dec 2 15:44:47 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99EB228C207 for ; Tue, 2 Dec 2008 15:44:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.98 X-Spam-Level: X-Spam-Status: No, score=-101.98 tagged_above=-999 required=5 tests=[AWL=2.552, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G3Br+aHie0-P for ; Tue, 2 Dec 2008 15:44:46 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id DC6A33A692E for ; Tue, 2 Dec 2008 15:44:46 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7erk-0008rI-Nu for ccamp-data@psg.com; Tue, 02 Dec 2008 23:41:16 +0000 Received: from [217.32.164.138] (helo=smtp3.smtp.bt.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7erf-0008qZ-70 for ccamp@ops.ietf.org; Tue, 02 Dec 2008 23:41:13 +0000 Received: from E03MVA4-UKBR.domain1.systemhost.net ([193.113.197.105]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Dec 2008 23:41:09 +0000 Received: from 217.32.164.184 ([217.32.164.184]) by E03MVA4-UKBR.domain1.systemhost.net ([193.113.197.56]) via Exchange Front-End Server mail.bt.com ([193.113.197.28]) with Microsoft Exchange Server HTTP-DAV ; Tue, 2 Dec 2008 23:41:09 +0000 User-Agent: Microsoft-Entourage/12.14.0.081024 Date: Tue, 02 Dec 2008 18:41:04 -0500 Subject: Re: CCAMP drafts for adoption From: "Thomas D. Nadeau" To: David Allan , Nitin Bahadur , Message-ID: Thread-Topic: CCAMP drafts for adoption Thread-Index: AclUl6mpWAW2o7P/QfKhDBZKhoe9CgABkY3AAAiyQSAAAP4GoAAApjZgAAHEswAAAIicsAABvGDw In-Reply-To: <87AC5F88F03E6249AEA68D40BD3E00BE168324AD@zcarhxm2.corp.nortel.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 02 Dec 2008 23:41:09.0988 (UTC) FILETIME=[74225A40:01C954D7] Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Dave, As an operator with a very big deployment of MPLS and a lot of money invested in OSS to manage said network, I do not want a different mechanism to the one that has been deployed today to control OAM for any MPLS networks, MPLS-TP included. --Tom On 12/2/08 6:01 PM, "David Allan" wrote: > HI Nitin: > > Thanks for replying.... > > >> David, all that I am asking is that one can use the basic-bare-bones > definitions in lsp-ping to setup the Ethernet OAM >> params. I am not talking about applicability nor I am saying that one > needs to use ping and trace based off lsp-ping for > PBB-TE LSPs. > > But this still requires implementing a new protocol where it does not > already exist, which also requires a *new* bare bones definition... > >> We have a whole bunch of stuff defined in RSVP. Obviously some of them > are not applicable for GMPLS LSPs. But that does > not mean that we go > define G-RSVP (for GMPLS LSPs). > > Isn't that CCAMPs mandate? > > > >> I am not asking you to use lsp-ping for LB/LT. I agree that ethernet > OAM already has that and indeed once should use >> that. I am just saying that the setup can be done using lsp-ping. > > I think the point was GMPLS applies to a lot of technologies that cannot > do LSP-PING in the first place, which means such a signalling extension > will be required nonetheless... > > >> LSP-Ping is already non-IP from a *forwarding* perspective. LSP-Ping > has a reply-mode of *application channel* which can > be used for things > like bi-directional LSPs. So for MPLS-TP LSPs, the lsp-ping replies > would go on the LSP reverse path > (label-switched and not IP > forwarded). > > OK, I can see that such an approach could be made to work and would be > desirable to some. On that basis, can I suggest you withdraw your > objections to the Eth-Oam draft and move the TP parts of this discussion > over to the MPLS list? That would seem appropriate... > > Cheers > Dave > > From owner-ccamp@ops.ietf.org Tue Dec 2 15:44:48 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 768F23A692E for ; Tue, 2 Dec 2008 15:44:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.963 X-Spam-Level: X-Spam-Status: No, score=-4.963 tagged_above=-999 required=5 tests=[AWL=-0.467, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xM-oneSdxL9O for ; Tue, 2 Dec 2008 15:44:47 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 772F528C10E for ; Tue, 2 Dec 2008 15:44:47 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7erh-0008qw-Gx for ccamp-data@psg.com; Tue, 02 Dec 2008 23:41:13 +0000 Received: from [64.18.2.177] (helo=exprod7og112.obsmtp.com) by psg.com with smtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7erb-0008qA-F8 for ccamp@ops.ietf.org; Tue, 02 Dec 2008 23:41:09 +0000 Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKSTXHkcZUb1qXJzT5H6Z445kAe9WTzwFP@postini.com; Tue, 02 Dec 2008 15:41:07 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.71) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.311.2; Tue, 2 Dec 2008 15:37:47 -0800 Received: from emailcorp3.jnpr.net ([66.129.254.13]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Dec 2008 15:37:46 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: CCAMP drafts for adoption Date: Tue, 2 Dec 2008 15:37:46 -0800 Message-ID: <7FA0C743C38E5340BFC2873488FA1E8E025DDF6E@emailcorp3.jnpr.net> In-Reply-To: <87AC5F88F03E6249AEA68D40BD3E00BE168324AD@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: CCAMP drafts for adoption thread-index: AclUl6mpWAW2o7P/QfKhDBZKhoe9CgABkY3AAAiyQSAAAP4GoAAApjZgAAHEswAAAIicsAAA2bWA References: <001201c9549f$2dac4e50$d626fea9@china.huawei.com> <001601c954c0$d165bf10$470c7c0a@china.huawei.com> <7FA0C743C38E5340BFC2873488FA1E8E025DDF5E@emailcorp3.jnpr.net> <87AC5F88F03E6249AEA68D40BD3E00BE168324A4@zcarhxm2.corp.nortel.com> <7FA0C743C38E5340BFC2873488FA1E8E025DDF6B@emailcorp3.jnpr.net> <87AC5F88F03E6249AEA68D40BD3E00BE168324AD@zcarhxm2.corp.nortel.com> From: Nitin Bahadur To: "David Allan" , X-OriginalArrivalTime: 02 Dec 2008 23:37:46.0961 (UTC) FILETIME=[FB1EE410:01C954D6] Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Hi David, > > David, all that I am asking is that one can use the basic-bare-bones > definitions in lsp-ping to setup the Ethernet OAM=20 > > params. I am not talking about applicability nor I am=20 > saying that one > needs to use ping and trace based off lsp-ping for > PBB-TE LSPs.=20 >=20 > But this still requires implementing a new protocol where it=20 > does not already exist, I agree. It does require implementing lsp-ping. But the way these 2 drafts are going, they will end up defining a new mini-oam-boot-strapping protocol on top of RSVP path messages. And once we have a precedence, it will just keep growing. I am basically against using RSVP path message as an OAM related PDU transfer agent. The drafts already specify 3-4 sub-TLVs and a bunch of error codes. This list can grow. The framework draft is generic in nature. So tomorrrow I can use BFD or XXX on top of RSVP (why just ethernet-oam) and I can add 10 more TLVs and 5 more error codes. It's all about keeping RSVP clean. Your requirement is to automate OAM on a GMPLS LSP. Why dirty this poor Path msg. If you do not wish to use Lsp-ping (for whatever reason)...I recommend using something other than a RSVP path msg. > which also requires a *new* bare=20 > bones definition... I think that would be easy. You just need to send the lsp-ping msg=20 along the control-plane. The LSP details can be put in the existing defined TLVs. The ethernet OAM details can be directly copied from these new drafts into a lsp-ping based draft. > >=20 > > I am not asking you to use lsp-ping for LB/LT. I agree that ethernet > OAM already has that and indeed once should use=20 > > that. I am just saying that the setup can be done using lsp-ping. >=20 > I think the point was GMPLS applies to a lot of technologies=20 > that cannot do LSP-PING in the first place, which means such=20 > a signalling extension will be required nonetheless... As I said earlier, use LSP-Ping not for OAM, but for signaling the OAM params. Given that you are using RSVP for signaling the GMPLS LSP via the control plane, you can use LSP-Ping (via control plane) to do the OAM signaling. > can I suggest you=20 > withdraw your objections to the Eth-Oam draft and move the TP=20 > parts of this discussion over to the MPLS list? My main objections to the Eth-oam drafts are not TP related.=20 They are related to using RSVP Path as a transmission mechanism for=20 OAM setup. OAM is complex and tomorrow we might need more TLVs to indicate remote failure=20 or some other condition via the control plane.=20 Dave, you are the co-author of draft-ietf-pwe3-oam-msg-map. Look at the amount of stuff that has gone in there. As a side-note, I am just *a person*. It's the ccamp wg mailing list that needs to say *yes*/*no*. It's all rough consensus right? Thanks Nitin From owner-ccamp@ops.ietf.org Tue Dec 2 15:58:25 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66C453A6A31 for ; Tue, 2 Dec 2008 15:58:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.704 X-Spam-Level: X-Spam-Status: No, score=-0.704 tagged_above=-999 required=5 tests=[AWL=-1.276, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_LOW=-1, RCVD_NUMERIC_HELO=2.067, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 81CWih2n7FeK for ; Tue, 2 Dec 2008 15:58:24 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 87A9B3A69BC for ; Tue, 2 Dec 2008 15:58:24 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7f4g-0009WA-33 for ccamp-data@psg.com; Tue, 02 Dec 2008 23:54:38 +0000 Received: from [217.32.164.150] (helo=smtp2.smtp.bt.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7f4b-0009VO-74 for ccamp@ops.ietf.org; Tue, 02 Dec 2008 23:54:35 +0000 Received: from E03MVA4-UKBR.domain1.systemhost.net ([193.113.197.105]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Dec 2008 23:54:32 +0000 Received: from 217.32.164.184 ([217.32.164.184]) by E03MVA4-UKBR.domain1.systemhost.net ([193.113.197.56]) via Exchange Front-End Server mail.bt.com ([193.113.197.28]) with Microsoft Exchange Server HTTP-DAV ; Tue, 2 Dec 2008 23:54:31 +0000 User-Agent: Microsoft-Entourage/12.14.0.081024 Date: Tue, 02 Dec 2008 18:54:27 -0500 Subject: Re: CCAMP drafts for adoption From: "Thomas D. Nadeau" To: Don Fedyk , Nitin Bahadur , Adrian Farrel , Message-ID: Thread-Topic: CCAMP drafts for adoption Thread-Index: AclUl6mpWAW2o7P/QfKhDBZKhoe9CgABkY3AAAiyQSAAAP4GoAABt/WgAANvmB4= In-Reply-To: <34B3EAA5B3066A42914D28C5ECF5FEA417C1D2F4@zrtphxm2.corp.nortel.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 02 Dec 2008 23:54:32.0019 (UTC) FILETIME=[522E9230:01C954D9] Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: On 12/2/08 5:32 PM, "Don Fedyk" wrote: > Hi Nitin > >> -----Original Message----- >> From: owner-ccamp@ops.ietf.org >> [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Nitin Bahadur >> >> >>>> draft-takacs-ccamp-oam-configuration-fwk-01.txt >>>> draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt >> >> Do not support either of these. >> >> From the oam-config-fwk draft: >>> A new useful application of RSVP-TE is OAM configuration >>> and control for transport networks. >> >> LSP-ping was designed as an OAM mechansim for MPLS LSPs. Why >> do we need >> another mechanism? What are the limitations of lsp-ping that warrant >> this new mechanism? > > These drafts support configuration of data plane OAM functions when you > are using RSVP-TE to setup the paths. The alternative is operator > configuration. It has nothing to do with LSP Ping. > >> >>> When RSVP-TE is used for LSP establishment it is desirable to bind >>> OAM setup to connection establishment signalling to avoid two >>> separate management/configuration steps >> >> draft-ietf-bfd-mpls specifies how to use LSP-Ping for >> automatic setup of >> BFD-based OAM. > > So LSP Ping sets up BFD? Interesting. While I can see this might be > useful in the case of LDP when debugging a problem you do have issues > with LSP-Ping reaching all path combinations and certain error > scenarios. I don't think this is a comprehensive mechanism. Don, LSP ping is used to "bootstrap" BFD for MPLS networks. It is a perfectly sound method of solving the problem it sought to solve. Please take a look at this draft-ietf-bfd-mpls-07 for a description of how this works if you are unfamiliar. > This is clearly different than what we are specifying in the Ethernet > OAM case. While not a comprehensive mechanism for doing Ethernet OAM, don't you think that defining how Ethernet OAM works (or is configured) should be done by the IEEE? What you are proposing here by combining these different things together is what at least smells like what was thrown out in L2VPN a number of years ago due to a layer violation when it was tried for Ethernet/VPLS PWs. --Tom > Regards, > Don > > > >> We should go along the same path for Ethernet OAM. >> >> Thanks >> Nitin >> >> > From owner-ccamp@ops.ietf.org Tue Dec 2 16:46:04 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42A4228C23A for ; Tue, 2 Dec 2008 16:46:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.495 X-Spam-Level: X-Spam-Status: No, score=-4.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xoC1WnbQFMlm for ; Tue, 2 Dec 2008 16:46:03 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 32AF728C227 for ; Tue, 2 Dec 2008 16:46:03 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7fni-000Cok-JW for ccamp-data@psg.com; Wed, 03 Dec 2008 00:41:10 +0000 Received: from [47.129.242.57] (helo=zcars04f.nortel.com) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7fnZ-000CoI-SP for ccamp@ops.ietf.org; Wed, 03 Dec 2008 00:41:07 +0000 Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id mB30eu428515; Wed, 3 Dec 2008 00:40:57 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: CCAMP drafts for adoption Date: Tue, 2 Dec 2008 19:40:55 -0500 Message-ID: <87AC5F88F03E6249AEA68D40BD3E00BE168324AF@zcarhxm2.corp.nortel.com> In-Reply-To: <7FA0C743C38E5340BFC2873488FA1E8E025DDF6E@emailcorp3.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: CCAMP drafts for adoption Thread-Index: AclUl6mpWAW2o7P/QfKhDBZKhoe9CgABkY3AAAiyQSAAAP4GoAAApjZgAAHEswAAAIicsAAA2bWAAAKAO+A= References: <001201c9549f$2dac4e50$d626fea9@china.huawei.com> <001601c954c0$d165bf10$470c7c0a@china.huawei.com> <7FA0C743C38E5340BFC2873488FA1E8E025DDF5E@emailcorp3.jnpr.net> <87AC5F88F03E6249AEA68D40BD3E00BE168324A4@zcarhxm2.corp.nortel.com> <7FA0C743C38E5340BFC2873488FA1E8E025DDF6B@emailcorp3.jnpr.net> <87AC5F88F03E6249AEA68D40BD3E00BE168324AD@zcarhxm2.corp.nortel.com> <7FA0C743C38E5340BFC2873488FA1E8E025DDF6E@emailcorp3.jnpr.net> From: "David Allan" To: "Nitin Bahadur" , Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Hi Nitin: My reaction is that spreading state over a number of protocols may keep one superficially simple but drives up the total cost of the solution...from the POV of lines of code, amount to test, amount of state, additional race conditions, delayed setup time etc. so is a specious optimization.... If the path is not up until OAM says so, it is useful to get there in as few transactions as possible... My 2 cents. Dave =20 -----Original Message----- From: Nitin Bahadur [mailto:nitinb@juniper.net]=20 Sent: Tuesday, December 02, 2008 6:38 PM To: Allan, David (CAR:NS00); ccamp@ops.ietf.org Subject: RE: CCAMP drafts for adoption Hi David, > > David, all that I am asking is that one can use the basic-bare-bones > definitions in lsp-ping to setup the Ethernet OAM > > params. I am not talking about applicability nor I am > saying that one > needs to use ping and trace based off lsp-ping for > PBB-TE LSPs.=20 >=20 > But this still requires implementing a new protocol where it does not=20 > already exist, I agree. It does require implementing lsp-ping. But the way these 2 drafts are going, they will end up defining a new mini-oam-boot-strapping protocol on top of RSVP path messages. And once we have a precedence, it will just keep growing. I am basically against using RSVP path message as an OAM related PDU transfer agent. The drafts already specify 3-4 sub-TLVs and a bunch of error codes. This list can grow. The framework draft is generic in nature. So tomorrrow I can use BFD or XXX on top of RSVP (why just ethernet-oam) and I can add 10 more TLVs and 5 more error codes. It's all about keeping RSVP clean. Your requirement is to automate OAM on a GMPLS LSP. Why dirty this poor Path msg. If you do not wish to use Lsp-ping (for whatever reason)...I recommend using something other than a RSVP path msg. > which also requires a *new* bare > bones definition... I think that would be easy. You just need to send the lsp-ping msg along the control-plane. The LSP details can be put in the existing defined TLVs. The ethernet OAM details can be directly copied from these new drafts into a lsp-ping based draft. > >=20 > > I am not asking you to use lsp-ping for LB/LT. I agree that ethernet > OAM already has that and indeed once should use > > that. I am just saying that the setup can be done using lsp-ping. >=20 > I think the point was GMPLS applies to a lot of technologies that=20 > cannot do LSP-PING in the first place, which means such a signalling=20 > extension will be required nonetheless... As I said earlier, use LSP-Ping not for OAM, but for signaling the OAM params. Given that you are using RSVP for signaling the GMPLS LSP via the control plane, you can use LSP-Ping (via control plane) to do the OAM signaling. > can I suggest you > withdraw your objections to the Eth-Oam draft and move the TP parts of > this discussion over to the MPLS list? My main objections to the Eth-oam drafts are not TP related.=20 They are related to using RSVP Path as a transmission mechanism for OAM setup. OAM is complex and tomorrow we might need more TLVs to indicate remote failure or some other condition via the control plane.=20 Dave, you are the co-author of draft-ietf-pwe3-oam-msg-map. Look at the amount of stuff that has gone in there. As a side-note, I am just *a person*. It's the ccamp wg mailing list that needs to say *yes*/*no*. It's all rough consensus right? Thanks Nitin From owner-ccamp@ops.ietf.org Tue Dec 2 20:13:32 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 024E13A6960 for ; Tue, 2 Dec 2008 20:13:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.036 X-Spam-Level: X-Spam-Status: No, score=-0.036 tagged_above=-999 required=5 tests=[AWL=-1.081, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EREEvbLaRN-w for ; Tue, 2 Dec 2008 20:13:31 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2D6F93A67D7 for ; Tue, 2 Dec 2008 20:13:31 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7j1f-000LxG-AI for ccamp-data@psg.com; Wed, 03 Dec 2008 04:07:47 +0000 Received: from [64.78.150.133] (helo=dog.tcb.net) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7j1b-000Lx0-0s for ccamp@ops.ietf.org; Wed, 03 Dec 2008 04:07:44 +0000 Received: by dog.tcb.net (Postfix, from userid 0) id BC6AE36802A; Tue, 2 Dec 2008 21:07:41 -0700 (MST) Received: from mbp.castlepoint.net (71-215-87-93.hlrn.qwest.net [71.215.87.93]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Tue, 02 Dec 2008 21:07:41 -0700 (MST) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=71.215.87.93; client-port=3115; syn-fingerprint=65535:55:1:64:M1460,N,W3,N,N,T,S MacOS 10.4.8; data-bytes=0 Cc: Nitin Bahadur , Adrian Farrel , Message-Id: From: Shane Amante To: Thomas D. Nadeau In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Subject: Re: CCAMP drafts for adoption Date: Tue, 2 Dec 2008 21:07:42 -0700 References: X-Mailer: Apple Mail (2.929.2) Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Do not support. -shane On Dec 2, 2008, at 2:49 PM, Thomas D. Nadeau wrote: > > I agree with Nitin and do not support the adoption of these drafts. > > --Tom > > > > On 12/2/08 4:35 PM, "Nitin Bahadur" wrote: > >>>> draft-takacs-ccamp-oam-configuration-fwk-01.txt >>>> draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt >> >> Do not support either of these. >> >> From the oam-config-fwk draft: >>> A new useful application of RSVP-TE is OAM configuration >>> and control for transport networks. >> >> LSP-ping was designed as an OAM mechansim for MPLS LSPs. Why do we >> need >> another mechanism? What are the limitations of lsp-ping that warrant >> this new mechanism? >> >>> When RSVP-TE is used for LSP establishment it is desirable to bind >>> OAM setup to connection establishment signalling to avoid two >>> separate management/configuration steps >> >> draft-ietf-bfd-mpls specifies how to use LSP-Ping for automatic >> setup of >> BFD-based OAM. >> We should go along the same path for Ethernet OAM. >> >> Thanks >> Nitin >> > > From owner-ccamp@ops.ietf.org Tue Dec 2 20:38:20 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29A043A699A for ; Tue, 2 Dec 2008 20:38:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.495 X-Spam-Level: X-Spam-Status: No, score=-4.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HwOlLohnHzye for ; Tue, 2 Dec 2008 20:38:17 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6FD4D3A67AF for ; Tue, 2 Dec 2008 20:38:17 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7jRV-000NGJ-1O for ccamp-data@psg.com; Wed, 03 Dec 2008 04:34:29 +0000 Received: from [47.129.242.57] (helo=zcars04f.nortel.com) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7jRQ-000NFw-1u for ccamp@ops.ietf.org; Wed, 03 Dec 2008 04:34:26 +0000 Received: from zrtphxm2.corp.nortel.com (zrtphxm2.corp.nortel.com [47.140.202.51]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id mB34YFw14342; Wed, 3 Dec 2008 04:34:15 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: CCAMP drafts for adoption Date: Tue, 2 Dec 2008 23:34:13 -0500 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA417C1D479@zrtphxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: CCAMP drafts for adoption Thread-Index: AclUl6mpWAW2o7P/QfKhDBZKhoe9CgABkY3AAAiyQSAAAP4GoAABt/WgAANvmB4ACXDVkA== References: <34B3EAA5B3066A42914D28C5ECF5FEA417C1D2F4@zrtphxm2.corp.nortel.com> From: "Don Fedyk" To: "Thomas D. Nadeau" , "Nitin Bahadur" , "Adrian Farrel" , Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Hi Tom Please see inline,=20 >On 12/2/08 5:32 PM, "Don Fedyk" wrote: > >> Hi Nitin=20 >>=20 >>> -----Original Message----- >>> From: owner-ccamp@ops.ietf.org >>> [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Nitin Bahadur >>>=20 >>>=20 >>>>> draft-takacs-ccamp-oam-configuration-fwk-01.txt >>>>> draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt >>>=20 >>> Do not support either of these. >>>=20 >>> From the oam-config-fwk draft: >>>> A new useful application of RSVP-TE is OAM configuration >>>> and control for transport networks. >>>=20 >>> LSP-ping was designed as an OAM mechansim for MPLS LSPs. Why >>> do we need >>> another mechanism? What are the limitations of lsp-ping that warrant >>> this new mechanism? >>=20 >> These drafts support configuration of data plane OAM functions when you >> are using RSVP-TE to setup the paths. The alternative is operator >> configuration. It has nothing to do with LSP Ping. >>=20 >>>=20 >>>> When RSVP-TE is used for LSP establishment it is desirable to bind >>>> OAM setup to connection establishment signalling to avoid two >>>> separate management/configuration steps >>>=20 >>> draft-ietf-bfd-mpls specifies how to use LSP-Ping for >>> automatic setup of >>> BFD-based OAM. >>=20 >> So LSP Ping sets up BFD? Interesting. While I can see this might be >> useful in the case of LDP when debugging a problem you do have issues >> with LSP-Ping reaching all path combinations and certain error >> scenarios. I don't think this is a comprehensive mechanism. > > Don, > > LSP ping is used to "bootstrap" BFD for MPLS networks. It is a perfectly >sound method of solving the problem it sought to solve. Please take a look >at this draft-ietf-bfd-mpls-07 for a description of how this works if you >are unfamiliar. =20 Tom, When I read this draft what I read is that an MPLS LSP may take one or=20 more paths and that a BFD session is set up for one or more of these paths.=20 Since the network may change, the MPLS LSP may vary the number of paths=20 it takes from time to time (ECMP may come and go). So if you have a=20 problem you may fined you have not set up the BFD session on a LSP path=20 or there may well be even 2 BFD sessions running on what is now a single LSP path. In a big network I think this may be a bit of an issue.=20 > >> This is clearly different than what we are specifying in the Ethernet >> OAM case.=20 > > While not a comprehensive mechanism for doing Ethernet OAM, don't you >think that defining how Ethernet OAM works (or is configured) should be done >by the IEEE? What you are proposing here by combining these different >things together is what at least smells like what was thrown out in L2VPN a >number of years ago due to a layer violation when it was tried for >Ethernet/VPLS PWs.=20 We absolutely have left OAM for the IEEE. In fact the whole data plane=20 and OAM is specified in the IEEE. All we are proposing is to optionally=20 signal a IEEE OAM profile of the type of MIPs and MEPs on the connection.=20 This is the point of GMPLS. Generalized control of other technologies. RSVP-TE sessions that don't use these objects would use normal RSVP-TE=20 processing. That is why we have extensible protocols. As Attila points=20 out OAM for other technologies such as optical could also use these=20 GMPLS mechanisms.=20 When you setup paths and CCM in this manner there is no doubt it is=20 protecting the traffic path.=20 Regards, Don=20 > > --Tom From jardannessz@ab-aegon.hu Tue Dec 2 22:58:10 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD5D63A699A for ; Tue, 2 Dec 2008 22:58:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -22.05 X-Spam-Level: X-Spam-Status: No, score=-22.05 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UWwF8p5uPtAl for ; Tue, 2 Dec 2008 22:58:10 -0800 (PST) Received: from aafes.com (unknown [59.161.11.253]) by core3.amsl.com (Postfix) with SMTP id 168293A67A5 for ; Tue, 2 Dec 2008 22:57:57 -0800 (PST) To: Subject: Your order From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081203065800.168293A67A5@core3.amsl.com> Date: Tue, 2 Dec 2008 22:57:57 -0800 (PST) Click here to view as a webpage. From owner-ccamp@ops.ietf.org Tue Dec 2 23:37:21 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7142E3A6B0F for ; Tue, 2 Dec 2008 23:37:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.698 X-Spam-Level: X-Spam-Status: No, score=-4.698 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yItblu7U4fBF for ; Tue, 2 Dec 2008 23:37:20 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 90D473A6A9B for ; Tue, 2 Dec 2008 23:37:20 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7mCo-0006PT-PC for ccamp-data@psg.com; Wed, 03 Dec 2008 07:31:30 +0000 Received: from [193.180.251.62] (helo=mailgw4.ericsson.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7mCk-0006P7-2P for ccamp@ops.ietf.org; Wed, 03 Dec 2008 07:31:28 +0000 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 03AED211E1; Wed, 3 Dec 2008 08:31:24 +0100 (CET) X-AuditID: c1b4fb3e-aff88bb00000537b-5a-493635cb98af Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id D8357211DE; Wed, 3 Dec 2008 08:31:23 +0100 (CET) Received: from EITRMMW021.eemea.ericsson.se ([141.137.48.176]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Dec 2008 08:31:21 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 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: CCAMP drafts for adoption Date: Wed, 3 Dec 2008 08:31:18 +0100 Message-ID: In-Reply-To: <2089B64D43144AEEA390F5C4C7232087@your029b8cecfe> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: CCAMP drafts for adoption Thread-Index: AclUl869tPqn4vzaQ4+mNJcTBH2XXgAgUJ7w From: "Daniele Ceccarelli" To: "Adrian Farrel" , X-OriginalArrivalTime: 03 Dec 2008 07:31:21.0816 (UTC) FILETIME=[23B1AD80:01C95519] X-Brightmail-Tracker: AAAAAA== Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: I support all of them. Cheers, Daniele -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On = Behalf Of Adrian Farrel Sent: marted=EC 2 dicembre 2008 17.02 To: ccamp@ops.ietf.org Subject: CCAMP drafts for adoption Hi, Can you please express your opinion on the adoption of the following = three=20 drafts as WG drafts. Thanks, Adrian draft-takacs-ccamp-oam-configuration-fwk-01.txt draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt draft-bernstein-ccamp-wson-encode-01.txt (to become -rwa-encode-00) Cheers, Adrian and Deborah=20 From owner-ccamp@ops.ietf.org Tue Dec 2 23:56:13 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4A393A67F0 for ; Tue, 2 Dec 2008 23:56:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.661 X-Spam-Level: X-Spam-Status: No, score=0.661 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_DK=1.009, HELO_MISMATCH_DK=1.7, RCVD_IN_DNSWL_LOW=-1, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 778adGmDO2BL for ; Tue, 2 Dec 2008 23:56:13 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DD5063A6B25 for ; Tue, 2 Dec 2008 23:56:07 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7mXE-0007Qo-Tj for ccamp-data@psg.com; Wed, 03 Dec 2008 07:52:36 +0000 Received: from [194.192.15.188] (helo=dkcphmx24.softcom.dk) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7mXA-0007QS-3k for ccamp@ops.ietf.org; Wed, 03 Dec 2008 07:52:34 +0000 Received: (qmail 16595 invoked by uid 74); 3 Dec 2008 07:52:28 -0000 Received: from mail.acreo.se (217.151.195.216) by dkcphmx24.softcom.dk (envelope-from ) with ESMTP. tag msg.1228290748.600526.23557 (Processed in 0.111243 secs); 03 Dec 2008 07:52:28 -0000 X-SoftScan-Status: clean X-Secure-TLS: Yes, message received through TLS by dkcphmx24.softcom.dk (RC4-MD5) Received: from mail.acreo.se (HELO mail.acreo.se) (217.151.195.216) by dkcphmx24.softcom.dk over TLS secured channel with (RC4-MD5 encrypted) ESMTPS; Wed, 03 Dec 2008 08:52:28 +0100 Received: from acreoexc01.ad.acreo.se ([10.4.148.12]) by acreoexc01.ad.acreo.se ([10.4.148.12]) with mapi; Wed, 3 Dec 2008 08:52:28 +0100 From: Anders Gavler To: Adrian Farrel , "ccamp@ops.ietf.org" Date: Wed, 3 Dec 2008 08:52:26 +0100 Subject: RE: CCAMP drafts for adoption Thread-Topic: CCAMP drafts for adoption Thread-Index: AclUmE0cpTY/XL5TQ8SDX7qklx93vQAg7/Ag Message-ID: <73B74934786FBB4F951B5F99724CEB603DD8291E15@acreoexc01.ad.acreo.se> References: <2089B64D43144AEEA390F5C4C7232087@your029b8cecfe> In-Reply-To: <2089B64D43144AEEA390F5C4C7232087@your029b8cecfe> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: sv-SE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Yes to all three. /Anders > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behal= f > Of Adrian Farrel > Sent: den 2 december 2008 17:02 > To: ccamp@ops.ietf.org > Subject: CCAMP drafts for adoption > > Hi, > > Can you please express your opinion on the adoption of the following thre= e > drafts as WG drafts. > > Thanks, > Adrian > > draft-takacs-ccamp-oam-configuration-fwk-01.txt > draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt > draft-bernstein-ccamp-wson-encode-01.txt (to become -rwa-encode-00) > > Cheers, > Adrian and Deborah > > > > From owner-ccamp@ops.ietf.org Wed Dec 3 00:42:02 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 448533A6B16 for ; Wed, 3 Dec 2008 00:42:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.396 X-Spam-Level: X-Spam-Status: No, score=-101.396 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id usPvaue-c+-L for ; Wed, 3 Dec 2008 00:41:56 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id D4D103A699A for ; Wed, 3 Dec 2008 00:41:56 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7nD0-0009WE-LP for ccamp-data@psg.com; Wed, 03 Dec 2008 08:35:46 +0000 Received: from [119.145.14.67] (helo=szxga04-in.huawei.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7nCv-0009Vw-Q1 for ccamp@ops.ietf.org; Wed, 03 Dec 2008 08:35:43 +0000 Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KBA00C64L6505@szxga04-in.huawei.com> for ccamp@ops.ietf.org; Wed, 03 Dec 2008 16:34:53 +0800 (CST) Received: from huawei.com ([172.17.1.36]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KBA007OLL65M2@szxga04-in.huawei.com> for ccamp@ops.ietf.org; Wed, 03 Dec 2008 16:34:53 +0800 (CST) Received: from [172.24.1.6] (Forwarded-For: [156.106.216.151]) by szxmc04-in.huawei.com (mshttpd); Wed, 03 Dec 2008 09:34:52 +0100 Date: Wed, 03 Dec 2008 09:34:52 +0100 From: longhao 48034 Subject: Re:CCAMP drafts for adoption In-reply-to: <2089B64D43144AEEA390F5C4C7232087@your029b8cecfe> To: Adrian Farrel Cc: ccamp@ops.ietf.org Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: quoted-printable Content-disposition: inline X-Accept-Language: zh-CN References: <2089B64D43144AEEA390F5C4C7232087@your029b8cecfe> Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Hi=2C I support all of the three drafts to become WG drafts=2E When I read the mailing discussion=2C some experts opposed the two I-Ds r= elated to oam configuration=3A draft-takacs-ccamp-oam-configuration-fwk-01=2Etxt draft-takacs-ccamp-rsvp-te-eth-oam-ext-03=2Etxt My understanding is these two I-Ds are very useful for oam deployment=2E = As you know=2C there are many things are needed to be preconfigured befor= e you activate the oam function=2E This is actually a tough thing for use= rs because the configuration involoves all the nodes on the lsp and so ma= ny parameters=2C e=2Eg=2E MEG level=2C MEP ID=2C MD name =2C MA name =2E=2E= =2E=2E=2E Some experts argues that this will lead to add more TLVs to RSV= P-TE=2E However=2C if looking at the LSP setup=2C it is also a way to simplify the configuration=2E LSP setup= and OAM configuration are similar thing=2E They are both the work of REV= P-TE signaling=2E As this=2C I support the two I-Ds=2E Thanks=2C Hao ----- =D4=AD=D3=CA=BC=FE ----- =B7=A2=BC=FE=C8=CB=3A Adrian Farrel =3Cadrian=40olddog=2Eco=2Euk=3E =C8=D5=C6=DA=3A =D0=C7=C6=DA=B6=FE=2C =CA=AE=B6=FE=D4=C2 2=C8=D5=2C 2008 = =CF=C2=CE=E75=3A03 =D6=F7=CC=E2=3A CCAMP drafts for adoption =CA=D5=BC=FE=C8=CB=3A ccamp=40ops=2Eietf=2Eorg =3E Hi=2C =3E = =3E Can you please express your opinion on the adoption of the = =3E following three = =3E drafts as WG drafts=2E =3E = =3E Thanks=2C =3E Adrian =3E = =3E draft-takacs-ccamp-oam-configuration-fwk-01=2Etxt =3E draft-takacs-ccamp-rsvp-te-eth-oam-ext-03=2Etxt =3E draft-bernstein-ccamp-wson-encode-01=2Etxt (to become -rwa-encode-00)= =3E = =3E Cheers=2C =3E Adrian and Deborah = =3E = =3E = =3E = =3E From owner-ccamp@ops.ietf.org Wed Dec 3 01:04:45 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC81A3A6B33 for ; Wed, 3 Dec 2008 01:04:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.593 X-Spam-Level: X-Spam-Status: No, score=-1.593 tagged_above=-999 required=5 tests=[AWL=-0.546, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ogJiGTRCaC41 for ; Wed, 3 Dec 2008 01:04:45 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F1A563A6B07 for ; Wed, 3 Dec 2008 01:04:44 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7nbP-000Ai4-Hx for ccamp-data@psg.com; Wed, 03 Dec 2008 09:00:59 +0000 Received: from [156.106.192.41] (helo=protext01.itu.ch) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7nbF-000Aha-Ol for ccamp@ops.ietf.org; Wed, 03 Dec 2008 09:00:52 +0000 Received: from protext01.itu.ch ([156.106.192.41]) by protext01.itu.ch with Microsoft SMTPSVC(5.0.2195.6713); Wed, 3 Dec 2008 10:00:48 +0100 Received: From mail6.itu.ch ([156.106.192.22]) by protext01.itu.ch (WebShield SMTP v4.5 MR3) id 1228294847632; Wed, 3 Dec 2008 10:00:47 +0100 Received: from your029b8cecfe ([156.106.216.176]) by mail6.itu.ch (8.14.3/8.14.3) with ESMTP id mB390jO5387475; Wed, 3 Dec 2008 10:00:46 +0100 (MET) Message-ID: Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Nitin Bahadur" , References: <001201c9549f$2dac4e50$d626fea9@china.huawei.com> <001601c954c0$d165bf10$470c7c0a@china.huawei.com> <7FA0C743C38E5340BFC2873488FA1E8E025DDF5E@emailcorp3.jnpr.net> Subject: OAM control Date: Wed, 3 Dec 2008 09:00:42 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (mail6.itu.ch [156.106.192.22]); Wed, 03 Dec 2008 10:00:47 +0100 (MET) X-OriginalArrivalTime: 03 Dec 2008 09:00:48.0398 (UTC) FILETIME=[A26D1AE0:01C95525] Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Hi Nitin, Have you tried running LSP Ping on a lambda? In practice, many data plane technologies have existing OAM techniques, and it is these that the draft proposes to control. Are you suggesting that the LSP Ping echo request should be sent out of band and used to manage data plane OAM? Thanks, Adrian ----- Original Message ----- From: "Nitin Bahadur" To: "Adrian Farrel" ; Sent: Tuesday, December 02, 2008 9:35 PM Subject: RE: CCAMP drafts for adoption > > draft-takacs-ccamp-oam-configuration-fwk-01.txt > > draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt Do not support either of these. >From the oam-config-fwk draft: > A new useful application of RSVP-TE is OAM configuration > and control for transport networks. LSP-ping was designed as an OAM mechansim for MPLS LSPs. Why do we need another mechanism? What are the limitations of lsp-ping that warrant this new mechanism? > When RSVP-TE is used for LSP establishment it is desirable to bind > OAM setup to connection establishment signalling to avoid two > separate management/configuration steps draft-ietf-bfd-mpls specifies how to use LSP-Ping for automatic setup of BFD-based OAM. We should go along the same path for Ethernet OAM. Thanks Nitin From owner-ccamp@ops.ietf.org Wed Dec 3 02:01:07 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FEF43A685D for ; Wed, 3 Dec 2008 02:01:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l6uqzt4Ti+eP for ; Wed, 3 Dec 2008 02:01:06 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 507D03A68B1 for ; Wed, 3 Dec 2008 02:00:52 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7oT2-000Dgy-8L for ccamp-data@psg.com; Wed, 03 Dec 2008 09:56:24 +0000 Received: from [119.145.14.67] (helo=szxga04-in.huawei.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7oSx-000DgE-LK for ccamp@ops.ietf.org; Wed, 03 Dec 2008 09:56:21 +0000 Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KBA00AU8OW3O6@szxga04-in.huawei.com> for ccamp@ops.ietf.org; Wed, 03 Dec 2008 17:55:15 +0800 (CST) Received: from m55527 ([10.111.12.247]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KBA007GGOVZM2@szxga04-in.huawei.com> for ccamp@ops.ietf.org; Wed, 03 Dec 2008 17:55:15 +0800 (CST) Date: Wed, 03 Dec 2008 17:55:10 +0800 From: Mach Chen Subject: Re: CCAMP drafts for adoption To: Adrian Farrel , ccamp@ops.ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V12.0.1606 X-Mailer: Microsoft Windows Live Mail 12.0.1606 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 X-MSMail-priority: Normal References: <2089B64D43144AEEA390F5C4C7232087@your029b8cecfe> Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Yes to all three drafts. Best regards, Mach -------------------------------------------------- From: "Adrian Farrel" Sent: Wednesday, December 03, 2008 12:01 AM To: Subject: CCAMP drafts for adoption > Hi, > > Can you please express your opinion on the adoption of the following three > drafts as WG drafts. > > Thanks, > Adrian > > draft-takacs-ccamp-oam-configuration-fwk-01.txt > draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt > draft-bernstein-ccamp-wson-encode-01.txt (to become -rwa-encode-00) > > Cheers, > Adrian and Deborah > > > From owner-ccamp@ops.ietf.org Wed Dec 3 02:13:14 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82ABC28C108 for ; Wed, 3 Dec 2008 02:13:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.355 X-Spam-Level: X-Spam-Status: No, score=-101.355 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S9S7Z80pmvUv for ; Wed, 3 Dec 2008 02:13:13 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AA99828C0F1 for ; Wed, 3 Dec 2008 02:13:13 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7ofb-000ETP-12 for ccamp-data@psg.com; Wed, 03 Dec 2008 10:09:23 +0000 Received: from [2001:2f8:29::3] (helo=ns2.nict.go.jp) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7ofV-000ESM-5d for ccamp@ops.ietf.org; Wed, 03 Dec 2008 10:09:20 +0000 Received: from gw2.nict.go.jp (gw2 [133.243.18.251]) by ns2.nict.go.jp with ESMTP id mB3A9C6s017911; Wed, 3 Dec 2008 19:09:12 +0900 (JST) Received: from gw2.nict.go.jp (localhost [127.0.0.1]) by gw2.nict.go.jp with ESMTP id mB3A9C8D021392; Wed, 3 Dec 2008 19:09:12 +0900 (JST) Received: from mail2.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw2.nict.go.jp with ESMTP id mB3A9Ccn021389; Wed, 3 Dec 2008 19:09:12 +0900 (JST) Received: from mail2.nict.go.jp (localhost [127.0.0.1]) by localhost.nict.go.jp (Postfix) with ESMTP id C6A5C6E4F; Wed, 3 Dec 2008 19:09:11 +0900 (JST) Received: from [127.0.0.1] (ssh2.nict.go.jp [133.243.3.50]) by mail2.nict.go.jp (Postfix) with ESMTP id A3A1D6E4E; Wed, 3 Dec 2008 19:09:11 +0900 (JST) Message-ID: <49365AB5.7090002@nict.go.jp> Date: Wed, 03 Dec 2008 19:08:53 +0900 From: Sugang XU User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Adrian Farrel Cc: ccamp@ops.ietf.org Subject: Re: CCAMP drafts for adoption References: <2089B64D43144AEEA390F5C4C7232087@your029b8cecfe> In-Reply-To: <2089B64D43144AEEA390F5C4C7232087@your029b8cecfe> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Support all to become WG documents. Sugang Adrian Farrel ã•ã‚“ã¯æ›¸ãã¾ã—ãŸ: > Hi, > > Can you please express your opinion on the adoption of the following > three drafts as WG drafts. > > Thanks, > Adrian > > draft-takacs-ccamp-oam-configuration-fwk-01.txt > draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt > draft-bernstein-ccamp-wson-encode-01.txt (to become -rwa-encode-00) > > Cheers, > Adrian and Deborah > > > From owner-ccamp@ops.ietf.org Wed Dec 3 02:57:33 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5874E3A6B71 for ; Wed, 3 Dec 2008 02:57:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.021 X-Spam-Level: X-Spam-Status: No, score=-104.021 tagged_above=-999 required=5 tests=[AWL=0.474, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wwuV1gcNYIcZ for ; Wed, 3 Dec 2008 02:57:32 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A74AE3A6B46 for ; Wed, 3 Dec 2008 02:57:31 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7pLn-000Ghj-70 for ccamp-data@psg.com; Wed, 03 Dec 2008 10:52:59 +0000 Received: from [216.82.253.179] (helo=mail167.messagelabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7pLi-000GhJ-GU for ccamp@ops.ietf.org; Wed, 03 Dec 2008 10:52:56 +0000 X-VirusChecked: Checked X-Env-Sender: dbrungard@att.com X-Msg-Ref: server-3.tower-167.messagelabs.com!1228301572!8559066!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 22761 invoked from network); 3 Dec 2008 10:52:52 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-3.tower-167.messagelabs.com with AES256-SHA encrypted SMTP; 3 Dec 2008 10:52:52 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id mB3AqpYD024488 for ; Wed, 3 Dec 2008 05:52:51 -0500 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id mB3AqnSc024477 for ; Wed, 3 Dec 2008 05:52:49 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: CCAMP minutes Date: Wed, 3 Dec 2008 05:51:47 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: CCAMP minutes Thread-Index: AclVNSNY0XswXzhcSR+LtL8Jpd4QDw== From: "BRUNGARD, DEBORAH A, ATTLABS" To: "ccamp" Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Hi all, The ccamp minutes are available: http://www.ietf.org/proceedings/08nov/minutes/ccamp.htm Much thanks to our note takers: Lyndon Ong (both sessions!), Eric Gray (session I) and Don Fedyk (session II). Let us know if any comments- Deborah and Adrian From owner-ccamp@ops.ietf.org Wed Dec 3 04:40:29 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD5DA3A68BC for ; Wed, 3 Dec 2008 04:40:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.543 X-Spam-Level: X-Spam-Status: No, score=-1.543 tagged_above=-999 required=5 tests=[AWL=-0.496, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id skv0ZxzdGb0H for ; Wed, 3 Dec 2008 04:40:29 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 164E03A695F for ; Wed, 3 Dec 2008 04:40:29 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7qxA-000NTz-IW for ccamp-data@psg.com; Wed, 03 Dec 2008 12:35:40 +0000 Received: from [156.106.192.41] (helo=protext01.itu.ch) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7qx5-000NTP-KE for ccamp@ops.ietf.org; Wed, 03 Dec 2008 12:35:37 +0000 Received: from protext01.itu.ch ([156.106.192.41]) by protext01.itu.ch with Microsoft SMTPSVC(5.0.2195.6713); Wed, 3 Dec 2008 13:35:34 +0100 Received: From mail6.itu.ch ([156.106.192.22]) by protext01.itu.ch (WebShield SMTP v4.5 MR3) id 1228307733882; Wed, 3 Dec 2008 13:35:33 +0100 Received: from your029b8cecfe ([156.106.216.176]) by mail6.itu.ch (8.14.3/8.14.3) with ESMTP id mB3CZWGD370222 for ; Wed, 3 Dec 2008 13:35:33 +0100 (MET) Message-ID: <07626F0FC99D4A538A3D919BF3E88A37@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "ccamp" References: Subject: Reiterating Thanks to Note-takers Date: Wed, 3 Dec 2008 12:35:29 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (mail6.itu.ch [156.106.192.22]); Wed, 03 Dec 2008 13:35:33 +0100 (MET) X-OriginalArrivalTime: 03 Dec 2008 12:35:34.0382 (UTC) FILETIME=[A31238E0:01C95543] Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Can I reiterate thanks to the note-takers. I often go back to the minutes to establish who said what, and what opinions were expressed. Accurate and detailed notes are a great asset. Thanks, Adrian ----- Original Message ----- From: "BRUNGARD, DEBORAH A, ATTLABS" To: "ccamp" Sent: Wednesday, December 03, 2008 10:51 AM Subject: CCAMP minutes Hi all, The ccamp minutes are available: http://www.ietf.org/proceedings/08nov/minutes/ccamp.htm Much thanks to our note takers: Lyndon Ong (both sessions!), Eric Gray (session I) and Don Fedyk (session II). Let us know if any comments- Deborah and Adrian From owner-ccamp@ops.ietf.org Wed Dec 3 05:09:54 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4699C3A68C6 for ; Wed, 3 Dec 2008 05:09:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WAq8VDcqqgMj for ; Wed, 3 Dec 2008 05:09:53 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 78D2C3A67D1 for ; Wed, 3 Dec 2008 05:09:52 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7rPN-000P8U-Aw for ccamp-data@psg.com; Wed, 03 Dec 2008 13:04:49 +0000 Received: from [209.85.128.188] (helo=fk-out-0910.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7rPI-000P86-An for ccamp@ops.ietf.org; Wed, 03 Dec 2008 13:04:46 +0000 Received: by fk-out-0910.google.com with SMTP id e30so3140793fke.9 for ; Wed, 03 Dec 2008 05:04:42 -0800 (PST) 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:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=MfgpROrgZ4C9PD3u2LiyXihlkemhchdD8O2RlU0t2YM=; b=WFEqRdDvQenapYdIztyqIy378u6sDhRYIz4nudpCyBFwW4RaAVznGEKJL1Ete0nvJb 1riPAf6ZnrUBGf3cVjeha84IJiuTjg74ovhhq8oRGpulkx1ZviFpaqF6OlC/37Wbs8ja xQvC6JA3rYfWaDecpVGUI57T/DinnlSYBctQw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=Jz8hEts3rjby8wX+514aqv2We/+kuimtXBuz4Qv8FM3TYFeRPt2sO18e+PZHTmjWS7 weQRsb344yvJg94F1Hef6P0wXs/RI8rc1H5dSlBv9rWppW8v30lqNcFelU47aT+1Bde9 FbK/FE+V37AiUBH/xIQzPwmXAJvHZHPHee00c= Received: by 10.181.59.19 with SMTP id m19mr4644878bkk.91.1228309482337; Wed, 03 Dec 2008 05:04:42 -0800 (PST) Received: by 10.181.199.6 with HTTP; Wed, 3 Dec 2008 05:04:42 -0800 (PST) Message-ID: <7c923b5e0812030504x6b257d44p5c64329eee842dda@mail.gmail.com> Date: Wed, 3 Dec 2008 14:04:42 +0100 From: "Francesco Fondelli" To: "Nitin Bahadur" Subject: Re: CCAMP drafts for adoption Cc: "Adrian Farrel" , ccamp@ops.ietf.org In-Reply-To: <7FA0C743C38E5340BFC2873488FA1E8E025DDF5E@emailcorp3.jnpr.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <001201c9549f$2dac4e50$d626fea9@china.huawei.com> <001601c954c0$d165bf10$470c7c0a@china.huawei.com> <7FA0C743C38E5340BFC2873488FA1E8E025DDF5E@emailcorp3.jnpr.net> Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: On Tue, Dec 2, 2008 at 10:35 PM, Nitin Bahadur wrote: > > >> > draft-takacs-ccamp-oam-configuration-fwk-01.txt >> > draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt > > Do not support either of these. Given this statement a) --- draft-ietf-mpls-tp-framework-00 --- The MPLS-TP control plane is based on a combination of the MPLS control plane for pseudowires and the GMPLS control plane for MPLS-TP LSPs, respectively. More specifically, LDP is used for PW signaling and *GMPLS based RSVP-TE for LSP signaling*. --- and this requirement b) --- draft-ietf-mpls-tp-requirements-00 -- The MPLS-TP control pane MUST support the configuration and modification of OAM maintenance points as well as the activation/deactivation of OAM *when the transport path is established or modified*. --- RSVP-TE is the tool that has to be used for OAM configuration in a MPLS-TP context, IMHO. Above I-Ds are mpls working group documents... so my opinion on the adoption of the following two drafts draft-takacs-ccamp-oam-configuration-fwk-01.txt draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt is yes and my opinion on the adoption of the following draft draft-bernstein-ccamp-wson-encode-01.txt is yes > Thanks > Nitin thanks Ciao FF From owner-ccamp@ops.ietf.org Wed Dec 3 06:42:24 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88A1D3A6923 for ; Wed, 3 Dec 2008 06:42:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.069 X-Spam-Level: X-Spam-Status: No, score=-1.069 tagged_above=-999 required=5 tests=[AWL=-0.908, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7HFgUL1VHzhR for ; Wed, 3 Dec 2008 06:42:23 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 99F6F3A6987 for ; Wed, 3 Dec 2008 06:42:23 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7sqh-0004cC-Hx for ccamp-data@psg.com; Wed, 03 Dec 2008 14:37:07 +0000 Received: from [69.89.18.6] (helo=outbound-mail-120.bluehost.com) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7sqc-0004bs-HS for ccamp@ops.ietf.org; Wed, 03 Dec 2008 14:37:04 +0000 Received: (qmail 21190 invoked by uid 0); 3 Dec 2008 14:36:58 -0000 Received: from unknown (HELO box474.bluehost.com) (74.220.219.74) by outboundproxy3.bluehost.com with SMTP; 3 Dec 2008 14:36:58 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:X-Mailer:Date:To:From:Subject:Cc:In-Reply-To:References:Mime-Version:Content-Type:X-Identified-User; b=vL9vPntLVVJIVQLaqXwhhCnA9SBqY5E8mYvPhDz+zMaRSq+DRuNB3dfletHc6DAxnPnsCazO7K+RHkn1YULWxTyxoZq90XVTJx++Q9YhTvA00XnxOoQKu7aKvk6RMkg+; Received: from box474.bluehost.com ([74.220.219.74] helo=LC2.labn.net) by box474.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1L7sqY-0004WR-DP; Wed, 03 Dec 2008 07:36:58 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 03 Dec 2008 09:36:59 -0500 To: "Thomas D. Nadeau" From: Lou Berger Subject: Re: CCAMP drafts for adoption Cc: David Allan ,Nitin Bahadur , In-Reply-To: References: <87AC5F88F03E6249AEA68D40BD3E00BE168324AD@zcarhxm2.corp.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Identified-User: {2629:box474.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 74.220.219.74 authed with lberger@labn.net} Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Message-Id: Tom, You might want to look at what's happening with OAM for TP, it != LSP Ping. As TP is currently drafted, Attila's documents will make more sense than LSP ping. Lou At 06:41 PM 12/2/2008, Thomas D. Nadeau wrote: > Dave, > > As an operator with a very big deployment of MPLS and a lot of money >invested in OSS to manage said network, I do not want a different mechanism >to the one that has been deployed today to control OAM for any MPLS >networks, MPLS-TP included. > > --Tom > > > >On 12/2/08 6:01 PM, "David Allan" wrote: > > > HI Nitin: > > > > Thanks for replying.... > > > > > >> David, all that I am asking is that one can use the basic-bare-bones > > definitions in lsp-ping to setup the Ethernet OAM > >> params. I am not talking about applicability nor I am saying that one > > needs to use ping and trace based off lsp-ping for > PBB-TE LSPs. > > > > But this still requires implementing a new protocol where it does not > > already exist, which also requires a *new* bare bones definition... > > > >> We have a whole bunch of stuff defined in RSVP. Obviously some of them > > are not applicable for GMPLS LSPs. But that does > not mean that we go > > define G-RSVP (for GMPLS LSPs). > > > > Isn't that CCAMPs mandate? > > > > > > > >> I am not asking you to use lsp-ping for LB/LT. I agree that ethernet > > OAM already has that and indeed once should use > >> that. I am just saying that the setup can be done using lsp-ping. > > > > I think the point was GMPLS applies to a lot of technologies that cannot > > do LSP-PING in the first place, which means such a signalling extension > > will be required nonetheless... > > > > > >> LSP-Ping is already non-IP from a *forwarding* perspective. LSP-Ping > > has a reply-mode of *application channel* which can > be used for things > > like bi-directional LSPs. So for MPLS-TP LSPs, the lsp-ping replies > > would go on the LSP reverse path > (label-switched and not IP > > forwarded). > > > > OK, I can see that such an approach could be made to work and would be > > desirable to some. On that basis, can I suggest you withdraw your > > objections to the Eth-Oam draft and move the TP parts of this discussion > > over to the MPLS list? That would seem appropriate... > > > > Cheers > > Dave > > > > From owner-ccamp@ops.ietf.org Wed Dec 3 06:46:14 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DD0F3A69FE for ; Wed, 3 Dec 2008 06:46:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.494 X-Spam-Level: X-Spam-Status: No, score=-0.494 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BCNFzdV0SZcz for ; Wed, 3 Dec 2008 06:46:13 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E872E3A6987 for ; Wed, 3 Dec 2008 06:46:12 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7svn-0004vp-9k for ccamp-data@psg.com; Wed, 03 Dec 2008 14:42:23 +0000 Received: from [209.191.85.55] (helo=web36804.mail.mud.yahoo.com) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7svh-0004vL-Ok for ccamp@ops.ietf.org; Wed, 03 Dec 2008 14:42:20 +0000 Received: (qmail 42342 invoked by uid 60001); 3 Dec 2008 14:42:16 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=zQmwV/FoUC/wDC5aB1y8fM5oGCf8wC7nXosJbDOeaXue1LJAj+21sVJHN8JHEXRkLmVnzT2iIPcfuJElnr+mhJR5O+o0qg58E07aqm23MCLdkDcbfUK9Z76GGmI97gma7rR/Cr4qEDDVRzLjIpEwniiDw9Rm/307+oi/cjmpzVw=; X-YMail-OSG: 1XikTrgVM1loaz.A8_w.n8CJBj1VWXTkweUI5mDRQClVavKsJSOu08RQ_2G7_sR76Kmg1R6V5jBhUE0JwGC_k3O4xj4kGFx9rkbbPEm0TXprkFfQUhkXT2qX05TouRFwDRtikBMqYZiES8lr9Cg6W5tW3ZlKAYNQuLVLF2ptwI8d7na0wD3mjsC5aug- Received: from [67.102.145.11] by web36804.mail.mud.yahoo.com via HTTP; Wed, 03 Dec 2008 06:42:15 PST X-Mailer: YahooMailRC/1155.32 YahooMailWebService/0.7.260.1 References: <001201c9549f$2dac4e50$d626fea9@china.huawei.com> <001601c954c0$d165bf10$470c7c0a@china.huawei.com> <7FA0C743C38E5340BFC2873488FA1E8E025DDF5E@emailcorp3.jnpr.net> <87AC5F88F03E6249AEA68D40BD3E00BE168324A4@zcarhxm2.corp.nortel.com> <7FA0C743C38E5340BFC2873488FA1E8E025DDF6B@emailcorp3.jnpr.net> <87AC5F88F03E6249AEA68D40BD3E00BE168324AD@zcarhxm2.corp.nortel.com> <7FA0C743C38E5340BFC2873488FA1E8E025DDF6E@emailcorp3.jnpr.net> <87AC5F88F03E6249AEA68D40BD3E00BE168324AF@zcarhxm2.corp.nortel.com> Date: Wed, 3 Dec 2008 06:42:15 -0800 (PST) From: Igor Bryskin Subject: Re: CCAMP drafts for adoption To: David Allan , Nitin Bahadur , ccamp@ops.ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-680914809-1228315335=:39765" Message-ID: <138584.39765.qm@web36804.mail.mud.yahoo.com> Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: --0-680914809-1228315335=:39765 Content-Type: text/plain; charset=us-ascii Dave, I completely agree with you. For me, as a GMPLS vendor, it would be very easy to add a couple of objects to GMPLS RSVP ( by the way, I also agree that GMPLS RSVP is very, very different from IP/MPLS RSVP-TE) so that I could automate OAM configuration. To add LSP Ping to my GMPLS offering is a completely diffirent scale of effort, and I believe, there should be reasons for this much more serious than the fact this could be also done using some existing IP/MPLS technology which so far was never part of my solution. On more general note, I think, it would be a good idea to agree within the CCAMP WG what is it, actually, GMPLS? Specifically, which components of IP/MPLS control plane belong to GMPLS, which do not, and which parts of GMPLS are specific to transport networks and have nothing to do with IP/MPLS. For instance, does LSP Ping belong to GMPLS? How about BGP? LDP? If the answer is yes, than which production GMPLS deployments feature them? I think after 8 years of working on GMPLS we can answer these questions. If the answer is no, that let's solve transport network control plane problems within existing GMPLS framework. Igor ________________________________ From: David Allan To: Nitin Bahadur ; ccamp@ops.ietf.org Sent: Tuesday, December 2, 2008 7:40:55 PM Subject: RE: CCAMP drafts for adoption Hi Nitin: My reaction is that spreading state over a number of protocols may keep one superficially simple but drives up the total cost of the solution...from the POV of lines of code, amount to test, amount of state, additional race conditions, delayed setup time etc. so is a specious optimization.... If the path is not up until OAM says so, it is useful to get there in as few transactions as possible... My 2 cents. Dave -----Original Message----- From: Nitin Bahadur [mailto:nitinb@juniper.net] Sent: Tuesday, December 02, 2008 6:38 PM To: Allan, David (CAR:NS00); ccamp@ops.ietf.org Subject: RE: CCAMP drafts for adoption Hi David, > > David, all that I am asking is that one can use the basic-bare-bones > definitions in lsp-ping to setup the Ethernet OAM > > params. I am not talking about applicability nor I am > saying that one > needs to use ping and trace based off lsp-ping for > PBB-TE LSPs. > > But this still requires implementing a new protocol where it does not > already exist, I agree. It does require implementing lsp-ping. But the way these 2 drafts are going, they will end up defining a new mini-oam-boot-strapping protocol on top of RSVP path messages. And once we have a precedence, it will just keep growing. I am basically against using RSVP path message as an OAM related PDU transfer agent. The drafts already specify 3-4 sub-TLVs and a bunch of error codes. This list can grow. The framework draft is generic in nature. So tomorrrow I can use BFD or XXX on top of RSVP (why just ethernet-oam) and I can add 10 more TLVs and 5 more error codes. It's all about keeping RSVP clean. Your requirement is to automate OAM on a GMPLS LSP. Why dirty this poor Path msg. If you do not wish to use Lsp-ping (for whatever reason)...I recommend using something other than a RSVP path msg. > which also requires a *new* bare > bones definition... I think that would be easy. You just need to send the lsp-ping msg along the control-plane. The LSP details can be put in the existing defined TLVs. The ethernet OAM details can be directly copied from these new drafts into a lsp-ping based draft. > > > > I am not asking you to use lsp-ping for LB/LT. I agree that ethernet > OAM already has that and indeed once should use > > that. I am just saying that the setup can be done using lsp-ping. > > I think the point was GMPLS applies to a lot of technologies that > cannot do LSP-PING in the first place, which means such a signalling > extension will be required nonetheless... As I said earlier, use LSP-Ping not for OAM, but for signaling the OAM params. Given that you are using RSVP for signaling the GMPLS LSP via the control plane, you can use LSP-Ping (via control plane) to do the OAM signaling. > can I suggest you > withdraw your objections to the Eth-Oam draft and move the TP parts of > this discussion over to the MPLS list? My main objections to the Eth-oam drafts are not TP related. They are related to using RSVP Path as a transmission mechanism for OAM setup. OAM is complex and tomorrow we might need more TLVs to indicate remote failure or some other condition via the control plane. Dave, you are the co-author of draft-ietf-pwe3-oam-msg-map. Look at the amount of stuff that has gone in there. As a side-note, I am just *a person*. It's the ccamp wg mailing list that needs to say *yes*/*no*. It's all rough consensus right? Thanks Nitin --0-680914809-1228315335=:39765 Content-Type: text/html; charset=us-ascii
Dave,

I completely agree with you. For me, as a GMPLS vendor, it would be very easy to add a couple of objects to GMPLS RSVP ( by the way, I also agree that GMPLS RSVP is very, very different from IP/MPLS RSVP-TE) so that I could automate OAM configuration. To add LSP Ping to my GMPLS offering is a completely diffirent scale of effort, and  I believe, there should be reasons for this much more serious than the fact this could be also done using some existing IP/MPLS technology which so far was never part of my solution.

On more general note, I think, it would be a good idea to agree within the CCAMP WG what is it, actually, GMPLS? Specifically, which components of IP/MPLS control plane belong to GMPLS, which do not, and which parts of GMPLS are specific to transport networks and have nothing to do with IP/MPLS. For instance, does LSP Ping belong to GMPLS? How about BGP? LDP? If the answer is yes, than which production GMPLS deployments feature them? I think after 8 years of working on GMPLS we can answer these questions. If the answer is no, that let's solve transport network control plane problems within existing GMPLS framework.

Igor

From: David Allan <dallan@nortel.com>
To: Nitin Bahadur <nitinb@juniper.net>; ccamp@ops.ietf.org
Sent: Tuesday, December 2, 2008 7:40:55 PM
Subject: RE: CCAMP drafts for adoption

Hi Nitin:

My reaction is that spreading state over a number of protocols may keep
one superficially simple but drives up the total cost of the
solution...from the POV of lines of code, amount to test, amount of
state, additional race conditions, delayed setup time etc. so is a
specious optimization....

If the path is not up until OAM says so, it is useful to get there in as
few transactions as possible...

My 2 cents.
Dave





-----Original Message-----
From: Nitin Bahadur [mailto:nitinb@juniper.net]
Sent: Tuesday, December 02, 2008 6:38 PM
To: Allan, David (CAR:NS00); ccamp@ops.ietf.org
Subject: RE: CCAMP drafts for adoption


Hi David,

> > David, all that I am asking is that one can use the basic-bare-bones
> definitions in lsp-ping to setup the Ethernet OAM
> > params. I am not talking about applicability nor I am
> saying that one
> needs to use ping and trace based off lsp-ping for > PBB-TE LSPs.
>
> But this still requires implementing a new protocol where it does not
> already exist,

I agree. It does require implementing lsp-ping. But the way these 2
drafts are going, they will end up defining a new
mini-oam-boot-strapping protocol on top of RSVP path messages. And once
we have a precedence, it will just keep growing. I am basically against
using RSVP path message as an OAM related PDU transfer agent. The drafts
already specify 3-4 sub-TLVs and a bunch of error codes. This list can
grow. The framework draft is generic in nature. So tomorrrow I can use
BFD or XXX on top of RSVP (why just ethernet-oam) and I can add 10 more
TLVs and 5 more error codes.

It's all about keeping RSVP clean. Your requirement is to automate OAM
on a GMPLS LSP. Why dirty this poor Path msg.

If you do not wish to use Lsp-ping (for whatever reason)...I recommend
using something other than a RSVP path msg.

> which also requires a *new* bare
> bones definition...

I think that would be easy. You just need to send the lsp-ping msg along
the control-plane. The LSP details can be put in the existing defined
TLVs. The ethernet OAM details can be directly copied from these new
drafts into a lsp-ping based draft.

> <snipped>
>
> > I am not asking you to use lsp-ping for LB/LT. I agree that ethernet
> OAM already has that and indeed once should use
> > that. I am just saying that the setup can be done using lsp-ping.
>
> I think the point was GMPLS applies to a lot of technologies that
> cannot do LSP-PING in the first place, which means such a signalling
> extension will be required nonetheless...

As I said earlier, use LSP-Ping not for OAM, but for signaling the OAM
params.
Given that you are using RSVP for signaling the GMPLS LSP via the
control plane, you can use LSP-Ping (via control plane) to do the OAM
signaling.

> can I suggest you
> withdraw your objections to the Eth-Oam draft and move the TP parts of

> this discussion over to the MPLS list?

My main objections to the Eth-oam drafts are not TP related.
They are related to using RSVP Path as a transmission mechanism for OAM
setup. OAM is complex and tomorrow we might need more TLVs to indicate
remote failure or some other condition via the control plane.
Dave, you are the co-author of draft-ietf-pwe3-oam-msg-map. Look at the
amount of stuff that has gone in there.

As a side-note, I am just *a person*. It's the ccamp wg mailing list
that needs to say *yes*/*no*. It's all rough consensus right?

Thanks
Nitin


--0-680914809-1228315335=:39765-- From owner-ccamp@ops.ietf.org Wed Dec 3 07:34:41 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 251AC3A690B for ; Wed, 3 Dec 2008 07:34:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.698 X-Spam-Level: X-Spam-Status: No, score=-4.698 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dv7qNaEd6IfO for ; Wed, 3 Dec 2008 07:34:40 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1B4DD3A689C for ; Wed, 3 Dec 2008 07:34:40 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7tfr-0008Rt-LD for ccamp-data@psg.com; Wed, 03 Dec 2008 15:29:59 +0000 Received: from [193.180.251.62] (helo=mailgw4.ericsson.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7tfl-0008RN-FI for ccamp@ops.ietf.org; Wed, 03 Dec 2008 15:29:56 +0000 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 299352212B; Wed, 3 Dec 2008 16:28:08 +0100 (CET) X-AuditID: c1b4fb3e-af787bb00000537b-ef-4936a588a67a Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 033B822110; Wed, 3 Dec 2008 16:28:08 +0100 (CET) Received: from esealmw116.eemea.ericsson.se ([153.88.200.7]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Dec 2008 16:28:07 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: CCAMP drafts for adoption Date: Wed, 3 Dec 2008 16:28:00 +0100 Message-ID: <53CCFDD6E346CB43994852666C210E9105B98CDB@esealmw116.eemea.ericsson.se> In-Reply-To: <7FA0C743C38E5340BFC2873488FA1E8E025DDF6A@emailcorp3.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: CCAMP drafts for adoption thread-index: AclUl6mpWAW2o7P/QfKhDBZKhoe9CgABkY3AAAiyQSAAAP4GoAAAuZwwAABaoIAAACzaAAAAe+hQACNwvLA= References: <001201c9549f$2dac4e50$d626fea9@china.huawei.com> <001601c954c0$d165bf10$470c7c0a@china.huawei.com> <7FA0C743C38E5340BFC2873488FA1E8E025DDF5E@emailcorp3.jnpr.net> <53CCFDD6E346CB43994852666C210E9105B70D91@esealmw116.eemea.ericsson.se> <7FA0C743C38E5340BFC2873488FA1E8E025DDF68@emailcorp3.jnpr.net> <53CCFDD6E346CB43994852666C210E9105B70DA5@esealmw116.eemea.ericsson.se> <7FA0C743C38E5340BFC2873488FA1E8E025DDF6A@emailcorp3.jnpr.net> From: "Attila Takacs" To: "Nitin Bahadur" , X-OriginalArrivalTime: 03 Dec 2008 15:28:07.0865 (UTC) FILETIME=[BE3A5A90:01C9555B] X-Brightmail-Tracker: AAAAAA== Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Hi Nitin,=20 >=20 > If you add a new-TLV to the PATH msg, then you need to send=20 > it on every PATH msg... > You really need to signal the parameters once during=20 > LSP-setup time (and perhaps when the parameters are changed). >=20 There are some options here.=20 First it has clear benefits to have the OAM config bound to the Path message and so to the actual LSP establishment as this ensures that the connection and its OAM is coupled. This is something you cannot ensure with LSP Ping. Alternatively, if one just wants to configure MEPs one may carry the proposed TLVs as part of Call establishment, this way only the endpoints will take part in signaling. On the other hand, if one needs to configure MIPs, the signaling needs to pass intermediate nodes hence the need to use the Path message is obvious. > LSP-Ping has a whole bunch of stuff defined. Most of it is=20 > not needed/applicable in various scenarios. But the advantage=20 > is that it's all there. As you go ahead with defining a new=20 > mechanism, you will gradually see other requirements/needs=20 > and you might end up re-inventing lsp-ping in another form. >=20 How would you configure MIPs with LSP Ping? I assume you would need to use at least as many transactions (and as such have as many failure scenarios) as many intermediate nodes the LSP has. (Not to mention that you need to get the list of intermediate nodes and the info on the success/failure of LSP establishment from another protocol.) Compare this to a single Path message in the case of RSVP-TE. Best regards, Attila > > Best regards, > > Attila > >=20 > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: Nitin Bahadur [mailto:nitinb@juniper.net] > > > Sent: Tuesday, December 02, 2008 11:01 PM > > > To: Attila Takacs; Adrian Farrel; ccamp@ops.ietf.org > > > Subject: RE: CCAMP drafts for adoption > > >=20 > > >=20 > > > Hi Attlia, > > >=20 > > > What is the limitation of lsp-ping that prevents it from being=20 > > > applied to GMPLS? > > > If an existing mechanism can be applied, then why not? If=20 > lsp-ping=20 > > > needs extensions to support GMPLS LSPs, feel free to make/specify=20 > > > those extensions. > > >=20 > > > Thanks > > > Nitin > > >=20 > > > > -----Original Message----- > > > > From: Attila Takacs [mailto:Attila.Takacs@ericsson.com] > > > > Sent: Tuesday, December 02, 2008 1:52 PM > > > > To: Nitin Bahadur; Adrian Farrel; ccamp@ops.ietf.org > > > > Subject: RE: CCAMP drafts for adoption > > > >=20 > > > > Hi Nitin, > > > >=20 > > > > Please note that these mechanisms are proposed for GMPLS > > > and as such > > > > to provide support for any data plane technology specific OAM=20 > > > > mechanism. As you noted LSP Ping is for MPLS and BFD only. > > > >=20 > > > > Best regards, > > > > Attila > > > >=20 > > > > > -----Original Message----- > > > > > From: owner-ccamp@ops.ietf.org > > > > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Nitin Bahadur > > > > > Sent: Tuesday, December 02, 2008 10:35 PM > > > > > To: Adrian Farrel; ccamp@ops.ietf.org > > > > > Subject: RE: CCAMP drafts for adoption > > > > >=20 > > > > >=20 > > > > >=20 > > > > > > > draft-takacs-ccamp-oam-configuration-fwk-01.txt > > > > > > > draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt > > > > >=20 > > > > > Do not support either of these. > > > > >=20 > > > > > From the oam-config-fwk draft: > > > > > > A new useful application of RSVP-TE is OAM configuration > > > > > and control > > > > > > for transport networks. > > > > >=20 > > > > > LSP-ping was designed as an OAM mechansim for MPLS LSPs.=20 > > > Why do we > > > > > need another mechanism? What are the limitations of > > lsp-ping that > > > > > warrant this new mechanism? > > > > >=20 > > > > > > When RSVP-TE is used for LSP establishment it is desirable > > > > > to bind OAM > > > > > > setup to connection establishment signalling to avoid two > > > > separate > > > > > > management/configuration steps > > > > >=20 > > > > > draft-ietf-bfd-mpls specifies how to use LSP-Ping for > > > > automatic setup > > > > > of BFD-based OAM. > > > > > We should go along the same path for Ethernet OAM. > > > > >=20 > > > > > Thanks > > > > > Nitin > > > > >=20 > > > > >=20 > > > >=20 > > >=20 > >=20 >=20 From owner-ccamp@ops.ietf.org Wed Dec 3 07:44:20 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7C733A6822 for ; Wed, 3 Dec 2008 07:44:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2-WIfgAiNwdc for ; Wed, 3 Dec 2008 07:44:20 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 08C1F3A67E9 for ; Wed, 3 Dec 2008 07:44:20 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7tpI-0008zs-K1 for ccamp-data@psg.com; Wed, 03 Dec 2008 15:39:44 +0000 Received: from [206.16.17.180] (helo=usaga04-in.huawei.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7tpD-0008zd-G2 for ccamp@ops.ietf.org; Wed, 03 Dec 2008 15:39:41 +0000 Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KBB00JA54U0NQ@usaga04-in.huawei.com> for ccamp@ops.ietf.org; Wed, 03 Dec 2008 09:39:36 -0600 (CST) Received: from jys3106023056 ([10.124.12.59]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KBB000Z34TY8A@usaga04-in.huawei.com> for ccamp@ops.ietf.org; Wed, 03 Dec 2008 09:39:36 -0600 (CST) Date: Wed, 03 Dec 2008 09:39:34 -0600 From: Rebecca Han Subject: Re: CCAMP drafts for adoption To: Adrian Farrel Cc: ccamp@ops.ietf.org Message-id: <006c01c9555d$57e38da0$3b0c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <2089B64D43144AEEA390F5C4C7232087@your029b8cecfe> Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Support all to become WG documents. Rebecca Han ----- Original Message ----- From: "Adrian Farrel" To: Sent: Tuesday, December 02, 2008 10:01 AM Subject: CCAMP drafts for adoption > Hi, > > Can you please express your opinion on the adoption of the following three > drafts as WG drafts. > > Thanks, > Adrian > > draft-takacs-ccamp-oam-configuration-fwk-01.txt > draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt > draft-bernstein-ccamp-wson-encode-01.txt (to become -rwa-encode-00) > > Cheers, > Adrian and Deborah > > > > From owner-ccamp@ops.ietf.org Wed Dec 3 07:46:15 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00E5C3A6B23 for ; Wed, 3 Dec 2008 07:46:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.547 X-Spam-Level: X-Spam-Status: No, score=-5.547 tagged_above=-999 required=5 tests=[AWL=-1.052, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WvsgF6oUgEzw for ; Wed, 3 Dec 2008 07:46:14 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A5F043A6B25 for ; Wed, 3 Dec 2008 07:46:13 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7trj-0009BJ-VD for ccamp-data@psg.com; Wed, 03 Dec 2008 15:42:15 +0000 Received: from [130.76.32.69] (helo=blv-smtpout-01.boeing.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7trW-0009A0-NI for ccamp@ops.ietf.org; Wed, 03 Dec 2008 15:42:05 +0000 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id mB3Ffk9h015003 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 3 Dec 2008 07:41:54 -0800 (PST) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id mB3FfkqN000435; Wed, 3 Dec 2008 07:41:46 -0800 (PST) Received: from xch-swbh-11.sw.nos.boeing.com (xch-swbh-11.sw.nos.boeing.com [129.172.192.157]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id mB3Ffhco000266; Wed, 3 Dec 2008 07:41:46 -0800 (PST) Received: from XCH-SW-5V2.sw.nos.boeing.com ([129.172.193.50]) by xch-swbh-11.sw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Dec 2008 07:41:45 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: CCAMP drafts for adoption Date: Wed, 3 Dec 2008 07:41:43 -0800 Message-ID: <51661468CBD1354294533DA79E85955A0148BB0C@XCH-SW-5V2.sw.nos.boeing.com> In-Reply-To: <53CCFDD6E346CB43994852666C210E9105B98CDB@esealmw116.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: CCAMP drafts for adoption Thread-Index: AclUl6mpWAW2o7P/QfKhDBZKhoe9CgABkY3AAAiyQSAAAP4GoAAAuZwwAABaoIAAACzaAAAAe+hQACNwvLAAAP1CgA== References: <001201c9549f$2dac4e50$d626fea9@china.huawei.com> <001601c954c0$d165bf10$470c7c0a@china.huawei.com> <7FA0C743C38E5340BFC2873488FA1E8E025DDF5E@emailcorp3.jnpr.net> <53CCFDD6E346CB43994852666C210E9105B70D91@esealmw116.eemea.ericsson.se> <7FA0C743C38E5340BFC2873488FA1E8E025DDF68@emailcorp3.jnpr.net> <53CCFDD6E346CB43994852666C210E9105B70DA5@esealmw116.eemea.ericsson.se> <7FA0C743C38E5340BFC2873488FA1E8E025DDF6A@emailcorp3.jnpr.net> <53CCFDD6E346CB43994852666C210E9105B98CDB@esealmw116.eemea.ericsson.se> From: "Drake, John E" To: "Attila Takacs" , "Nitin Bahadur" , X-OriginalArrivalTime: 03 Dec 2008 15:41:45.0675 (UTC) FILETIME=[A5AE41B0:01C9555D] Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Attila, Very well put. I think I-Ds in question should become working group drafts. Thanks, John=20 >-----Original Message----- >From: Attila Takacs [mailto:Attila.Takacs@ericsson.com]=20 >Sent: Wednesday, December 03, 2008 7:28 AM >To: Nitin Bahadur; ccamp@ops.ietf.org >Subject: RE: CCAMP drafts for adoption > >Hi Nitin,=20 > >>=20 >> If you add a new-TLV to the PATH msg, then you need to send it on=20 >> every PATH msg... >> You really need to signal the parameters once during LSP-setup time=20 >> (and perhaps when the parameters are changed). >>=20 > >There are some options here.=20 > >First it has clear benefits to have the OAM config bound to=20 >the Path message and so to the actual LSP establishment as=20 >this ensures that the connection and its OAM is coupled. This=20 >is something you cannot ensure with LSP Ping. > >Alternatively, if one just wants to configure MEPs one may=20 >carry the proposed TLVs as part of Call establishment, this=20 >way only the endpoints will take part in signaling. > >On the other hand, if one needs to configure MIPs, the=20 >signaling needs to pass intermediate nodes hence the need to=20 >use the Path message is obvious. > >> LSP-Ping has a whole bunch of stuff defined. Most of it is not=20 >> needed/applicable in various scenarios. But the advantage is=20 >that it's=20 >> all there. As you go ahead with defining a new mechanism, you will=20 >> gradually see other requirements/needs and you might end up=20 >> re-inventing lsp-ping in another form. >>=20 > >How would you configure MIPs with LSP Ping? I assume you would=20 >need to use at least as many transactions (and as such have as=20 >many failure >scenarios) as many intermediate nodes the LSP has. (Not to=20 >mention that you need to get the list of intermediate nodes=20 >and the info on the success/failure of LSP establishment from=20 >another protocol.) > >Compare this to a single Path message in the case of RSVP-TE. > >Best regards, >Attila > > > > >> > Best regards, >> > Attila >> >=20 >> >=20 >> >=20 >> >=20 >> > > -----Original Message----- >> > > From: Nitin Bahadur [mailto:nitinb@juniper.net] >> > > Sent: Tuesday, December 02, 2008 11:01 PM >> > > To: Attila Takacs; Adrian Farrel; ccamp@ops.ietf.org >> > > Subject: RE: CCAMP drafts for adoption >> > >=20 >> > >=20 >> > > Hi Attlia, >> > >=20 >> > > What is the limitation of lsp-ping that prevents it=20 >from being=20 >> > > applied to GMPLS? >> > > If an existing mechanism can be applied, then why not? If >> lsp-ping >> > > needs extensions to support GMPLS LSPs, feel free to=20 >make/specify=20 >> > > those extensions. >> > >=20 >> > > Thanks >> > > Nitin >> > >=20 >> > > > -----Original Message----- >> > > > From: Attila Takacs [mailto:Attila.Takacs@ericsson.com] >> > > > Sent: Tuesday, December 02, 2008 1:52 PM >> > > > To: Nitin Bahadur; Adrian Farrel; ccamp@ops.ietf.org >> > > > Subject: RE: CCAMP drafts for adoption >> > > >=20 >> > > > Hi Nitin, >> > > >=20 >> > > > Please note that these mechanisms are proposed for GMPLS >> > > and as such >> > > > to provide support for any data plane technology specific OAM=20 >> > > > mechanism. As you noted LSP Ping is for MPLS and BFD only. >> > > >=20 >> > > > Best regards, >> > > > Attila >> > > >=20 >> > > > > -----Original Message----- >> > > > > From: owner-ccamp@ops.ietf.org=20 >> > > > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Nitin Bahadur >> > > > > Sent: Tuesday, December 02, 2008 10:35 PM >> > > > > To: Adrian Farrel; ccamp@ops.ietf.org >> > > > > Subject: RE: CCAMP drafts for adoption >> > > > >=20 >> > > > >=20 >> > > > >=20 >> > > > > > > draft-takacs-ccamp-oam-configuration-fwk-01.txt >> > > > > > > draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt >> > > > >=20 >> > > > > Do not support either of these. >> > > > >=20 >> > > > > From the oam-config-fwk draft: >> > > > > > A new useful application of RSVP-TE is OAM configuration >> > > > > and control >> > > > > > for transport networks. >> > > > >=20 >> > > > > LSP-ping was designed as an OAM mechansim for MPLS LSPs.=20 >> > > Why do we >> > > > > need another mechanism? What are the limitations of >> > lsp-ping that >> > > > > warrant this new mechanism? >> > > > >=20 >> > > > > > When RSVP-TE is used for LSP establishment it is desirable >> > > > > to bind OAM >> > > > > > setup to connection establishment signalling to avoid two >> > > > separate >> > > > > > management/configuration steps >> > > > >=20 >> > > > > draft-ietf-bfd-mpls specifies how to use LSP-Ping for >> > > > automatic setup >> > > > > of BFD-based OAM. >> > > > > We should go along the same path for Ethernet OAM. >> > > > >=20 >> > > > > Thanks >> > > > > Nitin >> > > > >=20 >> > > > >=20 >> > > >=20 >> > >=20 >> >=20 >>=20 > > From owner-ccamp@ops.ietf.org Wed Dec 3 07:46:43 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D32D3A6B25 for ; Wed, 3 Dec 2008 07:46:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.547 X-Spam-Level: X-Spam-Status: No, score=-5.547 tagged_above=-999 required=5 tests=[AWL=-1.052, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kdAXYSY5huMo for ; Wed, 3 Dec 2008 07:46:43 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7D9723A6B23 for ; Wed, 3 Dec 2008 07:46:42 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7trd-0009Aa-9X for ccamp-data@psg.com; Wed, 03 Dec 2008 15:42:09 +0000 Received: from [130.76.96.56] (helo=stl-smtpout-01.boeing.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7trV-00099x-PR for ccamp@ops.ietf.org; Wed, 03 Dec 2008 15:42:04 +0000 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id mB3FfksF017452 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 3 Dec 2008 09:41:53 -0600 (CST) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id mB3Ffkp0000397; Wed, 3 Dec 2008 07:41:46 -0800 (PST) Received: from xch-swbh-11.sw.nos.boeing.com (xch-swbh-11.sw.nos.boeing.com [129.172.192.157]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id mB3Ffhcm000266; Wed, 3 Dec 2008 07:41:46 -0800 (PST) Received: from XCH-SW-5V2.sw.nos.boeing.com ([129.172.193.50]) by xch-swbh-11.sw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Dec 2008 07:41:45 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: CCAMP drafts for adoption Date: Wed, 3 Dec 2008 07:41:43 -0800 Message-ID: <51661468CBD1354294533DA79E85955A0148BB0B@XCH-SW-5V2.sw.nos.boeing.com> In-Reply-To: <53CCFDD6E346CB43994852666C210E9105B98CDB@esealmw116.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: CCAMP drafts for adoption Thread-Index: AclUl6mpWAW2o7P/QfKhDBZKhoe9CgABkY3AAAiyQSAAAP4GoAAAuZwwAABaoIAAACzaAAAAe+hQACNwvLAAAP1CgA== References: <001201c9549f$2dac4e50$d626fea9@china.huawei.com> <001601c954c0$d165bf10$470c7c0a@china.huawei.com> <7FA0C743C38E5340BFC2873488FA1E8E025DDF5E@emailcorp3.jnpr.net> <53CCFDD6E346CB43994852666C210E9105B70D91@esealmw116.eemea.ericsson.se> <7FA0C743C38E5340BFC2873488FA1E8E025DDF68@emailcorp3.jnpr.net> <53CCFDD6E346CB43994852666C210E9105B70DA5@esealmw116.eemea.ericsson.se> <7FA0C743C38E5340BFC2873488FA1E8E025DDF6A@emailcorp3.jnpr.net> <53CCFDD6E346CB43994852666C210E9105B98CDB@esealmw116.eemea.ericsson.se> From: "Drake, John E" To: "Attila Takacs" , "Nitin Bahadur" , X-OriginalArrivalTime: 03 Dec 2008 15:41:45.0456 (UTC) FILETIME=[A58CD700:01C9555D] Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Attila, Very well put. I think I-Ds in question should become working group drafts. Thanks, John=20 >-----Original Message----- >From: Attila Takacs [mailto:Attila.Takacs@ericsson.com]=20 >Sent: Wednesday, December 03, 2008 7:28 AM >To: Nitin Bahadur; ccamp@ops.ietf.org >Subject: RE: CCAMP drafts for adoption > >Hi Nitin,=20 > >>=20 >> If you add a new-TLV to the PATH msg, then you need to send it on=20 >> every PATH msg... >> You really need to signal the parameters once during LSP-setup time=20 >> (and perhaps when the parameters are changed). >>=20 > >There are some options here.=20 > >First it has clear benefits to have the OAM config bound to=20 >the Path message and so to the actual LSP establishment as=20 >this ensures that the connection and its OAM is coupled. This=20 >is something you cannot ensure with LSP Ping. > >Alternatively, if one just wants to configure MEPs one may=20 >carry the proposed TLVs as part of Call establishment, this=20 >way only the endpoints will take part in signaling. > >On the other hand, if one needs to configure MIPs, the=20 >signaling needs to pass intermediate nodes hence the need to=20 >use the Path message is obvious. > >> LSP-Ping has a whole bunch of stuff defined. Most of it is not=20 >> needed/applicable in various scenarios. But the advantage is=20 >that it's=20 >> all there. As you go ahead with defining a new mechanism, you will=20 >> gradually see other requirements/needs and you might end up=20 >> re-inventing lsp-ping in another form. >>=20 > >How would you configure MIPs with LSP Ping? I assume you would=20 >need to use at least as many transactions (and as such have as=20 >many failure >scenarios) as many intermediate nodes the LSP has. (Not to=20 >mention that you need to get the list of intermediate nodes=20 >and the info on the success/failure of LSP establishment from=20 >another protocol.) > >Compare this to a single Path message in the case of RSVP-TE. > >Best regards, >Attila > > > > >> > Best regards, >> > Attila >> >=20 >> >=20 >> >=20 >> >=20 >> > > -----Original Message----- >> > > From: Nitin Bahadur [mailto:nitinb@juniper.net] >> > > Sent: Tuesday, December 02, 2008 11:01 PM >> > > To: Attila Takacs; Adrian Farrel; ccamp@ops.ietf.org >> > > Subject: RE: CCAMP drafts for adoption >> > >=20 >> > >=20 >> > > Hi Attlia, >> > >=20 >> > > What is the limitation of lsp-ping that prevents it=20 >from being=20 >> > > applied to GMPLS? >> > > If an existing mechanism can be applied, then why not? If >> lsp-ping >> > > needs extensions to support GMPLS LSPs, feel free to=20 >make/specify=20 >> > > those extensions. >> > >=20 >> > > Thanks >> > > Nitin >> > >=20 >> > > > -----Original Message----- >> > > > From: Attila Takacs [mailto:Attila.Takacs@ericsson.com] >> > > > Sent: Tuesday, December 02, 2008 1:52 PM >> > > > To: Nitin Bahadur; Adrian Farrel; ccamp@ops.ietf.org >> > > > Subject: RE: CCAMP drafts for adoption >> > > >=20 >> > > > Hi Nitin, >> > > >=20 >> > > > Please note that these mechanisms are proposed for GMPLS >> > > and as such >> > > > to provide support for any data plane technology specific OAM=20 >> > > > mechanism. As you noted LSP Ping is for MPLS and BFD only. >> > > >=20 >> > > > Best regards, >> > > > Attila >> > > >=20 >> > > > > -----Original Message----- >> > > > > From: owner-ccamp@ops.ietf.org=20 >> > > > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Nitin Bahadur >> > > > > Sent: Tuesday, December 02, 2008 10:35 PM >> > > > > To: Adrian Farrel; ccamp@ops.ietf.org >> > > > > Subject: RE: CCAMP drafts for adoption >> > > > >=20 >> > > > >=20 >> > > > >=20 >> > > > > > > draft-takacs-ccamp-oam-configuration-fwk-01.txt >> > > > > > > draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt >> > > > >=20 >> > > > > Do not support either of these. >> > > > >=20 >> > > > > From the oam-config-fwk draft: >> > > > > > A new useful application of RSVP-TE is OAM configuration >> > > > > and control >> > > > > > for transport networks. >> > > > >=20 >> > > > > LSP-ping was designed as an OAM mechansim for MPLS LSPs.=20 >> > > Why do we >> > > > > need another mechanism? What are the limitations of >> > lsp-ping that >> > > > > warrant this new mechanism? >> > > > >=20 >> > > > > > When RSVP-TE is used for LSP establishment it is desirable >> > > > > to bind OAM >> > > > > > setup to connection establishment signalling to avoid two >> > > > separate >> > > > > > management/configuration steps >> > > > >=20 >> > > > > draft-ietf-bfd-mpls specifies how to use LSP-Ping for >> > > > automatic setup >> > > > > of BFD-based OAM. >> > > > > We should go along the same path for Ethernet OAM. >> > > > >=20 >> > > > > Thanks >> > > > > Nitin >> > > > >=20 >> > > > >=20 >> > > >=20 >> > >=20 >> >=20 >>=20 > > From owner-ccamp@ops.ietf.org Wed Dec 3 07:47:07 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B28313A6882 for ; Wed, 3 Dec 2008 07:47:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.547 X-Spam-Level: X-Spam-Status: No, score=-5.547 tagged_above=-999 required=5 tests=[AWL=-1.052, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fu6IsfjrSJPm for ; Wed, 3 Dec 2008 07:47:07 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4A5293A680A for ; Wed, 3 Dec 2008 07:47:07 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7trn-0009Bo-O9 for ccamp-data@psg.com; Wed, 03 Dec 2008 15:42:19 +0000 Received: from [130.76.96.56] (helo=stl-smtpout-01.boeing.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7trh-0009Ak-Hm for ccamp@ops.ietf.org; Wed, 03 Dec 2008 15:42:16 +0000 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id mB3Ffkwd017455 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 3 Dec 2008 09:41:53 -0600 (CST) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id mB3Ffk1o000453; Wed, 3 Dec 2008 07:41:46 -0800 (PST) Received: from xch-swbh-11.sw.nos.boeing.com (xch-swbh-11.sw.nos.boeing.com [129.172.192.157]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id mB3Ffhcq000266; Wed, 3 Dec 2008 07:41:46 -0800 (PST) Received: from XCH-SW-5V2.sw.nos.boeing.com ([129.172.193.50]) by xch-swbh-11.sw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Dec 2008 07:41:45 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: CCAMP drafts for adoption Date: Wed, 3 Dec 2008 07:41:43 -0800 Message-ID: <51661468CBD1354294533DA79E85955A0148BB0D@XCH-SW-5V2.sw.nos.boeing.com> In-Reply-To: <53CCFDD6E346CB43994852666C210E9105B98CDB@esealmw116.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: CCAMP drafts for adoption Thread-Index: AclUl6mpWAW2o7P/QfKhDBZKhoe9CgABkY3AAAiyQSAAAP4GoAAAuZwwAABaoIAAACzaAAAAe+hQACNwvLAAAP1CgA== References: <001201c9549f$2dac4e50$d626fea9@china.huawei.com> <001601c954c0$d165bf10$470c7c0a@china.huawei.com> <7FA0C743C38E5340BFC2873488FA1E8E025DDF5E@emailcorp3.jnpr.net> <53CCFDD6E346CB43994852666C210E9105B70D91@esealmw116.eemea.ericsson.se> <7FA0C743C38E5340BFC2873488FA1E8E025DDF68@emailcorp3.jnpr.net> <53CCFDD6E346CB43994852666C210E9105B70DA5@esealmw116.eemea.ericsson.se> <7FA0C743C38E5340BFC2873488FA1E8E025DDF6A@emailcorp3.jnpr.net> <53CCFDD6E346CB43994852666C210E9105B98CDB@esealmw116.eemea.ericsson.se> From: "Drake, John E" To: "Attila Takacs" , "Nitin Bahadur" , X-OriginalArrivalTime: 03 Dec 2008 15:41:45.0831 (UTC) FILETIME=[A5C60F70:01C9555D] Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Attila, Very well put. I think I-Ds in question should become working group drafts. Thanks, John=20 >-----Original Message----- >From: Attila Takacs [mailto:Attila.Takacs@ericsson.com]=20 >Sent: Wednesday, December 03, 2008 7:28 AM >To: Nitin Bahadur; ccamp@ops.ietf.org >Subject: RE: CCAMP drafts for adoption > >Hi Nitin,=20 > >>=20 >> If you add a new-TLV to the PATH msg, then you need to send it on=20 >> every PATH msg... >> You really need to signal the parameters once during LSP-setup time=20 >> (and perhaps when the parameters are changed). >>=20 > >There are some options here.=20 > >First it has clear benefits to have the OAM config bound to=20 >the Path message and so to the actual LSP establishment as=20 >this ensures that the connection and its OAM is coupled. This=20 >is something you cannot ensure with LSP Ping. > >Alternatively, if one just wants to configure MEPs one may=20 >carry the proposed TLVs as part of Call establishment, this=20 >way only the endpoints will take part in signaling. > >On the other hand, if one needs to configure MIPs, the=20 >signaling needs to pass intermediate nodes hence the need to=20 >use the Path message is obvious. > >> LSP-Ping has a whole bunch of stuff defined. Most of it is not=20 >> needed/applicable in various scenarios. But the advantage is=20 >that it's=20 >> all there. As you go ahead with defining a new mechanism, you will=20 >> gradually see other requirements/needs and you might end up=20 >> re-inventing lsp-ping in another form. >>=20 > >How would you configure MIPs with LSP Ping? I assume you would=20 >need to use at least as many transactions (and as such have as=20 >many failure >scenarios) as many intermediate nodes the LSP has. (Not to=20 >mention that you need to get the list of intermediate nodes=20 >and the info on the success/failure of LSP establishment from=20 >another protocol.) > >Compare this to a single Path message in the case of RSVP-TE. > >Best regards, >Attila > > > > >> > Best regards, >> > Attila >> >=20 >> >=20 >> >=20 >> >=20 >> > > -----Original Message----- >> > > From: Nitin Bahadur [mailto:nitinb@juniper.net] >> > > Sent: Tuesday, December 02, 2008 11:01 PM >> > > To: Attila Takacs; Adrian Farrel; ccamp@ops.ietf.org >> > > Subject: RE: CCAMP drafts for adoption >> > >=20 >> > >=20 >> > > Hi Attlia, >> > >=20 >> > > What is the limitation of lsp-ping that prevents it=20 >from being=20 >> > > applied to GMPLS? >> > > If an existing mechanism can be applied, then why not? If >> lsp-ping >> > > needs extensions to support GMPLS LSPs, feel free to=20 >make/specify=20 >> > > those extensions. >> > >=20 >> > > Thanks >> > > Nitin >> > >=20 >> > > > -----Original Message----- >> > > > From: Attila Takacs [mailto:Attila.Takacs@ericsson.com] >> > > > Sent: Tuesday, December 02, 2008 1:52 PM >> > > > To: Nitin Bahadur; Adrian Farrel; ccamp@ops.ietf.org >> > > > Subject: RE: CCAMP drafts for adoption >> > > >=20 >> > > > Hi Nitin, >> > > >=20 >> > > > Please note that these mechanisms are proposed for GMPLS >> > > and as such >> > > > to provide support for any data plane technology specific OAM=20 >> > > > mechanism. As you noted LSP Ping is for MPLS and BFD only. >> > > >=20 >> > > > Best regards, >> > > > Attila >> > > >=20 >> > > > > -----Original Message----- >> > > > > From: owner-ccamp@ops.ietf.org=20 >> > > > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Nitin Bahadur >> > > > > Sent: Tuesday, December 02, 2008 10:35 PM >> > > > > To: Adrian Farrel; ccamp@ops.ietf.org >> > > > > Subject: RE: CCAMP drafts for adoption >> > > > >=20 >> > > > >=20 >> > > > >=20 >> > > > > > > draft-takacs-ccamp-oam-configuration-fwk-01.txt >> > > > > > > draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt >> > > > >=20 >> > > > > Do not support either of these. >> > > > >=20 >> > > > > From the oam-config-fwk draft: >> > > > > > A new useful application of RSVP-TE is OAM configuration >> > > > > and control >> > > > > > for transport networks. >> > > > >=20 >> > > > > LSP-ping was designed as an OAM mechansim for MPLS LSPs.=20 >> > > Why do we >> > > > > need another mechanism? What are the limitations of >> > lsp-ping that >> > > > > warrant this new mechanism? >> > > > >=20 >> > > > > > When RSVP-TE is used for LSP establishment it is desirable >> > > > > to bind OAM >> > > > > > setup to connection establishment signalling to avoid two >> > > > separate >> > > > > > management/configuration steps >> > > > >=20 >> > > > > draft-ietf-bfd-mpls specifies how to use LSP-Ping for >> > > > automatic setup >> > > > > of BFD-based OAM. >> > > > > We should go along the same path for Ethernet OAM. >> > > > >=20 >> > > > > Thanks >> > > > > Nitin >> > > > >=20 >> > > > >=20 >> > > >=20 >> > >=20 >> >=20 >>=20 > > From owner-ccamp@ops.ietf.org Wed Dec 3 11:25:08 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B88683A6A10 for ; Wed, 3 Dec 2008 11:25:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.494 X-Spam-Level: X-Spam-Status: No, score=-0.494 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b-CFkuMXg-GU for ; Wed, 3 Dec 2008 11:25:07 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5B03F3A69F5 for ; Wed, 3 Dec 2008 11:25:07 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7xGD-000OIh-Bc for ccamp-data@psg.com; Wed, 03 Dec 2008 19:19:45 +0000 Received: from [72.14.220.159] (helo=fg-out-1718.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L7xG5-000OIA-6H for ccamp@ops.ietf.org; Wed, 03 Dec 2008 19:19:39 +0000 Received: by fg-out-1718.google.com with SMTP id 13so2548395fge.11 for ; Wed, 03 Dec 2008 11:19:35 -0800 (PST) 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:cc:in-reply-to:mime-version:content-type:references; bh=c5E9PRHVwfw7RgE98aA9FiJ4fy7shAL6vVKrL5Sbi9g=; b=FZhOlJJmqqMRASJw3A4wUCTaFP/qMp2sxo1r7sE9nNypTlVgQZyXvIW7Fo/+GvM3l6 WmgEF3oQc5uij+JSQc5/lAOQXieWihkCCfgJlDE0+tasZ84A+AIXhrsOpB2Pj+1wi6Z5 1keGC6D3VyYK90dfhY/AvHT0kbnDOCSM/oN6M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=sEsKRJBIwPPAA7IJ8L/FRo/9/oXxzQQHnwTKAn1DyX4x4knNtJMMZqxAs4YGYEiVWQ 2Hrw1XLmqAz99ENbtAf22fJGtU+2X4O2STUETz53PP9Tw+p1Zp1Z1pOz09qF1mwLRb0W JVLW1eV7cZiJk4FOYvPhM1hKEAmWsCU9dRPlY= Received: by 10.181.226.19 with SMTP id d19mr4759628bkr.35.1228331975193; Wed, 03 Dec 2008 11:19:35 -0800 (PST) Received: by 10.180.213.3 with HTTP; Wed, 3 Dec 2008 11:19:35 -0800 (PST) Message-ID: <787be2780812031119v659923acy1cfb8152455aef54@mail.gmail.com> Date: Wed, 3 Dec 2008 14:19:35 -0500 From: "Greg Mirsky" To: "Adrian Farrel" Subject: Re: CCAMP drafts for adoption Cc: ccamp@ops.ietf.org In-Reply-To: <2089B64D43144AEEA390F5C4C7232087@your029b8cecfe> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_13614_6381331.1228331975178" References: <2089B64D43144AEEA390F5C4C7232087@your029b8cecfe> Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: ------=_Part_13614_6381331.1228331975178 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Support oam-configuration and eth-oam Abstain wson-encode Regards, Greg On Tue, Dec 2, 2008 at 11:01 AM, Adrian Farrel wrote: > Hi, > > Can you please express your opinion on the adoption of the following three > drafts as WG drafts. > > Thanks, > Adrian > > draft-takacs-ccamp-oam-configuration-fwk-01.txt > draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt > draft-bernstein-ccamp-wson-encode-01.txt (to become -rwa-encode-00) > > Cheers, > Adrian and Deborah > > > ------=_Part_13614_6381331.1228331975178 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Support oam-configuration and eth-oam
Abstain wson-encode

Regards,
Greg

On Tue, Dec 2, 2008 at 11:01 AM, Adrian Farrel <adrian@olddog.co.uk> wrote:
Hi,

Can you please express your opinion on the adoption of the following three drafts as WG drafts.

Thanks,
Adrian

draft-takacs-ccamp-oam-configuration-fwk-01.txt
draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt
draft-bernstein-ccamp-wson-encode-01.txt (to become -rwa-encode-00)

Cheers,
Adrian and Deborah



------=_Part_13614_6381331.1228331975178-- From owner-ccamp@ops.ietf.org Wed Dec 3 17:40:00 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BF433A67AD for ; Wed, 3 Dec 2008 17:40:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w9Nvuof0Vehn for ; Wed, 3 Dec 2008 17:39:59 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9A3303A65A5 for ; Wed, 3 Dec 2008 17:39:59 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L836s-000Kv9-7K for ccamp-data@psg.com; Thu, 04 Dec 2008 01:34:30 +0000 Received: from [2001:200:601:12:230:48ff:fe22:3a84] (helo=mandala.kddilabs.jp) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L836m-000Kun-2V for ccamp@ops.ietf.org; Thu, 04 Dec 2008 01:34:27 +0000 Received: from localhost (localhost [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id 0DD5EEC963 for ; Thu, 4 Dec 2008 10:34:23 +0900 (JST) Received: from platinum.inc.kddilabs.jp (platinum.inc.kddilabs.jp [2001:200:601:1300:172:19:83:254]) by mandala.kddilabs.jp (Postfix) with ESMTP id CB89EEC961 for ; Thu, 4 Dec 2008 10:34:22 +0900 (JST) Received: from [IPv6:::1] (unknown [IPv6:2001:200:601:2450:d852:e31f:cdb2:6d59]) by platinum.inc.kddilabs.jp (Postfix) with ESMTP id 13172578111 for ; Thu, 4 Dec 2008 10:34:21 +0900 (JST) Message-ID: <49373388.2020505@cn.kddilabs.jp> Date: Thu, 04 Dec 2008 10:34:00 +0900 From: "Ogaki, Kenichi" User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: ccamp@ops.ietf.org Subject: Re: CCAMP drafts for adoption References: <2089B64D43144AEEA390F5C4C7232087@your029b8cecfe> In-Reply-To: <2089B64D43144AEEA390F5C4C7232087@your029b8cecfe> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Hi, Yes to All. Kenichi Adrian Farrel wrote: > Hi, > > Can you please express your opinion on the adoption of the following > three drafts as WG drafts. > > Thanks, > Adrian > > draft-takacs-ccamp-oam-configuration-fwk-01.txt > draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt > draft-bernstein-ccamp-wson-encode-01.txt (to become -rwa-encode-00) > > Cheers, > Adrian and Deborah > > > From kim@amacalert.com Wed Dec 3 19:51:46 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFA043A680C for ; Wed, 3 Dec 2008 19:51:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.717 X-Spam-Level: X-Spam-Status: No, score=-9.717 tagged_above=-999 required=5 tests=[BAYES_60=1, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR2=4.395, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_RCVD_IP=1.931, TVD_SPACE_RATIO=2.219, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cP5UslnvAQLL for ; Wed, 3 Dec 2008 19:51:46 -0800 (PST) Received: from 215-72-223-201.adsl.terra.cl (215-72-223-201.adsl.terra.cl [201.223.72.215]) by core3.amsl.com (Postfix) with SMTP id 9FAA53A68EF for ; Wed, 3 Dec 2008 19:51:24 -0800 (PST) To: Subject: RE: Message From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081204035125.9FAA53A68EF@core3.amsl.com> Date: Wed, 3 Dec 2008 19:51:24 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From owner-ccamp@ops.ietf.org Thu Dec 4 00:10:08 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEC953A698E for ; Thu, 4 Dec 2008 00:10:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EVs528N0x7+b for ; Thu, 4 Dec 2008 00:10:05 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B51783A6953 for ; Thu, 4 Dec 2008 00:10:04 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L89D7-000Frs-3K for ccamp-data@psg.com; Thu, 04 Dec 2008 08:05:21 +0000 Received: from [119.145.14.67] (helo=szxga04-in.huawei.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L89D2-000FrQ-1d for ccamp@ops.ietf.org; Thu, 04 Dec 2008 08:05:18 +0000 Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KBC00AB7EDLV8@szxga04-in.huawei.com> for ccamp@ops.ietf.org; Thu, 04 Dec 2008 16:03:21 +0800 (CST) Received: from huawei.com ([172.17.1.36]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KBC00EGOEDLJC@szxga04-in.huawei.com> for ccamp@ops.ietf.org; Thu, 04 Dec 2008 16:03:21 +0800 (CST) Received: from [172.24.1.6] (Forwarded-For: [156.106.219.17]) by szxmc04-in.huawei.com (mshttpd); Thu, 04 Dec 2008 00:03:21 -0800 Date: Thu, 04 Dec 2008 00:03:21 -0800 From: hejia 48726 Subject: Re: CCAMP drafts for adoption In-reply-to: <006c01c9555d$57e38da0$3b0c7c0a@china.huawei.com> To: Adrian Farrel Cc: ccamp@ops.ietf.org Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: zh-CN References: <2089B64D43144AEEA390F5C4C7232087@your029b8cecfe> <006c01c9555d$57e38da0$3b0c7c0a@china.huawei.com> Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Support All to become WG drafts. Thanks! B.R. Jia > > ----- Original Message ----- > From: "Adrian Farrel" > To: > Sent: Tuesday, December 02, 2008 10:01 AM > Subject: CCAMP drafts for adoption > > > > Hi, > > > > Can you please express your opinion on the adoption of the > following three > > drafts as WG drafts. > > > > Thanks, > > Adrian > > > > draft-takacs-ccamp-oam-configuration-fwk-01.txt > > draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt > > draft-bernstein-ccamp-wson-encode-01.txt (to become -rwa-encode-00) > > > > Cheers, > > Adrian and Deborah > > > > > > > > > > From kadir@123hikaye.com Thu Dec 4 04:26:46 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F5FD3A6A30 for ; Thu, 4 Dec 2008 04:26:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.791 X-Spam-Level: X-Spam-Status: No, score=-14.791 tagged_above=-999 required=5 tests=[BAYES_60=1, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_SPACE_RATIO=2.219, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Db3BxmOB+HOW for ; Thu, 4 Dec 2008 04:26:46 -0800 (PST) Received: from 88-170-124-91.pool.ukrtel.net (88-170-124-91.pool.ukrtel.net [91.124.170.88]) by core3.amsl.com (Postfix) with SMTP id B2CA03A6919 for ; Thu, 4 Dec 2008 04:26:43 -0800 (PST) To: Subject: Delivery Status Notification (Failure) From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081204122644.B2CA03A6919@core3.amsl.com> Date: Thu, 4 Dec 2008 04:26:43 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From owner-ccamp@ops.ietf.org Thu Dec 4 07:02:04 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 177613A69D9 for ; Thu, 4 Dec 2008 07:02:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[AWL=-0.789, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_LOW=-1, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 47-IsPefkmRe for ; Thu, 4 Dec 2008 07:02:03 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4B2AE3A6A9C for ; Thu, 4 Dec 2008 07:02:03 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L8FcZ-000GTs-8r for ccamp-data@psg.com; Thu, 04 Dec 2008 14:56:03 +0000 Received: from [195.101.245.16] (helo=p-mail2.rd.francetelecom.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L8FcU-000GTX-1H for ccamp@ops.ietf.org; Thu, 04 Dec 2008 14:56:00 +0000 Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Dec 2008 15:55:50 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 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: CCAMP drafts for adoption Date: Thu, 4 Dec 2008 15:55:50 +0100 Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB026060DF128@ftrdmel2> In-Reply-To: <2089B64D43144AEEA390F5C4C7232087@your029b8cecfe> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: CCAMP drafts for adoption Thread-Index: AclUl+PUbH0AlGVYSwK0Eoml59nxoQBiC0ew References: <2089B64D43144AEEA390F5C4C7232087@your029b8cecfe> From: To: , X-OriginalArrivalTime: 04 Dec 2008 14:55:50.0728 (UTC) FILETIME=[66047480:01C95620] Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Hello. I support the 3 of them. I also think that some of the arguments highlighted by Attila, Igor, = Dave, Adrian... may deserve to be incorporated in the 1st I-D to avoid = looping again on this kind of clarification. Regards, Julien -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On = Behalf Of Adrian Farrel Hi, Can you please express your opinion on the adoption of the following = three=20 drafts as WG drafts. Thanks, Adrian draft-takacs-ccamp-oam-configuration-fwk-01.txt draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt draft-bernstein-ccamp-wson-encode-01.txt (to become -rwa-encode-00) Cheers, Adrian and Deborah=20 From mehrdad@ami-usa.com Thu Dec 4 11:04:32 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 643DA3A6B39 for ; Thu, 4 Dec 2008 11:04:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -29.294 X-Spam-Level: X-Spam-Status: No, score=-29.294 tagged_above=-999 required=5 tests=[BAYES_95=3, HELO_EQ_DSL=1.129, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_SPACE_RATIO=2.219, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02V8aGAMUISC for ; Thu, 4 Dec 2008 11:04:31 -0800 (PST) Received: from aayn13.neoplus.adsl.tpnet.pl (aayd118.neoplus.adsl.tpnet.pl [83.6.115.118]) by core3.amsl.com (Postfix) with SMTP id B56013A6AA6 for ; Thu, 4 Dec 2008 11:04:28 -0800 (PST) To: Subject: RE: Message From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081204190429.B56013A6AA6@core3.amsl.com> Date: Thu, 4 Dec 2008 11:04:28 -0800 (PST) Click here to view as a webpage From majordomo@akiragraphics.com Fri Dec 5 04:22:44 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B1563A6C6B for ; Fri, 5 Dec 2008 04:22:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.51 X-Spam-Level: X-Spam-Status: No, score=-16.51 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SC_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1NaeCj6tQPzR for ; Fri, 5 Dec 2008 04:22:43 -0800 (PST) Received: from 83-223-160-84.cpe.netmadeira.com (83-223-160-84.cpe.netmadeira.com [83.223.160.84]) by core3.amsl.com (Postfix) with SMTP id 8078A3A6C69 for ; Fri, 5 Dec 2008 04:22:42 -0800 (PST) To: Subject: Re: Order status From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081205122242.8078A3A6C69@core3.amsl.com> Date: Fri, 5 Dec 2008 04:22:42 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From owner-ccamp@ops.ietf.org Fri Dec 5 09:06:40 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8B353A6AFD for ; Fri, 5 Dec 2008 09:06:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.057 X-Spam-Level: X-Spam-Status: No, score=-102.057 tagged_above=-999 required=5 tests=[AWL=0.543, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LaaQYpR5PLil for ; Fri, 5 Dec 2008 09:06:39 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 804A328C1D7 for ; Fri, 5 Dec 2008 09:06:24 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L8e28-0006ZP-RA for ccamp-data@psg.com; Fri, 05 Dec 2008 17:00:04 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L8e22-0006YU-OU for ccamp@ops.ietf.org; Fri, 05 Dec 2008 17:00:01 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id 0F07C3A69B4; Fri, 5 Dec 2008 09:00:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org Subject: I-D Action:draft-ietf-ccamp-rwa-wson-framework-00.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081205170002.0F07C3A69B4@core3.amsl.com> Date: Fri, 5 Dec 2008 09:00:02 -0800 (PST) Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: --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 : Framework for GMPLS and PCE Control of Wavelength Switched Optical Networks (WSON) Author(s) : G. Bernstein Filename : draft-ietf-ccamp-rwa-wson-framework-00.txt Pages : 37 Date : 2008-12-05 This memo provides a framework for applying Generalized Multi- Protocol Label Switching (GMPLS) and the Path Computation Element (PCE) architecture to the control of wavelength switched optical networks (WSON). In particular we provide control plane models for key wavelength switched optical network subsystems and processes. The subsystems include wavelength division multiplexed links, tunable laser transmitters, reconfigurable optical add/drop multiplexers (ROADM) and wavelength converters. Lightpath provisioning, in general, requires the routing and wavelength assignment (RWA) process. This process is reviewed and the information requirements, both static and dynamic for this process are presented, along with alternative implementation scenarios that could be realized via GMPLS/PCE and/or extended GMPLS/PCE protocols. This memo does NOT address optical impairments in any depth and focuses on topological elements and path selection constraints that are common across different WSON environments. It is expected that a variety of different techniques will be applied to optical impairments depending on the type of WSON, such as access, metro or long haul. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rwa-wson-framework-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-ccamp-rwa-wson-framework-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-12-05085244.I-D@ietf.org> --NextPart-- From oni@alk.com Fri Dec 5 11:07:29 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37FAC3A63EB for ; Fri, 5 Dec 2008 11:07:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -53.33 X-Spam-Level: X-Spam-Status: No, score=-53.33 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_SPACE_RATIO=2.219, URIBL_AB_SURBL=10, URIBL_BLACK=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nz-5zTHGslzT for ; Fri, 5 Dec 2008 11:07:27 -0800 (PST) Received: from akka.com (unknown [94.178.79.123]) by core3.amsl.com (Postfix) with SMTP id AF2163A68A7 for ; Fri, 5 Dec 2008 11:07:25 -0800 (PST) To: Subject: Delivery Status Notification (Failure) From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081205190726.AF2163A68A7@core3.amsl.com> Date: Fri, 5 Dec 2008 11:07:25 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From lindamobley@affinity1.com Fri Dec 5 12:12:37 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 892D53A6C98 for ; Fri, 5 Dec 2008 12:12:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -27.967 X-Spam-Level: X-Spam-Status: No, score=-27.967 tagged_above=-999 required=5 tests=[BAYES_80=2, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_DYNAMIC_IPADDR2=4.395, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_EQ_DSL=1.129, HELO_EQ_DYNAMIC=1.144, HELO_EQ_IP_ADDR=1.119, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_NUMERIC_HELO=2.067, RDNS_DYNAMIC=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_RCVD_IP=1.931, TVD_SPACE_RATIO=2.219, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DSN1+-BtlVTX for ; Fri, 5 Dec 2008 12:12:36 -0800 (PST) Received: from 177.117.32.95.c10008-a77.dsl-dynamic.vsi.ru (177.117.32.95.c10008-a77.dsl-dynamic.vsi.ru [95.32.117.177]) by core3.amsl.com (Postfix) with SMTP id B699C3A6C9A for ; Fri, 5 Dec 2008 12:12:35 -0800 (PST) To: Subject: RE: Message From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081205201235.B699C3A6C9A@core3.amsl.com> Date: Fri, 5 Dec 2008 12:12:35 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From claude@m5digital.ca Sat Dec 6 06:21:26 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4CAF3A6954; Sat, 6 Dec 2008 06:21:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -21.656 X-Spam-Level: X-Spam-Status: No, score=-21.656 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SBL=20, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yp1C-zwpHeHa; Sat, 6 Dec 2008 06:21:25 -0800 (PST) Received: from chello085216136197.chello.sk (chello085216136197.chello.sk [85.216.136.197]) by core3.amsl.com (Postfix) with SMTP id A51C03A683B; Sat, 6 Dec 2008 06:21:12 -0800 (PST) Message-ID: Date: Sat, 06 Dec 2008 09:20:46 -0500 From: "Loren Morales" Subject: Chopard watch for a christmas gift To: architecture-discuss@ietf.org Content-Type: text/plain Content-Transfer-Encoding: 7bit Hello Loren Christmas is the time to get Cartier watch, and the only place to get top notch watches that look and perform exactly like the originals is http://www.nuxancub.com/ The best news is that in December you can buy two watches and get an extra 15% off your purchase! http://www.nuxancub.com/ Sincerely, Mr Morales From nicolas.gorczyca@agscom.com Sat Dec 6 07:29:29 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A3EA3A6952 for ; Sat, 6 Dec 2008 07:29:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.884 X-Spam-Level: X-Spam-Status: No, score=-12.884 tagged_above=-999 required=5 tests=[BAYES_60=1, FH_RELAY_NODNS=1.451, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_SPACE_RATIO=2.219, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XcrFXn8sHDfa for ; Sat, 6 Dec 2008 07:29:28 -0800 (PST) Received: from accountancy.smu.edu.sg (unknown [190.79.26.43]) by core3.amsl.com (Postfix) with SMTP id 77C743A68D1 for ; Sat, 6 Dec 2008 07:29:25 -0800 (PST) To: Subject: Delivery Status Notification From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081206152926.77C743A68D1@core3.amsl.com> Date: Sat, 6 Dec 2008 07:29:25 -0800 (PST) Click to visit Official Web Site! From lerejbn@adwareeraser.com Sat Dec 6 07:57:15 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 035943A67FC for ; Sat, 6 Dec 2008 07:57:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.467 X-Spam-Level: X-Spam-Status: No, score=-13.467 tagged_above=-999 required=5 tests=[BAYES_60=1, HELO_EQ_DYNAMIC=1.144, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_SPACE_RATIO=2.219, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aqtm8Hr3oQUt for ; Sat, 6 Dec 2008 07:57:14 -0800 (PST) Received: from host52-112-dynamic.8-87-r.retail.telecomitalia.it (host52-112-dynamic.8-87-r.retail.telecomitalia.it [87.8.112.52]) by core3.amsl.com (Postfix) with SMTP id 2B0843A67B3 for ; Sat, 6 Dec 2008 07:57:12 -0800 (PST) To: Subject: Delivery Status Notification (Failure) From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081206155713.2B0843A67B3@core3.amsl.com> Date: Sat, 6 Dec 2008 07:57:12 -0800 (PST) Click to visit Official Web Site! From albert.horan@boi.ie Sat Dec 6 09:56:42 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B9203A67AC; Sat, 6 Dec 2008 09:56:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.504 X-Spam-Level: *** X-Spam-Status: No, score=3.504 tagged_above=-999 required=5 tests=[BAYES_95=3, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_DSL=1.129, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SBL=20, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3haVFOGtcYcr; Sat, 6 Dec 2008 09:56:41 -0800 (PST) Received: from 101-106-21-190.adsl.terra.cl (101-106-21-190.adsl.terra.cl [190.21.106.101]) by core3.amsl.com (Postfix) with SMTP id 8973C3A680A; Sat, 6 Dec 2008 09:56:26 -0800 (PST) Message-ID: Date: Sat, 06 Dec 2008 12:56:26 -0500 From: "Federico Lockett" Subject: Patek Phillipe watch for a christmas gift To: atompub-archive@megatron.ietf.org Content-Type: text/plain Content-Transfer-Encoding: 7bit Hello Federico If you've waited to get your IWC watch, this is the right time to go for it. http://www.pawovyaj.com/ Get two deeply discounted watches and take an extra 15% discount. http://www.pawovyaj.com/ Sincerely, Mr Lockett From knight@aimla.com Sat Dec 6 17:09:16 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAE793A68CE for ; Sat, 6 Dec 2008 17:09:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.088 X-Spam-Level: X-Spam-Status: No, score=-13.088 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_SPACE_RATIO=2.219, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7CwauHP43Mkx for ; Sat, 6 Dec 2008 17:09:16 -0800 (PST) Received: from ppp-58-8-121-33.revip2.asianet.co.th (ppp-58-8-115-209.revip2.asianet.co.th [58.8.115.209]) by core3.amsl.com (Postfix) with SMTP id A4C003A6358 for ; Sat, 6 Dec 2008 17:09:13 -0800 (PST) To: Subject: RE: Message From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081207010914.A4C003A6358@core3.amsl.com> Date: Sat, 6 Dec 2008 17:09:13 -0800 (PST) Click to visit Official Web Site! From motosycuatriciclos2008_@gmail.com Sat Dec 6 20:09:10 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2442B3A67AD for ; Sat, 6 Dec 2008 20:09:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.598 X-Spam-Level: **** X-Spam-Status: No, score=4.598 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_50=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, SUBJ_ALL_CAPS=2.077, UPPERCASE_50_75=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BIhR0nh17kDL for ; Sat, 6 Dec 2008 20:09:08 -0800 (PST) Received: from maildcarg4.dc-host.net.ar (maildcarg4.dc-host.net.ar [200.55.6.135]) by core3.amsl.com (Postfix) with ESMTP id 7676F3A6407 for ; Sat, 6 Dec 2008 20:09:08 -0800 (PST) Received: from localhost ([190.245.9.133]) by maildcarg4.dc-host.net.ar (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPA id <0KBH009YPNIK7K00@maildcarg4.dc-host.net.ar> for ccamp-archive@ietf.org; Sun, 07 Dec 2008 01:08:45 -0300 (ART) Received: from f3t ([127.0.0.1]) by localhost with SMTP (Code-Crafters Ability Mail Server 2.61); Sun, 07 Dec 2008 02:08:46 +0100 Date: Sun, 07 Dec 2008 02:08:46 +0100 From: "motosycuatriciclos2008@gmail.com" Subject: MOTOS Y CUATRICICLOS PARA EL INTERIOR To: myc Reply-to: "motosycuatriciclos2008@gmail.com" Message-id: <381-2200812071846343@f3t> MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable MOTOS Y CUATRICICLOS * CONCESIONARIA OFICIAL * ZANELLA-MONDIAL- JIANSHE-X-SCREAMS- PHANTER- CERRO EMAIL: motosycuatriciclos2008@gmail=2Ecom BUSCA REVENDEDORES PARA TODO EL PAIS Beneficios:=20 FINANCIACI=D3N HASTA 36 CUOTAS FIJAS PARA SUS CLIENTES con CON RECIBO DE S= UELDO Y/=D3 MONOTRIBUTO, o JUBILACION o PENSION Puede realizar el pago con tarjeta de credito Telefonicamente, tarjetas VI= SA, Mastercard, American Express, Tarjeta Naranja, Cabal y Tarjeta Shoppin= g hasta en 24 cuotas FIJAS y en PESOS SEGUROS: ATM EN RESPONSABILIDAD CIVIL Y ROBO SERVICIO DE GESTOR=CDA Y ASESORAMIENTO PARA PATENTAR LA UNIDAD SOMOS REPRESENTANTES DE LO JACK CASCOS, ACCESORIOS, REPUESTOS (los requisitos son D=2EN=2EI , recibo de sueldo y un servicio)=2E Los precios incluyen iva 21 % y hacemos Factura tipo A o B, facturamos al = cliente de manera directa, con lo cual no tiene que estar inscripto No dude en consultar Email: motosycuatriciclos2008@gmail=2Ecom MSN: motosycuatriciclos2008@gmail=2Ecom From ossowski@akaentertainment.com Sat Dec 6 21:07:26 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E67E3A6816 for ; Sat, 6 Dec 2008 21:07:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.873 X-Spam-Level: X-Spam-Status: No, score=-6.873 tagged_above=-999 required=5 tests=[BAYES_80=2, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_NJABL_PROXY=1.643, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_SPACE_RATIO=2.219, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AbE546tWo3Nz for ; Sat, 6 Dec 2008 21:07:25 -0800 (PST) Received: from aiaa.org (unknown [200.159.50.202]) by core3.amsl.com (Postfix) with SMTP id 362C93A67EE for ; Sat, 6 Dec 2008 21:07:23 -0800 (PST) To: Subject: Delivery Status Notification From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081207050724.362C93A67EE@core3.amsl.com> Date: Sat, 6 Dec 2008 21:07:23 -0800 (PST) Click to visit Official Web Site! From lpizanid@alpes2.com Sat Dec 6 21:24:05 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D814F3A6829 for ; Sat, 6 Dec 2008 21:24:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.011 X-Spam-Level: * X-Spam-Status: No, score=1.011 tagged_above=-999 required=5 tests=[BAYES_80=2, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_VERIZON_P=2.144, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_VERIZON_POOL=1.495, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_SPACE_RATIO=2.219, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zzphM9UlCABd for ; Sat, 6 Dec 2008 21:24:05 -0800 (PST) Received: from pool-96-235-179-160.cmdnnj.fios.verizon.net (pool-96-235-179-160.cmdnnj.fios.verizon.net [96.235.179.160]) by core3.amsl.com (Postfix) with SMTP id 786D63A67F6 for ; Sat, 6 Dec 2008 21:24:03 -0800 (PST) To: Subject: Delivery Status Notification From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081207052404.786D63A67F6@core3.amsl.com> Date: Sat, 6 Dec 2008 21:24:03 -0800 (PST) Click to visit Official Web Site! From jt200707271458112.8062546@ai-city.net Sat Dec 6 22:26:36 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC4A93A6866 for ; Sat, 6 Dec 2008 22:26:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.872 X-Spam-Level: X-Spam-Status: No, score=-11.872 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id faQxu7TjFxkR for ; Sat, 6 Dec 2008 22:26:36 -0800 (PST) Received: from accenture.com (unknown [190.191.176.253]) by core3.amsl.com (Postfix) with SMTP id DD9023A6818 for ; Sat, 6 Dec 2008 22:26:30 -0800 (PST) To: Subject: Your order From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081207062631.DD9023A6818@core3.amsl.com> Date: Sat, 6 Dec 2008 22:26:30 -0800 (PST) Click to visit Official Web Site! From nori@aktivpress.pl Sat Dec 6 23:21:45 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 920853A6866 for ; Sat, 6 Dec 2008 23:21:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.347 X-Spam-Level: X-Spam-Status: No, score=-3.347 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3iSNBOp0vW03 for ; Sat, 6 Dec 2008 23:21:45 -0800 (PST) Received: from host86-165-245-239.range86-165.btcentralplus.com (host81-159-238-163.range81-159.btcentralplus.com [81.159.238.163]) by core3.amsl.com (Postfix) with SMTP id CE6BA3A6850 for ; Sat, 6 Dec 2008 23:21:42 -0800 (PST) To: Subject: Your order From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081207072143.CE6BA3A6850@core3.amsl.com> Date: Sat, 6 Dec 2008 23:21:42 -0800 (PST) Click to visit Official Web Site! From milda@hadawaynet.com Sun Dec 7 07:49:01 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A8813A6993; Sun, 7 Dec 2008 07:49:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.551 X-Spam-Level: X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_AU=0.377, HELO_EQ_CPE=0.5, HOST_EQ_AU=0.327, HOST_EQ_CPE=0.979, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SBL=20, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IcpmuDyfexHP; Sun, 7 Dec 2008 07:49:00 -0800 (PST) Received: from CPE-124-190-235-248.vic.bigpond.net.au (CPE-124-190-235-248.vic.bigpond.net.au [124.190.235.248]) by core3.amsl.com (Postfix) with SMTP id 176433A6992; Sun, 7 Dec 2008 07:48:46 -0800 (PST) Message-ID: Date: Sun, 07 Dec 2008 10:48:38 -0500 From: "Berry Orozco" Subject: Cartier watch for a christmas gift To: atompub-archive@megatron.ietf.org Content-Type: text/plain Content-Transfer-Encoding: 7bit Hello Berry Looking for a Franck Muller watch that no one can tell from the original? You're in luck, because we have the best copies http://www.punihkek.com/ Take an extra 15% off your purchase during month of December. http://www.punihkek.com/ Sincerely, Mr Orozco From dick.claesson@ordfabriken.com Sun Dec 7 10:59:19 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7332D3A6851; Sun, 7 Dec 2008 10:59:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.374 X-Spam-Level: X-Spam-Status: No, score=-7.374 tagged_above=-999 required=5 tests=[BAYES_80=2, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, FRT_ROLEX=3.878, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HELO_EQ_DSL=1.129, HELO_EQ_TELESP=1.245, HOST_EQ_BR=1.295, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1, SARE_RECV_SPAM_DOMN02=1.666, TVD_RCVD_IP=1.931, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SBL=20, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mVx0SSvi9Hhz; Sun, 7 Dec 2008 10:59:18 -0800 (PST) Received: from 189-69-39-201.dsl.telesp.net.br (189-69-39-201.dsl.telesp.net.br [189.69.39.201]) by core3.amsl.com (Postfix) with SMTP id 4B99C3A677C; Sun, 7 Dec 2008 10:59:02 -0800 (PST) Message-ID: Date: Sun, 07 Dec 2008 13:58:57 -0500 From: "Lena Buck" Subject: Ro lex better than original To: architecture-discuss@ietf.org Content-Type: text/plain Content-Transfer-Encoding: 7bit Hello Lena I had never seen such beautiful and greatly-performing watches like the ones I found online at http://www.nazedlav.com/ With top notch customer service and super warranty, we stand behind our watches. http://www.nazedlav.com/ Sincerely, Mr Buck From buzz@proj-x.com Sun Dec 7 11:16:15 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC07C3A6851; Sun, 7 Dec 2008 11:16:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.188 X-Spam-Level: X-Spam-Status: No, score=-10.188 tagged_above=-999 required=5 tests=[BAYES_80=2, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DSL=1.129, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SBL=20, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k-oTSlykmFzm; Sun, 7 Dec 2008 11:16:14 -0800 (PST) Received: from adsl196-78-135-206-196.adsl196-5.iam.net.ma (adsl196-78-135-206-196.adsl196-5.iam.net.ma [196.206.135.78]) by core3.amsl.com (Postfix) with SMTP id CB9373A677C; Sun, 7 Dec 2008 11:15:32 -0800 (PST) Message-ID: Date: Sun, 07 Dec 2008 14:15:27 -0500 From: "Javier Hutchison" Subject: Omega watch for a christmas gift To: architecture-discuss@ietf.org Content-Type: text/plain Content-Transfer-Encoding: 7bit Hello Javier Looking for a Emporio Armani watch that no one can tell from the original? You're in luck, because we have the best copies http://www.pelabbiy.com/ Take advantage of our christmas specials and get yourself Emporio Armani watch that you've always wanted! http://www.pelabbiy.com/ Sincerely, Mr Hutchison From owner-ccamp@ops.ietf.org Sun Dec 7 18:21:57 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D993C3A6966 for ; Sun, 7 Dec 2008 18:21:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.036 X-Spam-Level: X-Spam-Status: No, score=-102.036 tagged_above=-999 required=5 tests=[AWL=0.564, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id crOhOq+WEQuM for ; Sun, 7 Dec 2008 18:21:57 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D00373A67FD for ; Sun, 7 Dec 2008 18:21:56 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L9VeR-000HMn-65 for ccamp-data@psg.com; Mon, 08 Dec 2008 02:15:11 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L9VeH-000HLs-TZ for ccamp@ops.ietf.org; Mon, 08 Dec 2008 02:15:06 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id E06AE3A69B3; Sun, 7 Dec 2008 18:15:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org Subject: I-D Action:draft-ietf-ccamp-lsp-dppm-03.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081208021501.E06AE3A69B3@core3.amsl.com> Date: Sun, 7 Dec 2008 18:15:01 -0800 (PST) Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: --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 : Label Switched Path (LSP) Dynamic Provisioning Performance Metrics in Generalized MPLS Networks Author(s) : W. Sun, et al. Filename : draft-ietf-ccamp-lsp-dppm-03.txt Pages : 48 Date : 2008-12-04 Generalized Multi-Protocol Label Switching (GMPLS) is one of the most promising candidate technologies for future data transmission network. GMPLS has been developed to control and operate different kinds of network elements, such as conventional routers, switches, Dense Wavelength Division Multiplexing (DWDM) systems, Add- Drop Multiplexors (ADMs), photonic cross-connects (PXCs), optical cross- connects (OXCs), etc. Dynamic provisioning ability of these physically diverse devices differs from each other drastically. At the same time, the need for Dynamicly provisioned connections is increasing because optical networks are being deployed in metro areas. As different applications have varied requirements in the provisioning performance of optical networks, it is imperative to define standardized metrics and procedures such that the performance of networks and application needs can be mapped to each other. This document provides a series of performance metrics to evaluate the dynamic LSP provisioning performance in GMPLS networks, specifically the Dynamic LSP setup/release performance. These metrics can depict the features of GMPLS networks in LSP dynamic provisioning. They can also be used in operational networks for carriers to monitor the control plane performance in realtime. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lsp-dppm-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-ccamp-lsp-dppm-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-12-07180506.I-D@ietf.org> --NextPart-- From jwhitlatch@adelphia.net Sun Dec 7 22:13:38 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79A413A6A2D for ; Sun, 7 Dec 2008 22:13:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -24.51 X-Spam-Level: X-Spam-Status: No, score=-24.51 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CszTwKaDw9Nh for ; Sun, 7 Dec 2008 22:13:38 -0800 (PST) Received: from CBL212-235-7-246.bb.netvision.net.il (CBL212-235-7-246.bb.netvision.net.il [212.235.7.246]) by core3.amsl.com (Postfix) with SMTP id 313BE3A68D0 for ; Sun, 7 Dec 2008 22:13:36 -0800 (PST) To: Subject: Delivery Status Notification From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081208061337.313BE3A68D0@core3.amsl.com> Date: Sun, 7 Dec 2008 22:13:36 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From dieter@temfilter.com Mon Dec 8 04:58:38 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B0383A6A83; Mon, 8 Dec 2008 04:58:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.745 X-Spam-Level: X-Spam-Status: No, score=0.745 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SBL=20, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V4pIrGjz5K3w; Mon, 8 Dec 2008 04:58:38 -0800 (PST) Received: from ppp-58-8-245-144.revip2.asianet.co.th (ppp-58-8-245-144.revip2.asianet.co.th [58.8.245.144]) by core3.amsl.com (Postfix) with SMTP id 5C3A63A6784; Mon, 8 Dec 2008 04:57:42 -0800 (PST) Message-ID: Date: Mon, 08 Dec 2008 07:57:33 -0500 From: "Desiree Potts" Subject: Omega better than original To: atompub-archive@megatron.ietf.org Content-Type: text/plain Content-Transfer-Encoding: 7bit Hello Desiree Looking for a Longines watch that no one can tell from the original? You're in luck, because we have the best copies http://www.nazedlav.com/ Take an extra 15% off your purchase during month of December. http://www.nazedlav.com/ Sincerely, Mr Potts From 6x6taxi@interware.hu Mon Dec 8 06:16:58 2008 Return-Path: <6x6taxi@interware.hu> X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 946303A6936; Mon, 8 Dec 2008 06:16:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.611 X-Spam-Level: X-Spam-Status: No, score=-5.611 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_DYNAMIC_HCC=4.295, HELO_EQ_DSL=1.129, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SBL=20, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gQKbc5BiVeSA; Mon, 8 Dec 2008 06:16:57 -0800 (PST) Received: from bl7-95-112.dsl.telepac.pt (bl7-95-112.dsl.telepac.pt [85.240.95.112]) by core3.amsl.com (Postfix) with SMTP id F03373A68F0; Mon, 8 Dec 2008 06:16:36 -0800 (PST) Message-ID: Date: Mon, 08 Dec 2008 09:16:32 -0500 From: "Irene Caudill" Subject: Longines watch for a christmas gift To: architecture-discuss@ietf.org Content-Type: text/plain Content-Transfer-Encoding: 7bit Hello Irene Christmas is the time to get Emporio Armani watch, and the only place to get top notch watches that look and perform exactly like the originals is http://www.nazedlav.com/ With top notch customer service and super warranty, we stand behind our watches. http://www.nazedlav.com/ Sincerely, Mr Caudill From owner-ccamp@ops.ietf.org Mon Dec 8 14:39:54 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5F2328C0FD for ; Mon, 8 Dec 2008 14:39:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kyGaFtBUXzhP for ; Mon, 8 Dec 2008 14:39:54 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7B46728C102 for ; Mon, 8 Dec 2008 14:39:53 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L9ofj-000AyH-Ql for ccamp-data@psg.com; Mon, 08 Dec 2008 22:33:47 +0000 Received: from [206.16.17.70] (helo=usaga02-in.huawei.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L9ofe-000Axw-FW for ccamp@ops.ietf.org; Mon, 08 Dec 2008 22:33:44 +0000 Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KBK001YSXC083@usaga02-in.huawei.com> for ccamp@ops.ietf.org; Mon, 08 Dec 2008 14:33:37 -0800 (PST) Received: from Y73674 ([10.124.12.71]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KBK00KW7XBU4Y@usaga02-in.huawei.com> for ccamp@ops.ietf.org; Mon, 08 Dec 2008 14:33:36 -0800 (PST) Date: Mon, 08 Dec 2008 16:33:29 -0600 From: Lucy Yong Subject: comments on the draft of LSP hierarchy To: shiomoto.kohei@lab.ntt.co.jp, 'Adrian Farrel' , ccamp@ops.ietf.org Message-id: <008301c95984$ff315cb0$fd32fea9@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_G0bW96lybl6woaba+XqNvg)" Thread-index: AclZhP39QzvE+JOGR/WrwFTtiePzmg== Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: This is a multi-part message in MIME format. --Boundary_(ID_G0bW96lybl6woaba+XqNvg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Shiomoto and Adrian, I study through this draft and appreciate that you specify many necessary MLN scenarios that LSP can be used for. Some of them can apply to CTG (composite transport group) scenario. Here are some clarification and questions: 1) When LSP is used for Client/Server Network: the server network sets LSP as private link with one or more client IGP instances; When LSP is used as routing adjacency: the network sets LSP as non-private link with routing adjacency. Is this correct? 2) Should section 2.2 add one more categories: -LSP is used as a component link in a link bundle? The doc. is described it but not considers it as category. 3) A component link in a link bundle has component link identifier. This identifier is the link ID that is advertised in LSA. Is that correct? 4) In section 3.3, it states: If the B-flag in the Actions field of the LSP_TUNNEL_INTERFACE_ID object is set, the other fields of the object apply to the link bundle itself. That is, the interface identifiers (numbered or unnumbered) and the other flags in the Actions field apply to the link bundle and not to the component link that the LSP will form. Furthermore, the IGP Instance Identifier TLV (if present) also applies to the link bundle and not to the component link. It seems odd way to set actions for link bundle. Should we first set the link bundle with the action, then add component link to the link bundle without action? 5) LSA should not advertise LSP used as private link. Should this be explicitly stated in section 3.4? 6) For CTG scenarios, we create a set of LSPs to form a single composite link to client/server network. We can first create a composite link as a private link with one or more client IGP instances with (at least one component link); then individual component link can be added to and removed from the composite link. Component links are also private link (different from component link in link bundle) and have different TE properties. We can also create composite link for routing adjacency (single IGP case). We need some extension to cover these scenarios. Could we consider adding this into the document? Cheers, Lucy --Boundary_(ID_G0bW96lybl6woaba+XqNvg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi Shiomoto and Adrian,

 

I study through this draft and appreciate that you specify many necessary MLN scenarios that LSP can be used for. Some of them can apply to CTG (composite transport group) scenario. Here are some clarification and questions:

1) When LSP is used for Client/Server Network: the server network sets LSP as private link with one or more client IGP instances; When LSP is used as routing adjacency: the network sets LSP as non-private link with routing adjacency. Is this correct?

2) Should section 2.2 add one more categories: -LSP is used as a component link in a link bundle? The doc. is described it but not considers it as category.

3) A component link in a link bundle has component link identifier. This identifier is the link ID that is advertised in LSA. Is that correct?

4) In section 3.3, it states:

 

   If the B-flag in the Actions field of the LSP_TUNNEL_INTERFACE_ID

   object is set, the other fields of the object apply to the link

   bundle itself. That is, the interface identifiers (numbered or

   unnumbered) and the other flags in the Actions field apply to the

   link bundle and not to the component link that the LSP will form.

 

   Furthermore, the IGP Instance Identifier TLV (if present) also

   applies to the link bundle and not to the component link.

 

It seems odd way to set actions for link bundle. Should we first set the link bundle with the action, then add component link to the link bundle without action?

 

5) LSA should not advertise LSP used as private link. Should this be explicitly stated in section 3.4?

 

6) For CTG scenarios, we create a set of LSPs to form a single composite link to client/server network. We can first create a composite link as a private link with one or more client IGP instances with (at least one component link); then individual component link can be added to and removed from the composite link. Component links are also private link (different from component link in link bundle) and have different TE properties. We can also create composite link for routing adjacency (single IGP case). We need some extension to cover these scenarios. Could we consider adding this into the document?

 

Cheers,

Lucy

 

 

 

--Boundary_(ID_G0bW96lybl6woaba+XqNvg)-- From morleykelleher@aiueo-circle.jp Mon Dec 8 15:08:48 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5247328C131 for ; Mon, 8 Dec 2008 15:08:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -41.715 X-Spam-Level: X-Spam-Status: No, score=-41.715 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HOST_EQ_D_D_D_D=0.765, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x8fweY-hpsab for ; Mon, 8 Dec 2008 15:08:48 -0800 (PST) Received: from lgb-static-66.18.142.124.mpowercom.net (lgb-static-66.18.142.124.mpowercom.net [66.18.142.124]) by core3.amsl.com (Postfix) with SMTP id 73B0928C122 for ; Mon, 8 Dec 2008 15:08:46 -0800 (PST) To: Subject: RE: Message From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081208230847.73B0928C122@core3.amsl.com> Date: Mon, 8 Dec 2008 15:08:46 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From daniela.zenger@apraxis.ch Mon Dec 8 15:55:22 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63FBC3A6A19; Mon, 8 Dec 2008 15:55:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.401 X-Spam-Level: X-Spam-Status: No, score=0.401 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_HCC=4.295, HELO_EQ_CPE=0.5, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_CPE=0.979, HOST_EQ_MODEMCABLE=1.368, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SBL=20, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jsvRWjGnw578; Mon, 8 Dec 2008 15:55:21 -0800 (PST) Received: from cpe-000c6e430393.cpe.cableonda.net (cpe-000c6e430393.cpe.cableonda.net [190.140.255.85]) by core3.amsl.com (Postfix) with SMTP id E0A9E3A686D; Mon, 8 Dec 2008 15:54:31 -0800 (PST) Message-ID: Date: Mon, 08 Dec 2008 18:54:25 -0500 From: "Consuelo Farrell" Subject: Take a look at the Gucci watches To: architecture-discuss@ietf.org Content-Type: text/plain Content-Transfer-Encoding: 7bit Hello Consuelo Looking for a Franck Muller watch that no one can tell from the original? You're in luck, because we have the best copies http://www.yifurwuy.com/ With top notch customer service and super warranty, we stand behind our watches. http://www.yifurwuy.com/ Sincerely, Mr Farrell From soeken@bbe-verlag.de Tue Dec 9 01:17:06 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F37D3A63D3; Tue, 9 Dec 2008 01:17:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.977 X-Spam-Level: X-Spam-Status: No, score=-6.977 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SBL=20, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id co-1VbQm79dr; Tue, 9 Dec 2008 01:17:06 -0800 (PST) Received: from chello087206051235.chello.pl (chello087206051235.chello.pl [87.206.51.235]) by core3.amsl.com (Postfix) with SMTP id EECF63A6A7C; Tue, 9 Dec 2008 01:16:05 -0800 (PST) Message-ID: Date: Tue, 09 Dec 2008 04:15:26 -0500 From: "Teresa Felix" Subject: Longines better than original To: architecture-discuss@ietf.org Content-Type: text/plain Content-Transfer-Encoding: 7bit Hello Teresa Looking for a Tag Heuer watch that no one can tell from the original? You're in luck, because we have the best copies http://www.yifurwuy.com/ Get two deeply discounted watches and take an extra 15% discount. http://www.yifurwuy.com/ Sincerely, Mr Felix From owner-ccamp@ops.ietf.org Tue Dec 9 02:58:50 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BADB3A6AFD for ; Tue, 9 Dec 2008 02:58:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.416 X-Spam-Level: X-Spam-Status: No, score=-104.416 tagged_above=-999 required=5 tests=[AWL=2.182, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, STOX_REPLY_TYPE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qRilHR3GvzVq for ; Tue, 9 Dec 2008 02:58:49 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 7EA3E3A6802 for ; Tue, 9 Dec 2008 02:58:49 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LA0BA-0007rq-I1 for ccamp-data0@psg.com; Tue, 09 Dec 2008 10:51:00 +0000 Received: from [156.106.192.41] (helo=protext01.itu.ch) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LA0B5-0007rB-Pw for ccamp@ops.ietf.org; Tue, 09 Dec 2008 10:50:58 +0000 Received: from protext01.itu.ch ([156.106.192.41]) by protext01.itu.ch with Microsoft SMTPSVC(5.0.2195.6713); Tue, 9 Dec 2008 11:50:52 +0100 Received: From mail6.itu.ch ([156.106.192.22]) by protext01.itu.ch (WebShield SMTP v4.5 MR3) id 1228819851507; Tue, 9 Dec 2008 11:50:51 +0100 Received: from your029b8cecfe ([156.106.219.179]) by mail6.itu.ch (8.14.3/8.14.3) with ESMTP id mB9Aom0x512555; Tue, 9 Dec 2008 11:50:49 +0100 (MET) Message-ID: <6FD613982F844ABDAE7193395355FB3A@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Lucy Yong" , , References: <008301c95984$ff315cb0$fd32fea9@china.huawei.com> Subject: Re: comments on the draft of LSP hierarchy Date: Tue, 9 Dec 2008 10:50:37 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (mail6.itu.ch [156.106.192.22]); Tue, 09 Dec 2008 11:50:51 +0100 (MET) X-OriginalArrivalTime: 09 Dec 2008 10:50:52.0710 (UTC) FILETIME=[0161A460:01C959EC] Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Hi Lucy, > I study through this draft and appreciate that you specify many necessary > MLN scenarios that LSP can be used for. Some of them can apply to CTG > (composite transport group) scenario. Here are some clarification and > questions: > > 1) When LSP is used for Client/Server Network: the server network sets LSP > as private link with one or more client IGP instances; When LSP is used as > routing adjacency: the network sets LSP as non-private link with routing > adjacency. Is this correct? I think that if the link is private, there is no need and possibly no meaning to set a client IGP instance. Setting an IGP instance implies that the link is to be advertised in some IGP instance, and a private link will not be advertised. > 2) Should section 2.2 add one more categories: -LSP is used as a component > link in a link bundle? The doc. is described it but not considers it as > category. Good catch. The overview text was not updated to reflect updates to the main body. I will update. > 3) A component link in a link bundle has component link identifier. This > identifier is the link ID that is advertised in LSA. Is that correct? Section 2.4 says... When an LSP is to be used as a component link of a link bundle, the LSP_TUNNEL_INTERFACE_ID object refers to the bundle indicating how the bundle is addressed and used, and a new TLV indicates the component link identifier for the link that the LSP creates. Only the component link identifier is advertised by the IGP. The component link identifier is used locally (between link end points), but may also be present in an ERO and RRO in signaling with the assumption that this inormaiton is coordinated by some other means. > 4) In section 3.3, it states: > > If the B-flag in the Actions field of the LSP_TUNNEL_INTERFACE_ID > object is set, the other fields of the object apply to the link > bundle itself. That is, the interface identifiers (numbered or > unnumbered) and the other flags in the Actions field apply to the > link bundle and not to the component link that the LSP will form. > > Furthermore, the IGP Instance Identifier TLV (if present) also > applies to the link bundle and not to the component link. > > It seems odd way to set actions for link bundle. Should we first set the > link bundle with the action, then add component link to the link bundle > without action? The issue is that the link bundle itself is not signaled. Only the component links correspond to LSPs that are signaled. Thus, when the first component link is signaled, there is no link bundle in existence. > 5) LSA should not advertise LSP used as private link. Should this be > explicitly stated in section 3.4? OK. I'll add this to the definition of a private link in section 1.1.3. > 6) For CTG scenarios, we create a set of LSPs to form a single composite > link to client/server network. We can first create a composite link as a > private link with one or more client IGP instances with (at least one > component link); then individual component link can be added to and > removed > from the composite link. Component links are also private link (different > from component link in link bundle) and have different TE properties. We > can > also create composite link for routing adjacency (single IGP case). We > need > some extension to cover these scenarios. Could we consider adding this > into > the document? I believe that the mechanisms in the hierarchy bis draft will be applicable to the creation of LSPs that are used as components of CTGs. In my view (as an author) it would be premature to add this to the draft at this stage as it would create a normative reference to the CTG work which has not yet been adopted by any working group and is bound to take some time to complete. My preferred approach is that the hierarchy bis draft creates the framework and a registry of actions carried in the flags field (see section 5.2). Any new work, such as your CTG work, can then request the allocation of a further bit and can define the behavior if the bit is set. Cheers, Adrian From owner-ccamp@ops.ietf.org Tue Dec 9 02:58:51 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30D6B3A6802 for ; Tue, 9 Dec 2008 02:58:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.698 X-Spam-Level: X-Spam-Status: No, score=-0.698 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C59wO0e2xBVw for ; Tue, 9 Dec 2008 02:58:50 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3F4F53A6AEE for ; Tue, 9 Dec 2008 02:58:50 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LA0E3-00084I-7r for ccamp-data0@psg.com; Tue, 09 Dec 2008 10:53:59 +0000 Received: from [80.86.78.228] (helo=fw.testbed.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LA0Dy-00083P-SC for ccamp@ops.ietf.org; Tue, 09 Dec 2008 10:53:57 +0000 Received: from [156.106.219.102] (port=1378) by fw.testbed.se with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1LA0Dm-0001Y9-1k; Tue, 09 Dec 2008 11:53:42 +0100 Message-ID: <493E4E2E.2050600@pi.nu> Date: Tue, 09 Dec 2008 11:53:34 +0100 From: Loa Andersson User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Adrian Farrel CC: ccamp@ops.ietf.org Subject: Re: CCAMP drafts for adoption References: <2089B64D43144AEEA390F5C4C7232087@your029b8cecfe> In-Reply-To: <2089B64D43144AEEA390F5C4C7232087@your029b8cecfe> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: support for all /Loa Adrian Farrel wrote: > Hi, > > Can you please express your opinion on the adoption of the following > three drafts as WG drafts. > > Thanks, > Adrian > > draft-takacs-ccamp-oam-configuration-fwk-01.txt > draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt > draft-bernstein-ccamp-wson-encode-01.txt (to become -rwa-encode-00) > > Cheers, > Adrian and Deborah > > -- Loa Andersson email: loa.andersson@redback.com Sr Strategy and Standards Manager loa@pi.nu Redback Networks phone: +46 8 632 77 14 An Ericsson Company From owner-ccamp@ops.ietf.org Tue Dec 9 03:01:29 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB0C83A6AFD for ; Tue, 9 Dec 2008 03:01:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.781 X-Spam-Level: X-Spam-Status: No, score=0.781 tagged_above=-999 required=5 tests=[AWL=-3.222, BAYES_50=0.001, FH_RELAY_NODNS=1.451, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bQRAhIJy4Qfv for ; Tue, 9 Dec 2008 03:01:29 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CF6B83A69AB for ; Tue, 9 Dec 2008 03:01:27 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LA0Gc-0008FY-G8 for ccamp-data0@psg.com; Tue, 09 Dec 2008 10:56:38 +0000 Received: from [156.106.192.41] (helo=protext01.itu.ch) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LA0GX-0008Ez-I7 for ccamp@ops.ietf.org; Tue, 09 Dec 2008 10:56:36 +0000 Received: from protext01.itu.ch ([156.106.192.41]) by protext01.itu.ch with Microsoft SMTPSVC(5.0.2195.6713); Tue, 9 Dec 2008 11:56:32 +0100 Received: From mail6.itu.ch ([156.106.192.22]) by protext01.itu.ch (WebShield SMTP v4.5 MR3) id 1228820191742; Tue, 9 Dec 2008 11:56:31 +0100 Received: from your029b8cecfe ([156.106.219.179]) by mail6.itu.ch (8.14.3/8.14.3) with ESMTP id mB9AuRBA512880 for ; Tue, 9 Dec 2008 11:56:30 +0100 (MET) Message-ID: <4CE0322579F54648BAAC52322768DCC3@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Fw: new version of LSP DPPM draft Date: Tue, 9 Dec 2008 10:56:23 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="gb2312"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (mail6.itu.ch [156.106.192.22]); Tue, 09 Dec 2008 11:56:31 +0100 (MET) X-OriginalArrivalTime: 09 Dec 2008 10:56:32.0492 (UTC) FILETIME=[CBE842C0:01C959EC] Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Forwarded on behalf of Guoying Zhang: ----- Original Message ----- From: "gyzhang" Sent: Tuesday, December 09, 2008 2:14 AM Subject: new version of LSP DPPM draft Hi all, A new version of DPPM draft (LSP Dynamic Provisioning Performance Metrics in GMPLS Networks) has just been posted on the IETF website. This draft was discussed in the Dublin meeting. The authors have now updated the draft according to the discussions during and after the meeting. The following are the summary of discussion and modifications made to the draft. 1. During and after the meeting, some discussion was made about the data plane and control plane synchronization. Thanks to Adrian, some rules clarifying their relations were identified in existing documents. (1) Three documents stated the rules in the forward direction RFC 3471 section 3.4: an ingress node should not transmit data traffic on a suggested label until the downstream node passes a label upstream. The implication here is that an ingress node may (safely) start to transmit data when it receives a label in a Resv message. This also shows in RFC 3473 section 2.5: An ingress node SHOULD NOT transmit data traffic using a suggested label until the downstream node passes a corresponding label upstream. Also in RFC3209 section 4.1.1.1: The node then sends the new LABEL object as part of the Resv message to the previous hop. The node SHOULD be prepared to forward packets carrying the assigned label prior to sending the Resv message. "before" is very telling. It means that the XC must be in place to forward traffic before Resv is sent. (2) For the reverse direction We have RFC 3473 section 3.1: The Upstream_Label object MUST indicate a label that is valid for forwarding at the time the Path message is sent. "valid for forwarding" should be taken to mean that it is OK to receive data and it will be forwarded. But it can also be taken to mean "acceptable for use" i.e. available to be cross-connected. This is clarified later in RFC 3473 section 3.1: Terminator nodes process Path messages as usual, with the exception that the upstream label can immediately be used to transport data traffic associated with the LSP upstream towards the initiator. This is pretty clear. When a Path message has been fully processed by an egress node, it is completely safe to transmit data toward the ingress (i.e. reverse path data). (3) To clarify this assumption (that the these rules are followed) we include the following text into the discussion section (section 15) This document assumes that the correct procedures for installing the data plane are followed as described in [RFC3209], [RFC3471], and [RFC3473]. That is, that by the time the egress receives and processes a Path message, it is safe for the egress to transmit data on the reverse path, and that by the time the ingress receives and processes a Resv message it is safe for the ingress to transmit data on the forward path. This document does not include any verification that the implementations of the control plane software are conformant, although such tests could be constructed with the use of suitable signal generation test equipment. 2. During the Dublin meeting, the authors raised the open issue of using two way signaling or three way signaling. After some discussions within the editor team, an agreement has been reached and the following text was added to the discussion section (section 15) o Bidirectional LSPs may be setup using three way signaling, where the initiate node will send a RESV_CONF message downstream upon receiving the RESV message. The RESV_CONF message is used to notify the terminate node that it can transfer data upstream. Actually, both directions should be ready to transfer data when the RESV message is received by the initiate node. Therefore, the bidirectional LSP setup delay defined in this document, does not take the confirmation procedure into account. We thank to Lou, Igor and Adrian for their valuable comments and discussions during and after the meeting. The authors would like to have more experts from the WG to review this draft. And we hope to request a WG last call soon. best regards, ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡Guoying Zhang ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡gyzhang@sina.com ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡2008-12-08 From owner-ccamp@ops.ietf.org Tue Dec 9 03:04:12 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 360B63A6802 for ; Tue, 9 Dec 2008 03:04:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.081 X-Spam-Level: X-Spam-Status: No, score=-102.081 tagged_above=-999 required=5 tests=[AWL=0.519, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uxe9+EsHj5+A for ; Tue, 9 Dec 2008 03:04:11 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 49E213A6986 for ; Tue, 9 Dec 2008 03:04:11 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LA0Ju-0008W6-MG for ccamp-data0@psg.com; Tue, 09 Dec 2008 11:00:02 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LA0Jp-0008V8-0b for ccamp@ops.ietf.org; Tue, 09 Dec 2008 10:59:59 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id 3B65E3A6AFD; Tue, 9 Dec 2008 03:00:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org Subject: I-D Action:draft-ietf-ccamp-lsp-hierarchy-bis-06.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081209110001.3B65E3A6AFD@core3.amsl.com> Date: Tue, 9 Dec 2008 03:00:01 -0800 (PST) Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: --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 : Procedures for Dynamically Signaled Hierarchical Label Switched Paths Author(s) : K. Shiomoto, et al. Filename : draft-ietf-ccamp-lsp-hierarchy-bis-06.txt Pages : 28 Date : 2008-12-09 Label Switched Paths (LSPs) set up in Multiprotocol Label Switching (MPLS) or Generalized MPLS (GMPLS) networks can be used to form links for carrying traffic in those networks or in other (client) networks. Protocol extensions already exist to facilitate the establishment of an LSP as a numbered traffic engineering (TE) link within the same instance of the routing as is used to advertise the links that it traverses creating a Forwarding Adjacency (FA). This document extends those mechanisms to support unnumbered FAs. This document also defines how to indicate that an LSP should be advertised as a link in another instance of the routing protocol (for instance in a client network) and which instance to use. Furthermore, mechanisms are defined to indicate when an LSP is to be used as a component link of a TE link bundle and to identify the bundle.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 [RFC2119]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lsp-hierarchy-bis-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-ccamp-lsp-hierarchy-bis-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-12-09025228.I-D@ietf.org> --NextPart-- From owner-ccamp@ops.ietf.org Tue Dec 9 08:37:59 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1534E28C0F5 for ; Tue, 9 Dec 2008 08:37:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gUgkWqW17X-j for ; Tue, 9 Dec 2008 08:37:58 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9CA9228C14C for ; Tue, 9 Dec 2008 08:37:51 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LA5UQ-0005wy-0Y for ccamp-data0@psg.com; Tue, 09 Dec 2008 16:31:14 +0000 Received: from [206.16.17.180] (helo=usaga04-in.huawei.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LA5UK-0005vi-Uu for ccamp@ops.ietf.org; Tue, 09 Dec 2008 16:31:11 +0000 Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KBM00IMSB7VSI@usaga04-in.huawei.com> for ccamp@ops.ietf.org; Tue, 09 Dec 2008 10:31:08 -0600 (CST) Received: from Y73674 ([10.124.12.71]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KBM00LOFB7QK4@usaga04-in.huawei.com> for ccamp@ops.ietf.org; Tue, 09 Dec 2008 10:31:07 -0600 (CST) Date: Tue, 09 Dec 2008 10:31:02 -0600 From: Lucy Yong Subject: RE: comments on the draft of LSP hierarchy In-reply-to: <6FD613982F844ABDAE7193395355FB3A@your029b8cecfe> To: 'Adrian Farrel' , shiomoto.kohei@lab.ntt.co.jp, ccamp@ops.ietf.org Message-id: <007c01c95a1b$87805080$470c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Thread-index: AclZ7Gp1u2Dz7I/lQSG3Zmi7gPu1BgAJgKew References: <008301c95984$ff315cb0$fd32fea9@china.huawei.com> <6FD613982F844ABDAE7193395355FB3A@your029b8cecfe> Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Hi Adrian, Thank very much for the explanation. See below. Regards, Lucy > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: Tuesday, December 09, 2008 4:51 AM > To: Lucy Yong; shiomoto.kohei@lab.ntt.co.jp; ccamp@ops.ietf.org > Subject: Re: comments on the draft of LSP hierarchy > > Hi Lucy, > > > I study through this draft and appreciate that you specify many necessary > > MLN scenarios that LSP can be used for. Some of them can apply to CTG > > (composite transport group) scenario. Here are some clarification and > > questions: > > > > 1) When LSP is used for Client/Server Network: the server network sets LSP > > as private link with one or more client IGP instances; When LSP is used as > > routing adjacency: the network sets LSP as non-private link with routing > > adjacency. Is this correct? > > I think that if the link is private, there is no need and possibly no > meaning to set a client IGP instance. Setting an IGP instance implies that > the link is to be advertised in some IGP instance, and a private link will > not be advertised. > [Lucy:] I though that signaling is within an IGP (say IGP A). So if signaling a LSP for client/server network (say IGP B), RSVP needs set action as private link (not adv in IGP A), FA, and lists other IGP instances (IGP B). It seems my understanding is not correct. Are you saying that RSVP signaling is not tight to an IGP instance? Without using private link indication, how does the LSA of IGP A know if it should advertise in IGP A or not? > > 2) Should section 2.2 add one more categories: -LSP is used as a component > > link in a link bundle? The doc. is described it but not considers it as > > category. > > Good catch. > The overview text was not updated to reflect updates to the main body. > I will update. > > > 3) A component link in a link bundle has component link identifier. This > > identifier is the link ID that is advertised in LSA. Is that correct? > > Section 2.4 says... > > When an LSP is to be used as a component link of a link bundle, the > LSP_TUNNEL_INTERFACE_ID object refers to the bundle indicating how > the bundle is addressed and used, and a new TLV indicates the > component link identifier for the link that the LSP creates. > > Only the component link identifier is advertised by the IGP. The component > link identifier is used locally (between link end points), but may also be > present in an ERO and RRO in signaling with the assumption that this > inormaiton is coordinated by some other means. [Lucy:] If component link identifier is used locally, why does it be advertised in the IGP? > > > 4) In section 3.3, it states: > > > > If the B-flag in the Actions field of the LSP_TUNNEL_INTERFACE_ID > > object is set, the other fields of the object apply to the link > > bundle itself. That is, the interface identifiers (numbered or > > unnumbered) and the other flags in the Actions field apply to the > > link bundle and not to the component link that the LSP will form. > > > > Furthermore, the IGP Instance Identifier TLV (if present) also > > applies to the link bundle and not to the component link. > > > > It seems odd way to set actions for link bundle. Should we first set the > > link bundle with the action, then add component link to the link bundle > > without action? > > The issue is that the link bundle itself is not signaled. Only the component > links correspond to LSPs that are signaled. Thus, when the first component > link is signaled, there is no link bundle in existence. [Lucy:] Yes, it is the issue. Would it be nice to have a way to signal a link bundle first? It can apply to composite link as well. If we stay as it is, when adding the second component link to a link bundle, RSVP has to make sure all the actions have to be the exact same, is that right? Or we only require the first signaled component link to indicate a link bundle properties. If we want to add a component link in a link bundle to an IGP instance, we will use LSP_TUNNEL_INTERFACE_ID with IGP TLV and component link TLV, how to distinguish two type of TLV within an LSP_TUNNEL_INTERFACE_ID object? > > > 5) LSA should not advertise LSP used as private link. Should this be > > explicitly stated in section 3.4? > > OK. > I'll add this to the definition of a private link in section 1.1.3. > > > 6) For CTG scenarios, we create a set of LSPs to form a single composite > > link to client/server network. We can first create a composite link as a > > private link with one or more client IGP instances with (at least one > > component link); then individual component link can be added to and > > removed > > from the composite link. Component links are also private link (different > > from component link in link bundle) and have different TE properties. We > > can > > also create composite link for routing adjacency (single IGP case). We > > need > > some extension to cover these scenarios. Could we consider adding this > > into > > the document? > > I believe that the mechanisms in the hierarchy bis draft will be applicable > to the creation of LSPs that are used as components of CTGs. In my view (as > an author) it would be premature to add this to the draft at this stage as > it would create a normative reference to the CTG work which has not yet been > adopted by any working group and is bound to take some time to complete. [Lucy:] Operator want to implement CTG soon and hope the framework and requirement draft can be completed soon. Although CTG can be manually configured at beginning, it would be nice to have an GMPLS way to configure it as well. > > My preferred approach is that the hierarchy bis draft creates the framework > and a registry of actions carried in the flags field (see section 5.2). Any > new work, such as your CTG work, can then request the allocation of a > further bit and can define the behavior if the bit is set. [Lucy:] Thank you for the suggestion. > > Cheers, > Adrian > From owner-ccamp@ops.ietf.org Tue Dec 9 09:35:15 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30D5C3A6B37 for ; Tue, 9 Dec 2008 09:35:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.617 X-Spam-Level: X-Spam-Status: No, score=-1.617 tagged_above=-999 required=5 tests=[AWL=-0.570, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HFy6UxHK3pkc for ; Tue, 9 Dec 2008 09:35:14 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BE0D43A6B36 for ; Tue, 9 Dec 2008 09:35:13 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LA6N8-000AIA-Dl for ccamp-data0@psg.com; Tue, 09 Dec 2008 17:27:46 +0000 Received: from [156.106.192.41] (helo=protext01.itu.ch) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LA6N3-000AHn-3v for ccamp@ops.ietf.org; Tue, 09 Dec 2008 17:27:43 +0000 Received: from protext01.itu.ch ([156.106.192.41]) by protext01.itu.ch with Microsoft SMTPSVC(5.0.2195.6713); Tue, 9 Dec 2008 18:27:37 +0100 Received: From mail6.itu.ch ([156.106.192.22]) by protext01.itu.ch (WebShield SMTP v4.5 MR3) id 1228843657218; Tue, 9 Dec 2008 18:27:37 +0100 Received: from your029b8cecfe ([156.106.219.179]) by mail6.itu.ch (8.14.3/8.14.3) with ESMTP id mB9HROsC520926; Tue, 9 Dec 2008 18:27:26 +0100 (MET) Message-ID: Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Lucy Yong" , , References: <008301c95984$ff315cb0$fd32fea9@china.huawei.com> <6FD613982F844ABDAE7193395355FB3A@your029b8cecfe> <007c01c95a1b$87805080$470c7c0a@china.huawei.com> Subject: Re: comments on the draft of LSP hierarchy Date: Tue, 9 Dec 2008 17:27:19 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (mail6.itu.ch [156.106.192.22]); Tue, 09 Dec 2008 18:27:37 +0100 (MET) X-OriginalArrivalTime: 09 Dec 2008 17:27:37.0765 (UTC) FILETIME=[6E4CC550:01C95A23] Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Hi Lucy, >> > 1) When LSP is used for Client/Server Network: the server network sets >> > LSP as private link with one or more client IGP instances; When LSP >> > is used as routing adjacency: the network sets LSP as non-private link >> > with routing adjacency. Is this correct? >> >> I think that if the link is private, there is no need and possibly no >> meaning to set a client IGP instance. Setting an IGP instance implies >> that >> the link is to be advertised in some IGP instance, and a private link >> will >> not be advertised. > > [Lucy:] I though that signaling is within an IGP (say IGP A). So if > signaling a LSP for client/server network (say IGP B), RSVP needs set > action > as private link (not adv in IGP A), FA, and lists other IGP instances (IGP > B). It seems my understanding is not correct. > Are you saying that RSVP signaling is not tight to an IGP instance? > Without > using private link indication, how does the LSA of IGP A know if it should > advertise in IGP A or not? I am a bit confused by your question. When an LSP is signaled in RSVP-TE it can be used to create a link in one or more other networks. If the link is to be advertised in the same instance of the IGP that was used to advertise the links that were used by RSVP-TE when it signaled the LSP, then this is a Forwarding Adjacency as already described. If the link is to be advertised in a separate instance of an IGP (perhaps an IGP that advertises links in another network layer) then the IGP instance is indicated in the signaling message used to set up the LSP as described in this draft. If the link is not to be advertised (i.e. is a private link) then you do not include the IGP instance because it is not needed. >> > 3) A component link in a link bundle has component link identifier. >> > This >> > identifier is the link ID that is advertised in LSA. Is that correct? >> >> Section 2.4 says... >> >> When an LSP is to be used as a component link of a link bundle, the >> LSP_TUNNEL_INTERFACE_ID object refers to the bundle indicating how >> the bundle is addressed and used, and a new TLV indicates the >> component link identifier for the link that the LSP creates. >> >> Only the component link identifier is advertised by the IGP. The >> component >> link identifier is used locally (between link end points), but may also >> be >> present in an ERO and RRO in signaling with the assumption that this >> inormaiton is coordinated by some other means. > > [Lucy:] If component link identifier is used locally, why does it be > advertised in the IGP? I'm sorry, I mistyped (that will teach me to try to write emails to you while concentrating on ITU-T politics ;-) I should have written... Only the *bundle* link identifier is advertised by the IGP. The component link identifier is used locally (between link end points), but may also be present in an ERO and RRO in signaling with the assumption that this information is coordinated by some other means. >> > 4) In section 3.3, it states: >> > >> > If the B-flag in the Actions field of the LSP_TUNNEL_INTERFACE_ID >> > object is set, the other fields of the object apply to the link >> > bundle itself. That is, the interface identifiers (numbered or >> > unnumbered) and the other flags in the Actions field apply to the >> > link bundle and not to the component link that the LSP will form. >> > >> > Furthermore, the IGP Instance Identifier TLV (if present) also >> > applies to the link bundle and not to the component link. >> > >> > It seems odd way to set actions for link bundle. Should we first set >> > the >> > link bundle with the action, then add component link to the link bundle >> > without action? >> >> The issue is that the link bundle itself is not signaled. Only the >> component links correspond to LSPs that are signaled. Thus, >> when the first component link is signaled, there is no link bundle >> in existence. > > [Lucy:] Yes, it is the issue. Would it be nice to have a way to signal a > link bundle first? It can apply to composite link as well. You could come up with a way to do that. You should not use LSP signaling to do this - the bundle or composite link should not be known at transit points of the LSP. You might want to use a GMPLS call to achieve this function if (and only if?) the bundle/composite link needs to be communicated in advance. > If we stay as it is, when adding the second component link to a link > bundle, > RSVP has to make sure all the actions have to be the exact same, is that > right? Or we only require the first signaled component link to indicate a > link bundle properties. I think that might depend on application. > If we want to add a component link in a link bundle to an IGP instance, we > will use LSP_TUNNEL_INTERFACE_ID with IGP TLV and component link TLV, how > to > distinguish two type of TLV within an LSP_TUNNEL_INTERFACE_ID object? They have different TLV type values. >> > 6) For CTG scenarios, we create a set of LSPs to form a single >> > composite >> > link to client/server network. We can first create a composite link as >> > a >> > private link with one or more client IGP instances with (at least one >> > component link); then individual component link can be added to and >> > removed from the composite link. Component links are also private link >> > (different from component link in link bundle) and have different TE >> > properties. We can also create composite link for routing adjacency >> > (single IGP case). We need some extension to cover these scenarios. >> > Could we consider adding this into the document? >> >> I believe that the mechanisms in the hierarchy bis draft will be >> applicable to the creation of LSPs that are used as components of >> CTGs. In my view (as an author) it would be premature to add this >> to the draft at this stage as it would create a normative reference to >> the CTG work which has not yet been adopted by any working group >> and is bound to take some time to complete. > > [Lucy:] Operator want to implement CTG soon and hope the framework and > requirement draft can be completed soon. Although CTG can be manually > configured at beginning, it would be nice to have an GMPLS way to > configure > it as well. Yes. I agree. Hence my proposal below. >> My preferred approach is that the hierarchy bis draft creates the >> framework and a registry of actions carried in the flags field (see >> section 5.2). >> Any new work, such as your CTG work, can then request the >> allocation of a further bit and can define the behavior if the bit >> is set. > > [Lucy:] Thank you for the suggestion. Regards, Adrian From oern@aagaard.net Tue Dec 9 14:14:22 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B02728C1A6 for ; Tue, 9 Dec 2008 14:14:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.2 X-Spam-Level: X-Spam-Status: No, score=-2.2 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_VERIZON_P=2.144, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DSL=1.129, HELO_EQ_VERIZON_POOL=1.495, HTML_FONT_LOW_CONTRAST=0.124, HTML_IMAGE_ONLY_08=1.787, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, URIBL_SC_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gcP0rCq2V9Ej for ; Tue, 9 Dec 2008 14:14:21 -0800 (PST) Received: from pool-71-119-80-73.lsanca.dsl-w.verizon.net (pool-71-119-80-73.lsanca.dsl-w.verizon.net [71.119.80.73]) by core3.amsl.com (Postfix) with SMTP id CC04B28C1A5 for ; Tue, 9 Dec 2008 14:14:09 -0800 (PST) To: Subject: Delivery Status Notification From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081209221412.CC04B28C1A5@core3.amsl.com> Date: Tue, 9 Dec 2008 14:14:09 -0800 (PST)
Click Here!

Hurry up, the stock is limited!



future.York Times: They [the Reichmanns] were the most successful real
with George. Then the market would deduce that you are buying forhowever, by limiting the number of investors to under 100 and by From owner-ccamp@ops.ietf.org Tue Dec 9 15:47:34 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11ED63A687E for ; Tue, 9 Dec 2008 15:47:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SX0kcku0Y2Pt for ; Tue, 9 Dec 2008 15:47:33 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 260F13A67F4 for ; Tue, 9 Dec 2008 15:47:33 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LACDD-0007E1-HR for ccamp-data0@psg.com; Tue, 09 Dec 2008 23:41:55 +0000 Received: from [206.16.17.70] (helo=usaga02-in.huawei.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LACD7-0007Db-L9 for ccamp@ops.ietf.org; Tue, 09 Dec 2008 23:41:52 +0000 Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KBM000DKV5O2N@usaga02-in.huawei.com> for ccamp@ops.ietf.org; Tue, 09 Dec 2008 15:41:48 -0800 (PST) Received: from Y73674 ([10.124.12.71]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KBM0034EV58MG@usaga02-in.huawei.com> for ccamp@ops.ietf.org; Tue, 09 Dec 2008 15:41:48 -0800 (PST) Date: Tue, 09 Dec 2008 17:41:32 -0600 From: Lucy Yong Subject: RE: comments on the draft of LSP hierarchy In-reply-to: To: 'Adrian Farrel' , shiomoto.kohei@lab.ntt.co.jp, ccamp@ops.ietf.org Message-id: <00b001c95a57$b04d4b80$470c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Thread-index: AclaI4NNnWYmsreJQ6Wr85050l8E1gAJ4VBg References: <008301c95984$ff315cb0$fd32fea9@china.huawei.com> <6FD613982F844ABDAE7193395355FB3A@your029b8cecfe> <007c01c95a1b$87805080$470c7c0a@china.huawei.com> Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Hello Adrian, Thank again. See below. Regards, Lucy [Snipped] > > I am a bit confused by your question. > > When an LSP is signaled in RSVP-TE it can be used to create a link in one or > more other networks. [Lucy:] yes. > > If the link is to be advertised in the same instance of the IGP that was > used to advertise the links that were used by RSVP-TE when it signaled the > LSP, then this is a Forwarding Adjacency as already described. [Lucy:] I would like to better understand client/server network case (1.1.6). As described, the server network LSP does not form FA because client and server network run separate instances of the control plane routing protocols. Now, I guess "instances of the control plane routing protocols" are different from IGP instances. (I thought they mean the same before). Could you give an example to use LSP_TUNNEL_INTERFACE_ID object for a LSP that is created in one network and used in another network as a virtual link? > > [Snipped] > > I'm sorry, I mistyped (that will teach me to try to write emails to you > while concentrating on ITU-T politics ;-) > > I should have written... > > Only the *bundle* link identifier is advertised by the IGP. The component > link identifier is used locally (between link end points), but may also be > present in an ERO and RRO in signaling with the assumption that this > information is coordinated by some other means. [Lucy:] Make sense. So without this extension, operator has to configure component link identifier at link end points. So a component link in a link bundle is never advertised. > [snipped] > > > > [Lucy:] Yes, it is the issue. Would it be nice to have a way to signal a > > link bundle first? It can apply to composite link as well. > > You could come up with a way to do that. You should not use LSP signaling to > do this - the bundle or composite link should not be known at transit points > of the LSP. You might want to use a GMPLS call to achieve this function if > (and only if?) the bundle/composite link needs to be communicated in > advance. [Lucy:] All the actions are indications for LSP egress point not transit points, right? > > > If we stay as it is, when adding the second component link to a link > > bundle, > > RSVP has to make sure all the actions have to be the exact same, is that > > right? Or we only require the first signaled component link to indicate a > > link bundle properties. > > I think that might depend on application. > > > If we want to add a component link in a link bundle to an IGP instance, we > > will use LSP_TUNNEL_INTERFACE_ID with IGP TLV and component link TLV, > how > > to > > distinguish two type of TLV within an LSP_TUNNEL_INTERFACE_ID object? > > They have different TLV type values. [Lucy:] where are they specified? > From owner-ccamp@ops.ietf.org Wed Dec 10 06:29:09 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97C793A6BB0 for ; Wed, 10 Dec 2008 06:29:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.68 X-Spam-Level: X-Spam-Status: No, score=-3.68 tagged_above=-999 required=5 tests=[AWL=1.368, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_I_INVITATION=-2, GB_I_LETTER=-2, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id twMrkcy8l2e4 for ; Wed, 10 Dec 2008 06:29:08 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B14233A68EC for ; Wed, 10 Dec 2008 06:29:08 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LAPy4-000E3r-DL for ccamp-data0@psg.com; Wed, 10 Dec 2008 14:23:12 +0000 Received: from [156.106.192.41] (helo=protext01.itu.ch) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LAPxz-000E3O-Eu for ccamp@ops.ietf.org; Wed, 10 Dec 2008 14:23:09 +0000 Received: from protext01.itu.ch ([156.106.192.41]) by protext01.itu.ch with Microsoft SMTPSVC(5.0.2195.6713); Wed, 10 Dec 2008 15:23:03 +0100 Received: From mail6.itu.ch ([156.106.192.22]) by protext01.itu.ch (WebShield SMTP v4.5 MR3) id 1228918982937; Wed, 10 Dec 2008 15:23:02 +0100 Received: from your029b8cecfe ([156.106.219.34]) by mail6.itu.ch (8.14.3/8.14.3) with ESMTP id mBAEMv6Q014364 for ; Wed, 10 Dec 2008 15:23:02 +0100 (MET) Message-ID: Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Fw: Letters of Invitation to IETF 74 now available to past attendees Date: Wed, 10 Dec 2008 14:22:43 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (mail6.itu.ch [156.106.192.22]); Wed, 10 Dec 2008 15:23:02 +0100 (MET) X-OriginalArrivalTime: 10 Dec 2008 14:23:03.0937 (UTC) FILETIME=[D0327710:01C95AD2] Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: ----- Original Message ----- From: "Alexa Morris" To: ; Sent: Tuesday, December 09, 2008 6:31 PM Subject: Letters of Invitation to IETF 74 now available to past attendees > If you need a letter of invitation (LOI) in order to obtain a visa to > come to IETF 74 in San Francisco -- and if you have attended at least > one IETF meeting in the past -- you can now request a LOI via this > webform: https://www.amsl.com/ietf/ietf74-loi.html. The LOI will be > sent to you via email unless you specifically request a hard copy. You > can also access the webform from the Meetings page of the IETF website. > > As soon as we officially open registration for the meeting, anyone who > registers for IETF 74 (regardless of whether or not they've attended a > past meeting) will be able to request and receive a letter of > invitation to attend. > > Regards, > Alexa > > ----------- > Alexa Morris / Executive Director / IETF > 48377 Fremont Blvd., Suite 117, Fremont, CA 94538 > Phone: +1.510.492.4089 / Fax: +1.510.492.4001 > Email: amorris@amsl.com > > Managed by Association Management Solutions (AMS) > Forum Management, Meeting and Event Planning > www.amsl.com > > From owner-ccamp@ops.ietf.org Wed Dec 10 10:05:55 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D22EE3A68EB for ; Wed, 10 Dec 2008 10:05:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.256 X-Spam-Level: X-Spam-Status: No, score=-102.256 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PCX66N9gd2gR for ; Wed, 10 Dec 2008 10:05:55 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0204C3A677E for ; Wed, 10 Dec 2008 10:05:55 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LATLv-0007Cc-Q5 for ccamp-data0@psg.com; Wed, 10 Dec 2008 18:00:03 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LATLp-0007Bw-Dj for ccamp@ops.ietf.org; Wed, 10 Dec 2008 18:00:00 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id BBFC43A6847; Wed, 10 Dec 2008 10:00:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org Subject: I-D Action:draft-ietf-ccamp-ethernet-gmpls-provider-reqs-01.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081210180001.BBFC43A6847@core3.amsl.com> Date: Wed, 10 Dec 2008 10:00:01 -0800 (PST) Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: --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 : Service Provider Requirements for Ethernet control with GMPLS Author(s) : W. Imajuku, et al. Filename : draft-ietf-ccamp-ethernet-gmpls-provider-reqs-01.txt Pages : 19 Date : 2008-12-10 Generalized Multi-Protocol Label Switching (GMPLS) is applicable to Ethernet switches supporting Provider Backbone Bridge Traffic Engineering (PBB-TE) networks. The GMPLS controlled Ethernet label switch network not only automates creation of Ethernet Label Switched Paths(Eth-LSPs), it also provides sophisticated Eth-LSP recovery Mechanisms such as protection and restoration of an Eth-LSP. This document describes the requirements for the set of solutions of GMPLS controlled Ethernet label switch networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ethernet-gmpls-provider-reqs-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-ccamp-ethernet-gmpls-provider-reqs-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-12-10095041.I-D@ietf.org> --NextPart-- From ortegakathrynkippy@advancedtechnology.ca Wed Dec 10 14:32:46 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74BB23A69E2 for ; Wed, 10 Dec 2008 14:32:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -21.289 X-Spam-Level: X-Spam-Status: No, score=-21.289 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, HTML_FONT_LOW_CONTRAST=0.124, HTML_IMAGE_ONLY_08=1.787, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, SARE_RECV_VIRTUACOMBR=1.193, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RxJmXfpoKbua for ; Wed, 10 Dec 2008 14:32:39 -0800 (PST) Received: from bd214cd3.virtua.com.br (bd214cd3.virtua.com.br [189.33.76.211]) by core3.amsl.com (Postfix) with SMTP id A36AD3A6BE5 for ; Wed, 10 Dec 2008 14:32:38 -0800 (PST) To: Subject: RE: Message From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081210223238.A36AD3A6BE5@core3.amsl.com> Date: Wed, 10 Dec 2008 14:32:38 -0800 (PST)
Visit site now!

Choose among all the models available!



factions (a no mans land with abandoned homes andin mid-July 1974 after right-wing Greek Cypriots (backed
 From owner-ccamp@ops.ietf.org Wed Dec 10 17:43:48 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 298FE3A68F6 for ; Wed, 10 Dec 2008 17:43:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.486 X-Spam-Level: X-Spam-Status: No, score=-102.486 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9opltPGXrP+P for ; Wed, 10 Dec 2008 17:43:47 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 47F713A6831 for ; Wed, 10 Dec 2008 17:43:47 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LAaU4-000ISi-IT for ccamp-data0@psg.com; Thu, 11 Dec 2008 01:36:56 +0000 Received: from [2001:200:601:12:230:48ff:fe22:3a84] (helo=mandala.kddilabs.jp) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LAaTs-000IS9-9z for ccamp@ops.ietf.org; Thu, 11 Dec 2008 01:36:53 +0000 Received: from localhost (localhost [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id 4A6B2EC88D for ; Thu, 11 Dec 2008 10:36:41 +0900 (JST) Received: from platinum.inc.kddilabs.jp (platinum.inc.kddilabs.jp [2001:200:601:1300:172:19:83:254]) by mandala.kddilabs.jp (Postfix) with ESMTP id C47A1EC88A for ; Thu, 11 Dec 2008 10:36:40 +0900 (JST) Received: from [IPv6:::1] (unknown [IPv6:2001:200:601:2450:c4aa:aae6:f551:3bf9]) by platinum.inc.kddilabs.jp (Postfix) with ESMTP id 22ACD578111 for ; Thu, 11 Dec 2008 10:36:36 +0900 (JST) Message-ID: <49406E90.1090105@cn.kddilabs.jp> Date: Thu, 11 Dec 2008 10:36:16 +0900 From: "Ogaki, Kenichi" User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: ccamp@ops.ietf.org Subject: Re: I-D Action:draft-ietf-ccamp-ethernet-gmpls-provider-reqs-01.txt References: <20081210180001.BBFC43A6847@core3.amsl.com> In-Reply-To: <20081210180001.BBFC43A6847@core3.amsl.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Hello All, Please find the new revision (01) of "Service Provider Requirements for Ethernet control with GMPLS". We have added some new sections, (4.1.3. Addressing) 4.2.4. Asymmetric bandwidth 4.2.5. QoS control. and modified some texts in 4.2.3. P2MP and MP2MP requirements 4.4. Protection and Restoration related functionality. We would welcome your feedback and thoughts. Best regards, Yoshiaki & Kenichi Internet-Drafts@ietf.org wrote: > 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 : Service Provider Requirements for Ethernet control with GMPLS > Author(s) : W. Imajuku, et al. > Filename : draft-ietf-ccamp-ethernet-gmpls-provider-reqs-01.txt > Pages : 19 > Date : 2008-12-10 > > Generalized Multi-Protocol Label Switching (GMPLS) is applicable to > Ethernet switches supporting Provider Backbone Bridge Traffic > Engineering (PBB-TE) networks. The GMPLS controlled Ethernet label > switch network not only automates creation of Ethernet Label Switched > Paths(Eth-LSPs), it also provides sophisticated Eth-LSP recovery > Mechanisms such as protection and restoration of an Eth-LSP. This > document describes the requirements for the set of solutions of GMPLS > controlled Ethernet label switch networks. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ethernet-gmpls-provider-reqs-01.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > 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://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > From claudio.beardo@italsoft-mi.it Thu Dec 11 06:08:49 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4DCC28C1B2; Thu, 11 Dec 2008 06:08:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.11 X-Spam-Level: **** X-Spam-Status: No, score=4.11 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_EQ_DSL=1.129, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SBL=20, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s4dw7yjwYdem; Thu, 11 Dec 2008 06:08:49 -0800 (PST) Received: from athedsl-4381972.home.otenet.gr (athedsl-4381972.home.otenet.gr [79.130.77.4]) by core3.amsl.com (Postfix) with SMTP id 53B8C28C187; Thu, 11 Dec 2008 06:08:34 -0800 (PST) Message-ID: Date: Thu, 11 Dec 2008 09:08:27 -0500 From: "Samuel Wolf" Subject: Emporio Armani better than original To: atompub-archive@megatron.ietf.org Content-Type: text/plain Content-Transfer-Encoding: 7bit Hello Samuel Christmas is the time to get Tag Heuer watch, and the only place to get top notch watches that look and perform exactly like the originals is http://www.zihiksup.com/ Get two deeply discounted watches and take an extra 15% discount. http://www.zihiksup.com/ Sincerely, Mr Wolf From jenniferm@aklaf.com Thu Dec 11 08:41:36 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35F333A68B6 for ; Thu, 11 Dec 2008 08:41:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.089 X-Spam-Level: X-Spam-Status: No, score=-4.089 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HTML_IMG_ONLY=1.666, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xWk-m+DNv7Aa for ; Thu, 11 Dec 2008 08:41:36 -0800 (PST) Received: from c-98-195-63-238.hsd1.tx.comcast.net (c-98-195-63-238.hsd1.tx.comcast.net [98.195.63.238]) by core3.amsl.com (Postfix) with SMTP id 441553A6782 for ; Thu, 11 Dec 2008 08:41:34 -0800 (PST) To: Subject: Your order From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081211164135.441553A6782@core3.amsl.com> Date: Thu, 11 Dec 2008 08:41:34 -0800 (PST)
Visit site now!

From odarla@amax.com Thu Dec 11 10:12:57 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 957EB28C0ED for ; Thu, 11 Dec 2008 10:12:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.935 X-Spam-Level: X-Spam-Status: No, score=-8.935 tagged_above=-999 required=5 tests=[BAYES_95=3, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_HTML_IMG_ONLY=1.666, TVD_SPACE_RATIO=2.219, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tp8xzq-qbXIv for ; Thu, 11 Dec 2008 10:12:57 -0800 (PST) Received: from abspc.com (unknown [200.160.20.220]) by core3.amsl.com (Postfix) with SMTP id 7982F3A6C12 for ; Thu, 11 Dec 2008 10:10:57 -0800 (PST) To: Subject: Delivery Status Notification From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081211181057.7982F3A6C12@core3.amsl.com> Date: Thu, 11 Dec 2008 10:10:57 -0800 (PST)
Visit site now!

From owner-ccamp@ops.ietf.org Thu Dec 11 15:17:41 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B514D3A6AAC for ; Thu, 11 Dec 2008 15:17:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.654 X-Spam-Level: X-Spam-Status: No, score=-0.654 tagged_above=-999 required=5 tests=[AWL=-0.206, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, J_CHICKENPOX_93=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J42kvWYcCke3 for ; Thu, 11 Dec 2008 15:17:41 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A9E333A699C for ; Thu, 11 Dec 2008 15:17:38 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LAuhx-0003dg-0R for ccamp-data0@psg.com; Thu, 11 Dec 2008 23:12:37 +0000 Received: from [128.9.168.207] (helo=bosco.isi.edu) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LAuhm-0003bb-Ju for ccamp@ops.ietf.org; Thu, 11 Dec 2008 23:12:32 +0000 Received: by bosco.isi.edu (Postfix, from userid 70) id 543C21A5483; Thu, 11 Dec 2008 15:12:26 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: RFC 5316 on ISIS Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, ccamp@ops.ietf.org Message-Id: <20081211231226.543C21A5483@bosco.isi.edu> Date: Thu, 11 Dec 2008 15:12:26 -0800 (PST) Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: A new Request for Comments is now available in online RFC libraries. RFC 5316 Title: ISIS Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering Author: M. Chen, R. Zhang, X. Duan Status: Standards Track Date: December 2008 Mailbox: mach@huawei.com, zhangrenhai@huawei.com, duanxiaodong@chinamobile.com Pages: 19 Characters: 45408 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ccamp-isis-interas-te-extension-04.txt URL: http://www.rfc-editor.org/rfc/rfc5316.txt This document describes extensions to the ISIS (ISIS) protocol to support Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (TE) for multiple Autonomous Systems (ASes). It defines ISIS-TE extensions for the flooding of TE information about inter-AS links, which can be used to perform inter- AS TE path computation. No support for flooding information from within one AS to another AS is proposed or defined in this document. [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-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute From owner-ccamp@ops.ietf.org Thu Dec 11 19:43:10 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A346528C0E5 for ; Thu, 11 Dec 2008 19:43:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.546 X-Spam-Level: X-Spam-Status: No, score=-9.546 tagged_above=-999 required=5 tests=[AWL=-1.052, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gXvYrDIOGBAl for ; Thu, 11 Dec 2008 19:43:09 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CBBE13A682D for ; Thu, 11 Dec 2008 19:43:08 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LAyoC-000CyS-6l for ccamp-data0@psg.com; Fri, 12 Dec 2008 03:35:20 +0000 Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LAyo4-000CqY-Tm for ccamp@ops.ietf.org; Fri, 12 Dec 2008 03:35:17 +0000 X-IronPort-AV: E=Sophos;i="4.36,208,1228089600"; d="scan'208,217";a="28409512" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 12 Dec 2008 03:35:05 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id mBC3Z5ve021134; Fri, 12 Dec 2008 04:35:05 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mBC3Z5sP010733; Fri, 12 Dec 2008 03:35:05 GMT Received: from xmb-ams-33a.cisco.com ([144.254.231.85]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Dec 2008 04:35:04 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C95C0A.9E8A562A" Subject: RE: new version of LSP DPPM draft Date: Fri, 12 Dec 2008 04:32:16 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: new version of LSP DPPM draft thread-index: AclZ7PlBrPqlTUMORfGBmVQ8cLKXhgCHUGWy References: <4CE0322579F54648BAAC52322768DCC3@your029b8cecfe> From: "Monique Morrow (mmorrow)" To: "Adrian Farrel" , Cc: X-OriginalArrivalTime: 12 Dec 2008 03:35:04.0890 (UTC) FILETIME=[9F4E31A0:01C95C0A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=11160; t=1229052905; x=1229916905; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mmorrow@cisco.com; z=From:=20=22Monique=20Morrow=20(mmorrow)=22=20 |Subject:=20RE=3A=20new=20version=20of=20LSP=20DPPM=20draft |Sender:=20; bh=nUbqLWSgrEpXQIieQQxKmWGM4/8BC+MBqaRLw8eKIz0=; b=EYeT2J8ZY7mBHBAgDl2SGG6rhuzx7TTm5nb2c29UbWfRj8I6vZxUB5set5 yKBug+uCEikiqWSuSUTpksUPRoJnVt+LkSaZ3I9CC73n8xxOOWZflJE3c6xi yr96pUNN/C; Authentication-Results: ams-dkim-2; header.From=mmorrow@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01C95C0A.9E8A562A Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Adrian, 1. Thanks for the forward. 2. Observation: nice productive dialogue on the technical merits of the = draft=20 Best/m Monique Jeanne Morrow SP APAC CTO/Distinguished Consulting Engineer -----Original Message----- From: owner-ccamp@ops.ietf.org on behalf of Adrian Farrel Sent: Tue 12/9/2008 2:56 AM To: ccamp@ops.ietf.org Subject: Fw: new version of LSP DPPM draft =20 Forwarded on behalf of Guoying Zhang: ----- Original Message -----=20 From: "gyzhang" Sent: Tuesday, December 09, 2008 2:14 AM Subject: new version of LSP DPPM draft Hi all, A new version of DPPM draft (LSP Dynamic Provisioning Performance = Metrics in=20 GMPLS Networks) has just been posted on the IETF website. This draft was = discussed in the Dublin meeting. The authors have now updated the draft=20 according to the discussions during and after the meeting. The following = are=20 the summary of discussion and modifications made to the draft. 1. During and after the meeting, some discussion was made about the = data=20 plane and control plane synchronization. Thanks to Adrian, some rules=20 clarifying their relations were identified in existing documents. (1) Three documents stated the rules in the forward direction RFC 3471 section 3.4: an ingress node should not transmit data traffic = on a=20 suggested label until the downstream node passes a label upstream. The=20 implication here is that an ingress node may (safely) start to transmit = data=20 when it receives a label in a Resv message. This also shows in RFC 3473 section 2.5: An ingress node SHOULD NOT=20 transmit data traffic using a suggested label until the downstream node=20 passes a corresponding label upstream. Also in RFC3209 section 4.1.1.1: The node then sends the new LABEL = object=20 as part of the Resv message to the previous hop. The node SHOULD be = prepared=20 to forward packets carrying the assigned label prior to sending the Resv = message. "before" is very telling. It means that the XC must be in place = to=20 forward traffic before Resv is sent. (2) For the reverse direction We have RFC 3473 section 3.1: The Upstream_Label object MUST indicate a=20 label that is valid for forwarding at the time the Path message is sent. = "valid for forwarding" should be taken to mean that it is OK to receive = data=20 and it will be forwarded. But it can also be taken to mean "acceptable = for=20 use" i.e. available to be cross-connected. This is clarified later in RFC 3473 section 3.1: Terminator nodes = process=20 Path messages as usual, with the exception that the upstream label can=20 immediately be used to transport data traffic associated with the LSP=20 upstream towards the initiator. This is pretty clear. When a Path = message=20 has been fully processed by an egress node, it is completely safe to=20 transmit data toward the ingress (i.e. reverse path data). (3) To clarify this assumption (that the these rules are followed) we=20 include the following text into the discussion section (section 15) This document assumes that the correct procedures for installing the = data=20 plane are followed as described in [RFC3209], [RFC3471], and [RFC3473]. = That=20 is, that by the time the egress receives and processes a Path message, = it is=20 safe for the egress to transmit data on the reverse path, and that by = the=20 time the ingress receives and processes a Resv message it is safe for = the=20 ingress to transmit data on the forward path. This document does not = include=20 any verification that the implementations of the control plane software = are=20 conformant, although such tests could be constructed with the use of=20 suitable signal generation test equipment. 2. During the Dublin meeting, the authors raised the open issue of = using=20 two way signaling or three way signaling. After some discussions within = the=20 editor team, an agreement has been reached and the following text was = added=20 to the discussion section (section 15) o Bidirectional LSPs may be setup using three way signaling, where the = initiate node will send a RESV_CONF message downstream upon receiving = the=20 RESV message. The RESV_CONF message is used to notify the terminate node = that it can transfer data upstream. Actually, both directions should be=20 ready to transfer data when the RESV message is received by the initiate = node. Therefore, the bidirectional LSP setup delay defined in this = document,=20 does not take the confirmation procedure into account. We thank to Lou, Igor and Adrian for their valuable comments and = discussions=20 during and after the meeting. The authors would like to have more = experts=20 from the WG to review this draft. And we hope to request a WG last call=20 soon. best regards, ????????Guoying Zhang ????????gyzhang@sina.com ??????????2008-12-08 ------_=_NextPart_001_01C95C0A.9E8A562A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: new version of LSP DPPM draft

Adrian,

1. Thanks for the forward.

2. Observation: nice productive dialogue on the technical merits of the = draft

Best/m



Monique Jeanne Morrow
SP APAC CTO/Distinguished Consulting Engineer



-----Original Message-----
From: owner-ccamp@ops.ietf.org on behalf of Adrian Farrel
Sent: Tue 12/9/2008 2:56 AM
To: ccamp@ops.ietf.org
Subject: Fw: new version of LSP DPPM draft

Forwarded on behalf of Guoying Zhang:

----- Original Message -----
From: "gyzhang" <gyzhang@sina.com>
Sent: Tuesday, December 09, 2008 2:14 AM
Subject: new version of LSP DPPM draft


Hi all,

A new version of DPPM draft (LSP Dynamic Provisioning Performance = Metrics in
GMPLS Networks) has just been posted on the IETF website. This draft = was
discussed in the Dublin meeting. The authors have now updated the = draft
according to the discussions during and after the meeting. The following = are
the summary of discussion and modifications made to the draft.

 1. During and after the meeting, some discussion was made about = the data
plane and control plane synchronization. Thanks to Adrian, some = rules
clarifying their relations were identified in existing documents.

 (1) Three documents stated the rules in the forward direction
RFC 3471 section 3.4: an ingress node should not transmit data traffic = on a
suggested label until the downstream node passes a label upstream. = The
implication here is that an ingress node may (safely) start to transmit = data
when it receives a label in a Resv message.

 This also shows in RFC 3473 section 2.5:  An ingress node = SHOULD NOT
transmit data traffic using a suggested label until the downstream = node
passes a corresponding label upstream.

 Also in RFC3209 section 4.1.1.1: The node then sends the new LABEL = object
as part of the Resv message to the previous hop. The node SHOULD be = prepared
to forward packets carrying the assigned label prior to sending the = Resv
message. "before" is very telling. It means that the XC must = be in place to
forward traffic before Resv is sent.

 (2) For the reverse direction
We have RFC 3473 section 3.1: The Upstream_Label object MUST indicate = a
label that is valid for forwarding at the time the Path message is = sent.
"valid for forwarding" should be taken to mean that it is OK = to receive data
and it will be forwarded. But it can also be taken to mean = "acceptable for
use" i.e. available to be cross-connected.

 This is clarified later in RFC 3473 section 3.1: Terminator nodes = process
Path messages as usual, with the exception that the upstream label = can
immediately be used to transport data traffic associated with the = LSP
upstream towards the initiator. This is pretty clear. When a Path = message
has been fully processed by an egress node, it is completely safe to
transmit data toward the ingress (i.e. reverse path data).

  (3) To clarify this assumption (that the these rules are = followed) we
include the following text into the discussion section (section 15)
This document assumes that the correct procedures for installing the = data
plane are followed as described in [RFC3209], [RFC3471], and [RFC3473]. = That
is, that by the time the egress receives and processes a Path message, = it is
safe for the egress to transmit data on the reverse path, and that by = the
time the ingress receives and processes a Resv message it is safe for = the
ingress to transmit data on the forward path. This document does not = include
any verification that the implementations of the control plane software = are
conformant, although such tests could be constructed with the use of
suitable signal generation test equipment.


 2. During the Dublin meeting, the authors raised the open issue of = using
two way signaling or three way signaling. After some discussions within = the
editor team, an agreement has been reached and the following text was = added
to the discussion section (section 15)

  o Bidirectional LSPs may be setup using three way signaling, = where the
initiate node will send a RESV_CONF message downstream upon receiving = the
RESV message. The RESV_CONF message is used to notify the terminate = node
that it can transfer data upstream. Actually, both directions should = be
ready to transfer data when the RESV message is received by the = initiate
node. Therefore, the bidirectional LSP setup delay defined in this = document,
does not take the confirmation procedure into account.


We thank to Lou, Igor and Adrian for their valuable comments and = discussions
during and after the meeting. The authors would like to have more = experts
from the WG to review this draft. And we hope to request a WG last = call
soon.

 best regards,
 ????????Guoying Zhang
 ????????gyzhang@sina.com
 ??????????2008-12-08

------_=_NextPart_001_01C95C0A.9E8A562A-- From aaron@brandttractor.com Fri Dec 12 02:30:28 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D57893A6915; Fri, 12 Dec 2008 02:30:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.217 X-Spam-Level: X-Spam-Status: No, score=-2.217 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SBL=20, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZaH+sZGGVlwx; Fri, 12 Dec 2008 02:30:28 -0800 (PST) Received: from 201-13-153-43.dial-up.telesp.net.br (201-13-153-43.dial-up.telesp.net.br [201.13.153.43]) by core3.amsl.com (Postfix) with SMTP id AE03D3A684D; Fri, 12 Dec 2008 02:30:14 -0800 (PST) Message-ID: Date: Fri, 12 Dec 2008 05:29:21 -0500 From: "Blair Park" Subject: Christmas Cartier watches bargain To: atompub-archive@megatron.ietf.org Content-Type: text/plain Content-Transfer-Encoding: 7bit Hello Blair If you've waited to get your Jaeger LeCoultre watch, this is the right time to go for it. http://www.nowtill.com/ Get two deeply discounted watches and take an extra 15% discount. http://www.nowtill.com/ Sincerely, Mr Park From 6400a8c0@readytechs.com Fri Dec 12 03:20:35 2008 Return-Path: <6400a8c0@readytechs.com> X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F83C3A6AB1; Fri, 12 Dec 2008 03:20:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.839 X-Spam-Level: X-Spam-Status: No, score=-14.839 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SBL=20, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lPtc0A3cW3UM; Fri, 12 Dec 2008 03:20:34 -0800 (PST) Received: from 38-mo4-1.acn.waw.pl (38-mo4-1.acn.waw.pl [82.210.168.38]) by core3.amsl.com (Postfix) with SMTP id 8BEEA3A6AAD; Fri, 12 Dec 2008 03:20:19 -0800 (PST) Message-ID: Date: Fri, 12 Dec 2008 06:20:07 -0500 From: "Raul Strong" Subject: Christmas Patek Phillipe watches bargain To: architecture-discuss@ietf.org Content-Type: text/plain Content-Transfer-Encoding: 7bit Hello Raul Looking for a IWC watch that no one can tell from the original? You're in luck, because we have the best copies http://www.nowflat.com/ With top notch customer service and super warranty, we stand behind our watches. http://www.nowflat.com/ Sincerely, Mr Strong From jon@19.to Fri Dec 12 12:17:50 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD7BA28C111 for ; Fri, 12 Dec 2008 12:17:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -26.892 X-Spam-Level: X-Spam-Status: No, score=-26.892 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_EQ_JP=1.244, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_PBL=0.905, RDNS_NONE=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uE3qk8JRyfU4 for ; Fri, 12 Dec 2008 12:17:50 -0800 (PST) Received: from agri.pref.ibaraki.jp (unknown [88.226.198.183]) by core3.amsl.com (Postfix) with SMTP id 719AA28C10B for ; Fri, 12 Dec 2008 12:17:46 -0800 (PST) To: Subject: Re: Order status From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081212201747.719AA28C10B@core3.amsl.com> Date: Fri, 12 Dec 2008 12:17:46 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From owner-ccamp@ops.ietf.org Fri Dec 12 13:31:51 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDFE428C222 for ; Fri, 12 Dec 2008 13:31:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TqdLAZRDIAxJ for ; Fri, 12 Dec 2008 13:31:50 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7AFAE28C230 for ; Fri, 12 Dec 2008 13:31:50 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LBFWh-0006tT-4f for ccamp-data0@psg.com; Fri, 12 Dec 2008 21:26:23 +0000 Received: from [206.16.17.180] (helo=usaga04-in.huawei.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LBFWb-0006t4-Oz for ccamp@ops.ietf.org; Fri, 12 Dec 2008 21:26:20 +0000 Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KBS001KM8VSXK@usaga04-in.huawei.com> for ccamp@ops.ietf.org; Fri, 12 Dec 2008 15:26:16 -0600 (CST) Received: from Y73674 ([10.124.12.71]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KBS005SS8VQLE@usaga04-in.huawei.com> for ccamp@ops.ietf.org; Fri, 12 Dec 2008 15:26:16 -0600 (CST) Date: Fri, 12 Dec 2008 15:26:14 -0600 From: Lucy Yong Subject: RE: comments on the draft of LSP hierarchy In-reply-to: To: 'Adrian Farrel' , shiomoto.kohei@lab.ntt.co.jp, ccamp@ops.ietf.org Message-id: <004701c95ca0$43a24300$470c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AclaI4NNnWYmsreJQ6Wr85050l8E1gCdVhqw References: <008301c95984$ff315cb0$fd32fea9@china.huawei.com> <6FD613982F844ABDAE7193395355FB3A@your029b8cecfe> <007c01c95a1b$87805080$470c7c0a@china.huawei.com> Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Hi Adrian, I would like to clarify on the use of IGP instance Identifier. If there is no such TLV listed in LSP_TUNNEL_INFERFACE_ID object, the LSP is to be advertised in the same instance of the IGP as was used to advertise the TE links that the LSP traverse, or If there are such TLVs listed in LSP_TUNNEL_INFERFACE_ID object, the LSP is to be advertised in those IGPs in TLV list. In order to advertise in the IGP as was used to advertise the TE links that the LSP traverses, an TLV has to be used but just fill value as 0xffffff. Is my understanding correct? I think how client/server network (1.1.6) can apply to inter AS case. In this case, the LSP is created in server network (IGP A) as inter-AS link between AS B and AS C. Each end point of LSP connects IGP B and IGP C, respectively, i.e. one end need to advertise in IGP B and another end advertises in IGP C. In this case, only ingress end point needs to know its side IGP identifier so no needs to list IGP B and IGP C in TLVs. But we also don't want to advertise this LSP in the IGP A. Can we address this case? Regards, Lucy > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: Tuesday, December 09, 2008 11:27 AM > To: Lucy Yong; shiomoto.kohei@lab.ntt.co.jp; ccamp@ops.ietf.org > Subject: Re: comments on the draft of LSP hierarchy > > Hi Lucy, > > >> > 1) When LSP is used for Client/Server Network: the server network sets > >> > LSP as private link with one or more client IGP instances; When LSP > >> > is used as routing adjacency: the network sets LSP as non-private link > >> > with routing adjacency. Is this correct? > >> > >> I think that if the link is private, there is no need and possibly no > >> meaning to set a client IGP instance. Setting an IGP instance implies > >> that > >> the link is to be advertised in some IGP instance, and a private link > >> will > >> not be advertised. > > > > [Lucy:] I though that signaling is within an IGP (say IGP A). So if > > signaling a LSP for client/server network (say IGP B), RSVP needs set > > action > > as private link (not adv in IGP A), FA, and lists other IGP instances (IGP > > B). It seems my understanding is not correct. > > Are you saying that RSVP signaling is not tight to an IGP instance? > > Without > > using private link indication, how does the LSA of IGP A know if it should > > advertise in IGP A or not? > > I am a bit confused by your question. > > When an LSP is signaled in RSVP-TE it can be used to create a link in one or > more other networks. > > If the link is to be advertised in the same instance of the IGP that was > used to advertise the links that were used by RSVP-TE when it signaled the > LSP, then this is a Forwarding Adjacency as already described. > > If the link is to be advertised in a separate instance of an IGP (perhaps an > IGP that advertises links in another network layer) then the IGP instance is > indicated in the signaling message used to set up the LSP as described in > this draft. > > If the link is not to be advertised (i.e. is a private link) then you do not > include the IGP instance because it is not needed. > > >> > 3) A component link in a link bundle has component link identifier. > >> > This > >> > identifier is the link ID that is advertised in LSA. Is that correct? > >> > >> Section 2.4 says... > >> > >> When an LSP is to be used as a component link of a link bundle, the > >> LSP_TUNNEL_INTERFACE_ID object refers to the bundle indicating how > >> the bundle is addressed and used, and a new TLV indicates the > >> component link identifier for the link that the LSP creates. > >> > >> Only the component link identifier is advertised by the IGP. The > >> component > >> link identifier is used locally (between link end points), but may also > >> be > >> present in an ERO and RRO in signaling with the assumption that this > >> inormaiton is coordinated by some other means. > > > > [Lucy:] If component link identifier is used locally, why does it be > > advertised in the IGP? > > I'm sorry, I mistyped (that will teach me to try to write emails to you > while concentrating on ITU-T politics ;-) > > I should have written... > > Only the *bundle* link identifier is advertised by the IGP. The component > link identifier is used locally (between link end points), but may also be > present in an ERO and RRO in signaling with the assumption that this > information is coordinated by some other means. > > >> > 4) In section 3.3, it states: > >> > > >> > If the B-flag in the Actions field of the LSP_TUNNEL_INTERFACE_ID > >> > object is set, the other fields of the object apply to the link > >> > bundle itself. That is, the interface identifiers (numbered or > >> > unnumbered) and the other flags in the Actions field apply to the > >> > link bundle and not to the component link that the LSP will form. > >> > > >> > Furthermore, the IGP Instance Identifier TLV (if present) also > >> > applies to the link bundle and not to the component link. > >> > > >> > It seems odd way to set actions for link bundle. Should we first set > >> > the > >> > link bundle with the action, then add component link to the link bundle > >> > without action? > >> > >> The issue is that the link bundle itself is not signaled. Only the > >> component links correspond to LSPs that are signaled. Thus, > >> when the first component link is signaled, there is no link bundle > >> in existence. > > > > [Lucy:] Yes, it is the issue. Would it be nice to have a way to signal a > > link bundle first? It can apply to composite link as well. > > You could come up with a way to do that. You should not use LSP signaling to > do this - the bundle or composite link should not be known at transit points > of the LSP. You might want to use a GMPLS call to achieve this function if > (and only if?) the bundle/composite link needs to be communicated in > advance. > > > If we stay as it is, when adding the second component link to a link > > bundle, > > RSVP has to make sure all the actions have to be the exact same, is that > > right? Or we only require the first signaled component link to indicate a > > link bundle properties. > > I think that might depend on application. > > > If we want to add a component link in a link bundle to an IGP instance, we > > will use LSP_TUNNEL_INTERFACE_ID with IGP TLV and component link TLV, > how > > to > > distinguish two type of TLV within an LSP_TUNNEL_INTERFACE_ID object? > > They have different TLV type values. > > >> > 6) For CTG scenarios, we create a set of LSPs to form a single > >> > composite > >> > link to client/server network. We can first create a composite link as > >> > a > >> > private link with one or more client IGP instances with (at least one > >> > component link); then individual component link can be added to and > >> > removed from the composite link. Component links are also private link > >> > (different from component link in link bundle) and have different TE > >> > properties. We can also create composite link for routing adjacency > >> > (single IGP case). We need some extension to cover these scenarios. > >> > Could we consider adding this into the document? > >> > >> I believe that the mechanisms in the hierarchy bis draft will be > >> applicable to the creation of LSPs that are used as components of > >> CTGs. In my view (as an author) it would be premature to add this > >> to the draft at this stage as it would create a normative reference to > >> the CTG work which has not yet been adopted by any working group > >> and is bound to take some time to complete. > > > > [Lucy:] Operator want to implement CTG soon and hope the framework and > > requirement draft can be completed soon. Although CTG can be manually > > configured at beginning, it would be nice to have an GMPLS way to > > configure > > it as well. > > Yes. I agree. > > Hence my proposal below. > > >> My preferred approach is that the hierarchy bis draft creates the > >> framework and a registry of actions carried in the flags field (see > >> section 5.2). > >> Any new work, such as your CTG work, can then request the > >> allocation of a further bit and can define the behavior if the bit > >> is set. > > > > [Lucy:] Thank you for the suggestion. > > Regards, > Adrian > From jw@alpha-omegaserv.com Sat Dec 13 04:26:12 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 055553A690A for ; Sat, 13 Dec 2008 04:26:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.831 X-Spam-Level: X-Spam-Status: No, score=-8.831 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_FONT_LOW_CONTRAST=0.124, HTML_IMAGE_ONLY_08=1.787, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SC_TOP200_89=3, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AvPXM8EVHjXO for ; Sat, 13 Dec 2008 04:26:11 -0800 (PST) Received: from amcorgroup.com (unknown [89.222.150.253]) by core3.amsl.com (Postfix) with SMTP id 41EC93A6863 for ; Sat, 13 Dec 2008 04:26:09 -0800 (PST) To: Subject: Re: Order status From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081213122610.41EC93A6863@core3.amsl.com> Date: Sat, 13 Dec 2008 04:26:09 -0800 (PST)
Go to site!

Your woman won't forget her pleasure



toward people he had made a great deal of money for in the previouswrapped up in his work, he had little time for his wife, even less for
 From chris@pjdrew.co.uk Sat Dec 13 07:38:06 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E8083A6822; Sat, 13 Dec 2008 07:38:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.983 X-Spam-Level: **** X-Spam-Status: No, score=4.983 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SBL=20, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AE0IcYWg75OM; Sat, 13 Dec 2008 07:38:05 -0800 (PST) Received: from chello087207039043.chello.pl (chello087207039043.chello.pl [87.207.39.43]) by core3.amsl.com (Postfix) with SMTP id BB10C3A67E9; Sat, 13 Dec 2008 07:37:51 -0800 (PST) Message-ID: Date: Sat, 13 Dec 2008 10:37:37 -0500 From: "Sofia Michaud" Subject: Christmas Emporio Armani watches bargain To: architecture-discuss@ietf.org Content-Type: text/plain Content-Transfer-Encoding: 7bit Hello Sofia How about buying yourself a two Bvlgari watches the same day? It's not impossible, mostly when you can get them for a couple hundred bucks http://www.nowtill.com/ We are offering wholesaler prices on all watches during the month of December. http://www.nowtill.com/ Sincerely, Mr Michaud From kayodspi@ains-inc.com Mon Dec 15 01:43:59 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DD6E3A6829 for ; Mon, 15 Dec 2008 01:43:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -22.831 X-Spam-Level: X-Spam-Status: No, score=-22.831 tagged_above=-999 required=5 tests=[BAYES_95=3, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_SPACE_RATIO=2.219, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mmf4qkKNe05X for ; Mon, 15 Dec 2008 01:43:58 -0800 (PST) Received: from 212.com (unknown [121.210.133.152]) by core3.amsl.com (Postfix) with SMTP id E65CB3A67CC for ; Mon, 15 Dec 2008 01:43:53 -0800 (PST) To: Subject: , December 48% off From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081215094354.E65CB3A67CC@core3.amsl.com> Date: Mon, 15 Dec 2008 01:43:53 -0800 (PST) Click here to view as a webpage From owner-ccamp@ops.ietf.org Mon Dec 15 04:33:41 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE3133A69D0 for ; Mon, 15 Dec 2008 04:33:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.911 X-Spam-Level: X-Spam-Status: No, score=-0.911 tagged_above=-999 required=5 tests=[AWL=-0.417, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wYk8gVqZJ+Hg for ; Mon, 15 Dec 2008 04:33:41 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 226FE3A6994 for ; Mon, 15 Dec 2008 04:33:41 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LCCYG-0007yT-2o for ccamp-data0@psg.com; Mon, 15 Dec 2008 12:27:56 +0000 Received: from [62.128.201.248] (helo=asmtp1.iomartmail.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LCCYB-0007y1-Hr for ccamp@ops.ietf.org; Mon, 15 Dec 2008 12:27:53 +0000 Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id mBFCRjTd028089 for ; Mon, 15 Dec 2008 12:27:48 GMT Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id mBFCRiwB028042 for ; Mon, 15 Dec 2008 12:27:45 GMT Message-ID: Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Working group last call draft-ietf-ccamp-gmpls-ason-routing-ospf-06.txt Date: Mon, 15 Dec 2008 12:27:37 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: This email starts the working group last call on draft-ietf-ccamp-gmpls-ason-routing-ospf-06.txt The last call will run for three weeks to give people a little extra time over the Christmas period. Thus the call will end on 5th January 2009 at noon GMT. Please send your comments to the CCAMP mailing list. Note that the I-D is positioned as Experimental. This is appropriate for a modification to the use of a routing protocol where we do not have significant experience of the impact of the change to the way the routing protocol works. Thanks, Adrian PS. This will be copied to the OSPF working group. From owner-ccamp@ops.ietf.org Mon Dec 15 05:19:49 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 759A73A69EC for ; Mon, 15 Dec 2008 05:19:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.921 X-Spam-Level: X-Spam-Status: No, score=-0.921 tagged_above=-999 required=5 tests=[AWL=-0.427, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tMafMJYCNCoV for ; Mon, 15 Dec 2008 05:19:48 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5BA953A6784 for ; Mon, 15 Dec 2008 05:19:48 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LCDI6-000Ccp-Vd for ccamp-data0@psg.com; Mon, 15 Dec 2008 13:15:18 +0000 Received: from [62.128.201.248] (helo=asmtp1.iomartmail.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LCDI0-000CcV-Lz for ccamp@ops.ietf.org; Mon, 15 Dec 2008 13:15:15 +0000 Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id mBFDFA4Q023156 for ; Mon, 15 Dec 2008 13:15:11 GMT Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id mBFDFAAi023146 for ; Mon, 15 Dec 2008 13:15:10 GMT Message-ID: Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Draft Response to OIF on Resv Usage Date: Mon, 15 Dec 2008 13:15:04 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Hi, We (well, mainly Deborah and I) have been delinquent in responding to the OIF's communication http://www.olddog.co.uk/oif2008_063_02.pdf Here is a draft response. Please comment this week and we will send the response as a Christmas present. Thanks, Adrian === Dear Lyndon, CCAMP owes the OIF responses to several communications. Apologies for the delay in producing formal responses. The issues raised were discussed at some length during the months after we received the communication both on and off the CCAMP mailing list, and I know you were involved in some of those discussions, but we forgot to send the formal responses. We will generate a series of responses with the technical issues broken out into separate threads. This first one addresses the issue of Resv usage during make-before-break as raised in oif2008.063.02.pdf. Best regards, Adrian Farrel and Deborah Brungard IETF CCAMP Working Group Co-chairs --- > OIF thanks CCAMP for its prompt and very informative response > to our liaison on OIF interoperability demo findings, sent > from our 4Q2007 meeting. We appreciate CCAMP's offer to use > the CCAMP mailing list for questions during our demo planning > and testing, although more structured liaisons are still > useful in our view to reflect meeting results and issues or > comments that are agreed across OIF members (as opposed to > individual views). [SNIP] > Based on your response liaison, it is our understanding that > per-LSP RESV messages should be expected for the "make- > before-break" scenario of modification. However, some members > have commented that it appears to be possible in the > specifications to use a single RESV message for multiple LSPs > because: > a) RFC 2205 allows the RESV message to carry multiple > FILTER_SPEC objects, specifically with the Shared Explicit > (SE) style that supports reservation sharing; and > b) The FILTER_SPEC object was extended in RFC 3209 to carry > the LSP_ID. > > Clarification would be appreciated as to whether we should > allow for receiving a single RESV message with multiple > FILTER_SPEC objects in the "make-before-break" scenario using > the SE style. We believe this issue is substantially the same as the following issue raised in the OIF correspondence dated November 29, 2007 with the subject "Liaison to IETF Regarding 2007 Interop Test Findings". Here you wrote: >> - 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 our response, dated January 3, 2008, we stated: >> 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. To help clarify this point, we draw your attention to RFC 3209 which states: The SESSION object uniquely defines a traffic engineered tunnel. The SENDER_TEMPLATE and FILTER_SPEC objects carry an LSP ID. The SENDER_TEMPLATE (or FILTER_SPEC) object together with the SESSION object uniquely identifies an LSP tunnel. As LSP tunnels (or LSPs for short) are identified using different LSP IDs (as carried in SENDER_TEMPLATE and FILTER_SPEC objects) and each LSP is signaled independently, multiple FILTER_SPEC objects SHOULD NOT be allowed as part of make-before-break. From owner-ccamp@ops.ietf.org Mon Dec 15 05:36:28 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 556BC3A684E for ; Mon, 15 Dec 2008 05:36:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.903 X-Spam-Level: X-Spam-Status: No, score=-0.903 tagged_above=-999 required=5 tests=[AWL=-0.409, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Dyv74Hm1lsL for ; Mon, 15 Dec 2008 05:36:27 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D6F1D3A69DF for ; Mon, 15 Dec 2008 05:36:26 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LCDYW-000Dqm-Pj for ccamp-data0@psg.com; Mon, 15 Dec 2008 13:32:16 +0000 Received: from [62.128.201.248] (helo=asmtp1.iomartmail.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LCDYR-000DqB-CT for ccamp@ops.ietf.org; Mon, 15 Dec 2008 13:32:13 +0000 Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id mBFDW9Ho031848 for ; Mon, 15 Dec 2008 13:32:09 GMT Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id mBFDW8Pq031827 for ; Mon, 15 Dec 2008 13:32:09 GMT Message-ID: <6A12E0AF275D406DA16B7FBC738DE025@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Draft response to OIF on MEF-Related Work Date: Mon, 15 Dec 2008 13:32:04 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Hi, Please also comment on this draft response to the OIF. Thanks, Adrian === Dear Lyndon, In your communication oif2008.063.02.pdf dated February 14, 2008 you noted: > Finally, we noted the discussion on the CCAMP mailing list > regarding the computation of the Length field for TLVs, > especially for the Ethernet Bandwidth Profile TLV used in > the Ethernet Traffic Parameters draft. As this draft is > considered to be very important for support of MEF defined > Ethernet services, we request that this issue be resolved > as soon as possible within CCAMP. > > Our preference would be to compute the Length field for all > TLVs (except those in RFC 4420) based on the full TLV rather > than the Value alone, as this is the method commonly used in > the past for length computation in RSVP. Please note that RFC 4420 has been revised as draft-ietf-ccamp-rfc4420-bis-03.txt. This draft is in the RFC Editor's queue, and will shortly be published as an RFC that obsoletes RFC 4420. The change is to make the processing of all RSVP-TE TLVs consistent so that the Length field accounts for the full length of the TLV. This change has also been incorporated into the work on traffic parameters for Ethernet as described in draft-ietf-ccamp-ethernet-traffic-parameters-06.txt. You will be pleased to hear that we consider our work on MEF- related protocol extensions to be stable, and we will shortly issue working group last calls on the following drafts: draft-ietf-ccamp-ethernet-traffic-parameters-06.txt draft-ietf-ccamp-gmpls-ether-svcs-02.txt draft-ietf-ccamp-gmpls-mef-uni-01.txt draft-ietf-ccamp-gmpls-dcsc-channel-ext-00.txt In view of the imminent last call on this work, we would welcome any input from OIF members. Input should be made either by official communication from the OIF, or by email from any individual to the CCAMP mailing list (subscription details are found at http://www.ietf.org/html.charters/ccamp-charter.html). Best regards, Adrian Farrel and Deborah Brungard IETF CCAMP Working Group Co-Chairs From m_p17@afterwork.com Tue Dec 16 02:19:06 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 116FE3A6A5F for ; Tue, 16 Dec 2008 02:19:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -23.88 X-Spam-Level: X-Spam-Status: No, score=-23.88 tagged_above=-999 required=5 tests=[BAYES_95=3, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_SPACE_RATIO=2.219, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y5zk+FX50Pjs for ; Tue, 16 Dec 2008 02:19:00 -0800 (PST) Received: from 197.223-ppp.3menatwork.com (197.223-ppp.3menatwork.com [72.0.197.223]) by core3.amsl.com (Postfix) with SMTP id A3D833A67AD for ; Tue, 16 Dec 2008 02:18:59 -0800 (PST) To: Subject: RE: Message From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081216101859.A3D833A67AD@core3.amsl.com> Date: Tue, 16 Dec 2008 02:18:59 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From owner-ccamp@ops.ietf.org Tue Dec 16 09:34:33 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42A993A6AB0 for ; Tue, 16 Dec 2008 09:34:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.912 X-Spam-Level: X-Spam-Status: No, score=-0.912 tagged_above=-999 required=5 tests=[AWL=-0.418, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rN614JGbzpFR for ; Tue, 16 Dec 2008 09:34:32 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CEDCD28C0DC for ; Tue, 16 Dec 2008 09:34:31 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LCdih-000HrF-Pw for ccamp-data0@psg.com; Tue, 16 Dec 2008 17:28:31 +0000 Received: from [62.128.201.248] (helo=asmtp1.iomartmail.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LCdiZ-000HqE-HZ for ccamp@ops.ietf.org; Tue, 16 Dec 2008 17:28:28 +0000 Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id mBGHSJXc017617 for ; Tue, 16 Dec 2008 17:28:21 GMT Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id mBGHSHc8017542 for ; Tue, 16 Dec 2008 17:28:18 GMT Message-ID: Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Furthre draft to OIF : VCAT Date: Tue, 16 Dec 2008 17:28:12 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Hi, Review and comment please. Thanks, Adrian ==== Dear Lyndon, In your communication oif2007.377.02.pdf you made several comments about our VCAT/LCAS work, but did not specifically request any response. In communication oif2008.063.02.pdf you said: > We would also appreciate any feedback that you might have on > our liaison from the 4Q2007 meeting on VCAT/LCAS requirements, > especially whether these were incorporated into your work on > VCAT/LCAS support. This response addresses the points you made in the earlier communication. You wrote: > We have been monitoring with great interest the work on > VCAT/LCAS support in the IETF CCAMP WG, as we have done > prototyping work on control of VCAT/LCAS for interoperability > events in 2005 and 2007. As a result of our internal > discussion and prototyping work, we have identified a number > of requirements on VCAT/LCAS support that we believe are > important and may be helpful input to your work. > > In general, we agree with the requirements already identified > in draft-ietf-ccamp-gmpls-vcat-lcas-03.txt. Please note that this draft is now at the 06 revision and may be found as draft-ietf-ccamp-gmpls-vcat-lcas-06.txt > The following have been identified as important functionality > for control plane support for VCAT/LCAS that is not currently > identified in the CCAMP draft: > > - Ability to identify link endpoint capabilities associated > with VCAT such as support of LCAS functionality > - Possible additional requirement on ASON routing support > to be taken into account in CCAMP work on ASON routing > extensions rather than the VCAT/LCAS draft itself > - This might be generalizable to advertising inverse > multiplexing capabilities in addition to VCAT/LCAS CCAMP did consider extensions to IGPs to distribute inverse multiplexing, VCAT, and LCAS capabilities. This information would allow the initiator of a VCG to understand the capabilities of the egress that it is attempting to connect to. However, we decided that the LSP will not be set up to a different destination based on the VCAT capabilities. The LSP is required between a pair of LSRs, and there is no benefit to routing in distributing the end-point capabilities. Thus, we decided that if any negotiation is needed, it should be performed on the Call. > - Clean separation of VCG (VCAT Group) control from the > control of VCG members > - Supports the ability to create and modify the VCG > independent of its members We believe that this is exactly what our draft does. > - Supports potentially different sequences of creation, > e.g., creation of members first followed by VCG creation > or creation of VCG first followed by its members We believe that the ITU Recommendations that define VCAT do not support this behavior. We are also not convinced that this would be a valid way of operating a network - trails are not created on the off-chance that they will be used as part of a VCG at some time in the future. > - A single separate signaling session associated with the > VCG is an approach that has been prototyped successfully > in OIF interop events and may be a possible approach. While the use of a separate signaling session to establish the VCG is a fine way to conduct an experiment to establish data plane interoperability, this is not a good architectural solution for RSVP-TE. The signaling exchange of an RSVP-TE Path and Resv message is intended to establish an LSP. The coordination between end points for VCAT is far closer to the processes necessary for a Call, and that is why we have used the RSVP-TE Notify message exchange in our draft. > - We believe the current approach in the CCAMP draft has > limitations in this respect due to the incorporation of > multiple VCGs within a single call, as this does not > cleanly separate the VCG state and the state of its > component members. We suggest that CCAMP consider using a > single call per VCG instead, based on our prototyping > experiences. This may reflect some misunderstanding of the CCAMP draft. The draft currently allows a one-to-one correlation between Call and VCG. Component members are, of course, associated with the VCG and so the state of the component members is directly associated with the state of the VCG itself. > - Separation of VCG and member sessions will allow > unambiguous semantics for VCG characteristics vs. member > characteristics such as support of recovery modes Again, this may represent some misunderstanding of the CCAMP draft. The draft allows each LSP (VCG member) to be maintained with distinct characteristics. > - Ability to identify VCG members within VCG-related > signaling > - Note that it may be common in ASON environments for a VCG > connection to span multiple domains and RSVP sessions in > series, in which case session-specific objects such as > the LSP ID and Tunnel ID are not guaranteed to have > unique values end-to-end > - Manipulation of VCG characteristics requires the ability > to clearly and unambiguously identify the VCG members at > each end of the VCG We note that "session shuffling" is peculiar to the OIF way of addressing the ASON architecture, and the CCAMP working group has previously expressed its view that such a way of building a network, while functional, is not advisable. Since the OIF presumably has a solution to the fact that any one connection must be unambiguously identifiable at each end of the connection, we do not consider that the problem is exacerbated by the construction of a VCG. Indeed, session shuffling can only work if there is a consistent, coherent, repeatable, and reversible mapping of the various parameters (such as addresses, Tunnel ID, and LSP ID) at domain boundaries. That said, we believe that the ASON architecture is currently struggling with issues of diverse routes of connections that provide protection. It has normally been the case that protection is terminated at domain boundaries (at E-NNIs), and this may also be the case for VCGs. > - Ability to maintain VCG state across control plane failures > - It is important to be able to maintain the VCG in the > event of temporary loss of control plane connectivity or > control plane state > - We believe that graceful restart-like capabilities in > RSVP need to be supported to maintain VCG state across > control plane failure. You are correct that the control plane state must be recoverable after control plane component restart, and must be resynchronized after control plane connectivity recovery. Further, the data plane state must not be perturbed by control plane failure or restart. Graceful restart is a standard part of GMPLS RSVP-TE. It can be found in RFC 5063. A more detailed description (including a discussion of the handling of multiple failures) can be found in draft-ietf-ccamp-gr-description-03.txt which is currently being reviewed by the IESG prior to publication as an RFC. Restart processing for GMPLS Calls is covered in RFC 4974. The VCAT work simply re-uses these mechanisms and no further description is required. Regards, Adrian Farrel and Deborah Brungard IETF CCAMP Working Group Co-Chairs From a.napolitano@meridiana.it Wed Dec 17 02:16:24 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B80FE3A680A; Wed, 17 Dec 2008 02:16:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -83.213 X-Spam-Level: X-Spam-Status: No, score=-83.213 tagged_above=-999 required=5 tests=[BAYES_80=2, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y0qmcGQ84WKH; Wed, 17 Dec 2008 02:16:17 -0800 (PST) Received: from host-62-141-239-217.tomaszow.mm.pl (host-62-141-239-217.tomaszow.mm.pl [62.141.239.217]) by core3.amsl.com (Postfix) with SMTP id 22C3328C133; Wed, 17 Dec 2008 02:15:41 -0800 (PST) Message-ID: Date: Wed, 17 Dec 2008 05:15:32 -0500 From: "Dale Sheldon" Subject: Chopard better than original To: call-home-bounces@ietf.org Content-Type: text/plain Content-Transfer-Encoding: 7bit Hello Dale I had never seen such beautiful and greatly-performing watches like the ones I found online at http://www.domedome.com/ With top notch customer service and super warranty, we stand behind our watches. http://www.domedome.com/ Sincerely, Mr Sheldon From laltmann@iastate.edu Wed Dec 17 04:52:40 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07A6C3A68CB for ; Wed, 17 Dec 2008 04:52:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.728 X-Spam-Level: **** X-Spam-Status: No, score=4.728 tagged_above=-999 required=5 tests=[BAYES_80=2, J_CHICKENPOX_35=0.6, J_CHICKENPOX_62=0.6, MILLION_USD=1.528] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 61PwqoTLzuux for ; Wed, 17 Dec 2008 04:52:33 -0800 (PST) Received: from mailhub-4.iastate.edu (mailhub-4.iastate.edu [129.186.140.14]) by core3.amsl.com (Postfix) with ESMTP id 918DD3A6901 for ; Wed, 17 Dec 2008 04:52:33 -0800 (PST) Received: from devirus-10.iastate.edu (devirus-10.iastate.edu [129.186.1.47]) by mailhub-4.iastate.edu (8.12.11.20060614/8.12.10) with SMTP id mBHCpe7i020589; Wed, 17 Dec 2008 06:51:40 -0600 Received: from (despam-10.iastate.edu [129.186.140.80]) by devirus-10.iastate.edu with smtp id 1d6c_2d9ba40e_cc38_11dd_969a_00137253420a; Wed, 17 Dec 2008 06:42:33 -0600 Received: from Debug (webmail-1.iastate.edu [129.186.140.21]) by despam-10.iastate.edu (8.14.2/8.12.10) with SMTP id mBHCp4Xg031046; Wed, 17 Dec 2008 06:51:04 -0600 To: From: "Lindsay Altmann" Subject: Proposal From China. Date: Wed, 17 Dec 2008 06:51:32 -0600 (CST) X-Mailer: Endymion MailMan Professional Edition v3.0.14 ISU Version mp9.11 Message-Id: <32516171110833510@webmail.iastate.edu> X-PMX-Version: 5.4.4.348488, Antispam-Engine: 2.6.0.325393, Antispam-Data: 2008.12.17.124020 X-ISUMailhub-test: Gauge=XXIIII, Probability=24%, Report='TO_EMPTY 2.199, HK_TLD 0.5, BODY_SIZE_2000_2999 0, BODY_SIZE_5000_LESS 0, ECARD_KNOWN_DOMAINS 0, FROM_EDU_TLD 0, __CP_NAME_BODY 0, __FRAUD_419_BODY_WEBMAIL 0, __FRAUD_419_CONTACT_ADDY_B 0, __FRAUD_419_INTRO 0, __FRAUD_419_MONEY 0, __FRAUD_419_MONEY_VALUE 0, __FRAUD_419_WEBMAIL 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __MIME_TEXT_ONLY 0, __PHISH_SPEAR_ACCOUNT_1 0, __PHISH_SPEAR_STRUCTURE_1 0, __PHISH_SPEAR_STRUCTURE_2 0, __SANE_MSGID 0' Hello, Let me introduce myself,my name is Mou Xinsheng Minister of General Administration of Customs of the Peoples Republic of China).I have a secured business proposal for you,which i believe will be beneficial to both of us i want to solicit your attention.The purpose of my contacting you is because you live outside China. Actually i got your contact during my discreet search for a reliable,successfull,business oriented partner.I feel it would be huge surprise for you to receive such email from a serving minister of the People's Republic of China.I will give you more information about myself and the business.My name is Mou Xinsheng (Minister of General Administration of Customs of the Peoples Republic of China). Forgive me if you see my business proposal as shameful and not honorable because of my governmental status. But please excuse me and understand that this is the situation I am and must find a credible partner outside China.In my years of government service as Narcotics Control Commission and General Administration of Customs, I have received kick backs from smugglers and business people seeking favors from me and as a public officer my bank accounts are monitored hence I diverted the funds Thirty million United States dollars for safe keeping abroad.I want you to receive the money which has been in deposit since the last Two years. When the money is in your bank account, I want to use Sixty Percent of the money for charity to help orphanage Children suffering (You will spare head this project and my name will not be mentioned).You will receive Twenty Percent as your commission and I will take the remaining Twenty Percent as my share which I intend to settle with outside China.Please consider this proposal and reply to me soon. It will certainly do you no good to report me to my government authorities or divulge this information to anybody because doing so will only destroy my person and my career. If you are interested in my proposal,please contact me on this email address: moux77917@yahoo.com.hk I will send you more information about myself and this proposal. Thank you. Mou Xinsheng. From lalvarezd@ama.gobierno.pr Wed Dec 17 05:52:05 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DAB43A6B1C for ; Wed, 17 Dec 2008 05:52:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -30.554 X-Spam-Level: X-Spam-Status: No, score=-30.554 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_RU=0.595, HOST_EQ_BROADBND=1.118, HOST_EQ_RU=0.875, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HTML_IMG_ONLY=1.666, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s0xF-QzClBO4 for ; Wed, 17 Dec 2008 05:51:57 -0800 (PST) Received: from 93-80-114-108.broadband.corbina.ru (93-80-114-108.broadband.corbina.ru [93.80.114.108]) by core3.amsl.com (Postfix) with SMTP id 751593A6AF4 for ; Wed, 17 Dec 2008 05:50:59 -0800 (PST) To: Subject: RE: We have found your lost message From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081217135100.751593A6AF4@core3.amsl.com> Date: Wed, 17 Dec 2008 05:50:59 -0800 (PST)
Go to site!
From jurgensen5@amada.com Wed Dec 17 11:35:01 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDBBE3A6B35 for ; Wed, 17 Dec 2008 11:35:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.127 X-Spam-Level: X-Spam-Status: No, score=-12.127 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_EQ_DSL=1.129, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, SARE_HTML_IMG_ONLY=1.666, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kPg2yht5pMvZ for ; Wed, 17 Dec 2008 11:34:55 -0800 (PST) Received: from icu242.internetdsl.tpnet.pl (icu242.internetdsl.tpnet.pl [79.189.72.242]) by core3.amsl.com (Postfix) with SMTP id 7E5F33A67A8 for ; Wed, 17 Dec 2008 11:34:46 -0800 (PST) To: Subject: We have found your lost message From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081217193449.7E5F33A67A8@core3.amsl.com> Date: Wed, 17 Dec 2008 11:34:46 -0800 (PST)
Go to site!
From owner-ccamp@ops.ietf.org Wed Dec 17 14:26:10 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A018A3A67BD for ; Wed, 17 Dec 2008 14:26:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.942 X-Spam-Level: X-Spam-Status: No, score=-0.942 tagged_above=-999 required=5 tests=[AWL=-0.448, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jVvSWdXSe30m for ; Wed, 17 Dec 2008 14:26:09 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B19803A6891 for ; Wed, 17 Dec 2008 14:26:09 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LD4jr-000EPc-7Y for ccamp-data0@psg.com; Wed, 17 Dec 2008 22:19:31 +0000 Received: from [62.128.201.248] (helo=asmtp1.iomartmail.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LD4jl-000EOa-SY for ccamp@ops.ietf.org; Wed, 17 Dec 2008 22:19:28 +0000 Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id mBHMJKEx008978 for ; Wed, 17 Dec 2008 22:19:22 GMT Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id mBHMJItU008972 for ; Wed, 17 Dec 2008 22:19:19 GMT Message-ID: Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Last of 4 drafts to OIF : inter-level routing Date: Wed, 17 Dec 2008 22:19:13 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Hi, A fourth and final draft for you to review... Thanks, Adrian === Dear Lyndon, Here is a final response to the issues raised by the OIF. This one relates to ASON routing and multi-layer networks, and comes from your communication oif2008.063.02.pdf. > in our discussions of multilayer networks and impacts > on the control plane, we took note of ITU-T Recommendation > G.7715.1 requirements to advertise: > a) Local Connection Type; and > b) Local Client Adaptations Supported. > We believe that this functionality would be very useful for > applications that have been discussed in OIF (see > attachment). We would appreciate further clarification as to > whether both requirements have been addressed in the current > CCAMP work on ASON routing support (local connection type in > particular is not explicitly identified in the current > draft). We would also appreciate more information on the > relationship between support of adaptation in the ASON > routing draft and in the multilayer/multiregion networking > drafts also being developed in the CCAMP WG. We note that G.7715.1 discusses the operation of multi-layer networks in an appendix and observes: This appendix provides illustrative examples of different methods of carrying multiple layer information between two systems. It does not mandate a particular method of implementation for link state routing protocols. From the perspective of ITU-T Rec. G.8080/Y.1304, each layer network has its own instance of a control plane. It can also be observed that a single routing level cannot span multiple network layers within the ASON architecture. draft-ietf-ccamp-gmpls-ason-routing-ospf-06.txt addresses the distribution of routing information between Routing Areas (in the ASON sense), but is agnostic to the routing information passed. For more details of the exchange of "local connection type" and "local client adaptations" we need to look into the base GMPLS routing specifications and the CCAMP work on multi- layer networks. As pointed out in RFC 4652, the Switching Capability field of the Interface Switching Capability Descriptor (see RFC 4202) describes the capabilities of the receiver with regard to any specific TE link (e.g., PSC, TDM, etc.). Your question also opens up the issue of distinguishing between what signal types an LSR can terminate (through adaptation) as distinct from switch (onto another TE link). This function is addressed in another CCAMP draft, draft-ietf-ccamp-gmpls-mln-extensions-03.txt, which will go to CCAMP working group last call soon. This draft introduces the Interface Adaptation Capability Descriptor (IACD) to carry the necessary information. Both the ISCD and the IACD can be exchanged between routing levels using the techniques described in draft-ietf-ccamp- gmpls-ason-routing-ospf-06.txt. You may, however, also like to look at the appropriateness of the PCE architecture (RFC 4655) in the role of inter-level routing as it seems to fit well with the architecture as described by the ITU-T in G.7715.2. Best regards, Adrian Farrel and Deborah Brungard IETF CCAMP Working Group Co-Chairs From ameachen@commsolution.com Wed Dec 17 15:57:11 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D13603A687F; Wed, 17 Dec 2008 15:57:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -56.344 X-Spam-Level: X-Spam-Status: No, score=-56.344 tagged_above=-999 required=5 tests=[BAYES_95=3, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_DYNAMIC_IPADDR2=4.395, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_EQ_IP_ADDR=1.119, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RCVD_NUMERIC_HELO=2.067, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, URIBL_BLACK=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aF762sLZYWjj; Wed, 17 Dec 2008 15:57:11 -0800 (PST) Received: from 93.102.95.184.rev.optimus.pt (93.102.95.184.rev.optimus.pt [93.102.95.184]) by core3.amsl.com (Postfix) with SMTP id ABE833A67BD; Wed, 17 Dec 2008 15:56:50 -0800 (PST) Message-ID: Date: Wed, 17 Dec 2008 18:56:48 -0500 From: "Luz Kirkland" Subject: Chopard better than original To: architecture-discuss@ietf.org Content-Type: text/plain Content-Transfer-Encoding: 7bit Hello Luz I had never seen such beautiful and greatly-performing watches like the ones I found online at http://www.domedome.com/ Take advantage of our christmas specials and get yourself Jaeger LeCoultre watch that you've always wanted! http://www.domedome.com/ Sincerely, Mr Kirkland From owner-ccamp@ops.ietf.org Wed Dec 17 16:16:13 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F32C3A6965 for ; Wed, 17 Dec 2008 16:16:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.525 X-Spam-Level: X-Spam-Status: No, score=-104.525 tagged_above=-999 required=5 tests=[AWL=-0.030, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Yf9YBy4BXFg for ; Wed, 17 Dec 2008 16:16:12 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8214C3A687F for ; Wed, 17 Dec 2008 16:16:12 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LD6U9-000MfQ-2i for ccamp-data0@psg.com; Thu, 18 Dec 2008 00:11:25 +0000 Received: from [216.82.241.147] (helo=mail146.messagelabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LD6U1-000MeT-Pf for ccamp@ops.ietf.org; Thu, 18 Dec 2008 00:11:21 +0000 X-VirusChecked: Checked X-Env-Sender: dbrungard@att.com X-Msg-Ref: server-2.tower-146.messagelabs.com!1229559074!9787441!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 29438 invoked from network); 18 Dec 2008 00:11:14 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-2.tower-146.messagelabs.com with AES256-SHA encrypted SMTP; 18 Dec 2008 00:11:14 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id mBI0BDKo011965 for ; Wed, 17 Dec 2008 19:11:13 -0500 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id mBI0BAkM011950 for ; Wed, 17 Dec 2008 19:11:11 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Working Group Last Call ends: draft-ietf-ccamp-path-key-ero-02.txt Date: Wed, 17 Dec 2008 19:11:09 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Working Group Last Call ends: draft-ietf-ccamp-path-key-ero-02.txt Thread-Index: AclLcSBkC9PN1RWSRrquCv8jL/wuaAVM4Rmg From: "BRUNGARD, DEBORAH A, ATTLABS" To: Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: This ends the Last Call. There were no comments. Thanks- Deborah _____________________________________________ From: BRUNGARD, DEBORAH A, ATTLABS=20 Sent: Thursday, November 20, 2008 7:36 PM To: 'ccamp@ops.ietf.org' Subject: Working Group Last Call: draft-ietf-ccamp-path-key-ero-02.txt This is to initiate a Working Group Last Call on: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-path-key-ero-02.txt Please send your comments to the mailing list prior to EOB Dec 5. Thanks, Deborah and Adrian From owner-ccamp@ops.ietf.org Thu Dec 18 02:25:49 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96E853A689F for ; Thu, 18 Dec 2008 02:25:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.013 X-Spam-Level: X-Spam-Status: No, score=0.013 tagged_above=-999 required=5 tests=[AWL=-1.352, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Zte8eHriRyQ for ; Thu, 18 Dec 2008 02:25:49 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 861383A6873 for ; Thu, 18 Dec 2008 02:25:48 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LDFyH-000A6u-7Q for ccamp-data0@psg.com; Thu, 18 Dec 2008 10:19:09 +0000 Received: from [62.128.201.248] (helo=asmtp1.iomartmail.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LDFy9-000A6I-62 for ccamp@ops.ietf.org; Thu, 18 Dec 2008 10:19:03 +0000 Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id mBIAIq9W009621; Thu, 18 Dec 2008 10:18:52 GMT Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id mBIAIp4O009599; Thu, 18 Dec 2008 10:18:52 GMT Message-ID: <722A4A56A60942F08F278CFA611E9ED8@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "Greg Bernstein" References: <2089B64D43144AEEA390F5C4C7232087@your029b8cecfe> <493E4E2E.2050600@pi.nu> Subject: draft-bernstein-ccamp-wson-encode accepted as WG I-D Date: Thu, 18 Dec 2008 10:18:17 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Hi, draft-bernstein-ccamp-wson-encode-01.txt is accepted as a working group draft. Authors, please resubmit as draft-ietf-ccamp-rwa-wson-encode-00.txt to indicate that the problem space you address is just the RWA portion of WSON. Thanks, Adrian From owner-ccamp@ops.ietf.org Thu Dec 18 02:37:06 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 764E63A68B5 for ; Thu, 18 Dec 2008 02:37:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.873 X-Spam-Level: X-Spam-Status: No, score=-0.873 tagged_above=-999 required=5 tests=[AWL=-0.379, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LJGKnLEFwM8p for ; Thu, 18 Dec 2008 02:37:05 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9E1C43A67B5 for ; Thu, 18 Dec 2008 02:37:05 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LDGAr-000BT6-NT for ccamp-data0@psg.com; Thu, 18 Dec 2008 10:32:09 +0000 Received: from [62.128.201.248] (helo=asmtp1.iomartmail.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LDGAn-000BSc-3F for ccamp@ops.ietf.org; Thu, 18 Dec 2008 10:32:07 +0000 Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id mBIAW2lw016627 for ; Thu, 18 Dec 2008 10:32:02 GMT Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id mBIAW2JZ016605 for ; Thu, 18 Dec 2008 10:32:02 GMT Message-ID: Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: References: <2089B64D43144AEEA390F5C4C7232087@your029b8cecfe> <493E4E2E.2050600@pi.nu> Subject: Accepting OAM Configuration I-Ds Date: Thu, 18 Dec 2008 10:31:54 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Hi, Deborah and I have listened to the discussion about accepting the two OAM configuration I-Ds (draft-takacs-ccamp-oam-configuration-fwk-01.txt and draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt) as working group drafts. We see reasonable consensus for adoption, but are aware that several people expressed a concern that this work would deprecate LSP Ping as a bootstrap mechanism for OAM in certain environments. We believe that it is not the authors' intention to deprecate the use of LSP Ping in this way, and that it would not be wise to make such a change. Therefore, we accept these two I-Ds as working group drafts, but request the authors to add to draft-takacs-ccamp-oam-configuration-fwk-01.txt to say: The mechansim described in this document provides an additional option for bootstrapping OAM that is not intended to replace or deprecate the use of other OAM bootstrapping techniques such as LSP Ping [RFC4379]. The procedures specified in this document are intended only for use in environments where RSVP-TE signaling is already in use to set up the LSPs that are to be monitored using OAM. We believe that this text goes some way to address the concerns raised and we note that the draft will be the property of the working group allowing additional changes to be made according to working group consensus. Authors, please make the textual change and submit draft-takacs-ccamp-oam-configuration-fwk-01.txt as draft-ietf-ccamp-oam-configuration-fwk-00.txt and draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt as draft-ietf-ccamp-rsvp-te-eth-oam-ext-00.txt Thanks, Adrian and Deborah From owner-ccamp@ops.ietf.org Thu Dec 18 06:47:41 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8373128C218 for ; Thu, 18 Dec 2008 06:47:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.698 X-Spam-Level: X-Spam-Status: No, score=-4.698 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id irhfq1JWbuGI for ; Thu, 18 Dec 2008 06:47:40 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 35C823A681C for ; Thu, 18 Dec 2008 06:47:39 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LDK3b-0003iw-UV for ccamp-data0@psg.com; Thu, 18 Dec 2008 14:40:55 +0000 Received: from [193.180.251.62] (helo=mailgw4.ericsson.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LDK3W-0003iJ-97 for ccamp@ops.ietf.org; Thu, 18 Dec 2008 14:40:53 +0000 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 1A0AB207B9; Thu, 18 Dec 2008 15:40:48 +0100 (CET) X-AuditID: c1b4fb3e-ac781bb00000537b-fa-494a60e7ab85 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id E6C4021021; Thu, 18 Dec 2008 15:40:39 +0100 (CET) Received: from esealmw116.eemea.ericsson.se ([153.88.200.7]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 Dec 2008 15:40:38 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: Accepting OAM Configuration I-Ds Date: Thu, 18 Dec 2008 15:40:36 +0100 Message-ID: <53CCFDD6E346CB43994852666C210E9105DC41A8@esealmw116.eemea.ericsson.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Accepting OAM Configuration I-Ds thread-index: Aclg/IfD41CeG/WRTpGetj24ciG71QAHccOg References: <2089B64D43144AEEA390F5C4C7232087@your029b8cecfe> <493E4E2E.2050600@pi.nu> From: "Attila Takacs" To: "Adrian Farrel" , X-OriginalArrivalTime: 18 Dec 2008 14:40:38.0192 (UTC) FILETIME=[97E30300:01C9611E] X-Brightmail-Tracker: AAAAAA== Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Hi Adrian, > We see reasonable consensus for adoption, but are aware that=20 > several people expressed a concern that this work would=20 > deprecate LSP Ping as a bootstrap mechanism for OAM in=20 > certain environments. >=20 > We believe that it is not the authors' intention to deprecate=20 > the use of LSP Ping in this way, and that it would not be=20 > wise to make such a change. >=20 Agreed. > Therefore, we accept these two I-Ds as working group drafts,=20 > but request the authors to add to=20 > draft-takacs-ccamp-oam-configuration-fwk-01.txt to say: >=20 > The mechansim described in this document provides an=20 > additional option for bootstrapping OAM that is not intended=20 > to replace or deprecate the use of other OAM bootstrapping=20 > techniques such as LSP Ping [RFC4379]. The procedures=20 > specified in this document are intended only for use in=20 > environments where RSVP-TE signaling is already in use to set=20 > up the LSPs that are to be monitored using OAM. >=20 Will add the note and resubmit. Thanks and best regards, Attila > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel > Sent: Thursday, December 18, 2008 11:32 AM > To: ccamp@ops.ietf.org > Subject: Accepting OAM Configuration I-Ds >=20 > Hi, >=20 > Deborah and I have listened to the discussion about accepting=20 > the two OAM configuration I-Ds=20 > (draft-takacs-ccamp-oam-configuration-fwk-01.txt and > draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt) as working=20 > group drafts. >=20 > We see reasonable consensus for adoption, but are aware that=20 > several people expressed a concern that this work would=20 > deprecate LSP Ping as a bootstrap mechanism for OAM in=20 > certain environments. >=20 > We believe that it is not the authors' intention to deprecate=20 > the use of LSP Ping in this way, and that it would not be=20 > wise to make such a change. >=20 > Therefore, we accept these two I-Ds as working group drafts,=20 > but request the authors to add to=20 > draft-takacs-ccamp-oam-configuration-fwk-01.txt to say: >=20 > The mechansim described in this document provides an=20 > additional option for bootstrapping OAM that is not intended=20 > to replace or deprecate the use of other OAM bootstrapping=20 > techniques such as LSP Ping [RFC4379]. The procedures=20 > specified in this document are intended only for use in=20 > environments where RSVP-TE signaling is already in use to set=20 > up the LSPs that are to be monitored using OAM. >=20 >=20 > We believe that this text goes some way to address the=20 > concerns raised and we note that the draft will be the=20 > property of the working group allowing additional changes to=20 > be made according to working group consensus. >=20 >=20 > Authors, please make the textual change and submit >=20 > draft-takacs-ccamp-oam-configuration-fwk-01.txt > as > draft-ietf-ccamp-oam-configuration-fwk-00.txt >=20 > and > draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt > as > draft-ietf-ccamp-rsvp-te-eth-oam-ext-00.txt >=20 >=20 > Thanks, > Adrian and Deborah=20 >=20 >=20 >=20 From accounts@caverock.net.nz Thu Dec 18 08:21:40 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F19A83A6955; Thu, 18 Dec 2008 08:21:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.735 X-Spam-Level: ** X-Spam-Status: No, score=2.735 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_EQ_DSL=1.129, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SBL=20, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cyPS-xw6TuXq; Thu, 18 Dec 2008 08:21:39 -0800 (PST) Received: from addo214.neoplus.adsl.tpnet.pl (addo214.neoplus.adsl.tpnet.pl [79.184.66.214]) by core3.amsl.com (Postfix) with SMTP id 71F063A691E; Thu, 18 Dec 2008 08:21:22 -0800 (PST) Message-ID: Date: Thu, 18 Dec 2008 11:21:13 -0500 From: "Wiley Bowden" Subject: Christmas Franck Muller watches bargain To: atompub-archive@megatron.ietf.org Content-Type: text/plain Content-Transfer-Encoding: 7bit Hello Wiley Christmas is the time to get IWC watch, and the only place to get top notch watches that look and perform exactly like the originals is http://www.watchlast.com/ Take an extra 15% off your purchase during month of December. http://www.watchlast.com/ Sincerely, Mr Bowden From owner-ccamp@ops.ietf.org Thu Dec 18 08:57:43 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3779F3A685D for ; Thu, 18 Dec 2008 08:57:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XaTb2yO8tqK5 for ; Thu, 18 Dec 2008 08:57:42 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 54C3E3A67A8 for ; Thu, 18 Dec 2008 08:57:42 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LDM77-000EGL-Be for ccamp-data0@psg.com; Thu, 18 Dec 2008 16:52:41 +0000 Received: from [206.16.17.180] (helo=usaga04-in.huawei.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LDM6v-000EFE-Rm for ccamp@ops.ietf.org; Thu, 18 Dec 2008 16:52:36 +0000 Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KC3003G007EBM@usaga04-in.huawei.com> for ccamp@ops.ietf.org; Thu, 18 Dec 2008 10:52:27 -0600 (CST) Received: from L73682 ([10.124.12.74]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KC300G4V079F4@usaga04-in.huawei.com> for ccamp@ops.ietf.org; Thu, 18 Dec 2008 10:52:26 -0600 (CST) Date: Thu, 18 Dec 2008 10:52:21 -0600 From: Young Lee Subject: RE: draft-bernstein-ccamp-wson-encode accepted as WG I-D In-reply-to: <722A4A56A60942F08F278CFA611E9ED8@your029b8cecfe> To: 'Adrian Farrel' , ccamp@ops.ietf.org Cc: 'Greg Bernstein' Message-id: <004a01c96130$ffbd2480$4a0c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Aclg+oGlDvWPP7uWQHGD6/7rE+XLOAANlc9A References: <2089B64D43144AEEA390F5C4C7232087@your029b8cecfe> <493E4E2E.2050600@pi.nu> <722A4A56A60942F08F278CFA611E9ED8@your029b8cecfe> Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: We will submit the update with the clear scope spelled out. Thanks. Young -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel Sent: Thursday, December 18, 2008 4:18 AM To: ccamp@ops.ietf.org Cc: Greg Bernstein Subject: draft-bernstein-ccamp-wson-encode accepted as WG I-D Hi, draft-bernstein-ccamp-wson-encode-01.txt is accepted as a working group draft. Authors, please resubmit as draft-ietf-ccamp-rwa-wson-encode-00.txt to indicate that the problem space you address is just the RWA portion of WSON. Thanks, Adrian From owner-ccamp@ops.ietf.org Thu Dec 18 09:03:32 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A43FF3A67F0 for ; Thu, 18 Dec 2008 09:03:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.242 X-Spam-Level: X-Spam-Status: No, score=-102.242 tagged_above=-999 required=5 tests=[AWL=0.358, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AambI7jM4lFa for ; Thu, 18 Dec 2008 09:03:30 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 223923A6778 for ; Thu, 18 Dec 2008 09:03:29 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LDMED-000En6-FX for ccamp-data0@psg.com; Thu, 18 Dec 2008 17:00:01 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LDME7-000Emi-JB for ccamp@ops.ietf.org; Thu, 18 Dec 2008 16:59:58 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id DD43D3A69D6; Thu, 18 Dec 2008 09:00:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org Subject: I-D Action:draft-ietf-ccamp-rwa-wson-encode-00.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081218170001.DD43D3A69D6@core3.amsl.com> Date: Thu, 18 Dec 2008 09:00:01 -0800 (PST) Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: --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 : Routing and Wavelength Assignment Information Encoding for Wavelength Switched Optical Networks Author(s) : G. Bernstein Filename : draft-ietf-ccamp-rwa-wson-encode-00.txt Pages : 21 Date : 2008-12-18 A wavelength switched optical network (WSON) requires that certain key information elements are made available to facilitate path computation and the establishment of label switching paths (LSPs). The information model described in "Routing and Wavelength Assignment Information for Wavelength Switched Optical Networks" shows what information is required at specific points in the WSON. The information may be used in Generalized Multiprotocol Label Switching (GMPLS) signaling protocols, and may be distributed by GMSPL routing protocols. Other distribution mechanisms (for example, XML-based protocols) may also be used. This document provides efficient, protocol-agnostic encodings for the information elements necessary to operate a WSON. It is intended that protocol-specific documents will reference this memo to describe how information is carried for specific uses. 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 [RFC2119]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rwa-wson-encode-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-ccamp-rwa-wson-encode-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-12-18085918.I-D@ietf.org> --NextPart-- From owner-ccamp@ops.ietf.org Thu Dec 18 09:19:57 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCFAB3A69E9 for ; Thu, 18 Dec 2008 09:19:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[AWL=0.351, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oULtAqPik-A7 for ; Thu, 18 Dec 2008 09:19:57 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F1CF53A6778 for ; Thu, 18 Dec 2008 09:19:56 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LDMSi-000GGO-EI for ccamp-data0@psg.com; Thu, 18 Dec 2008 17:15:00 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LDMSd-000GFp-A9 for ccamp@ops.ietf.org; Thu, 18 Dec 2008 17:14:57 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id B160B3A6B86; Thu, 18 Dec 2008 09:15:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org Subject: I-D Action:draft-ietf-ccamp-gmpls-vcat-lcas-07.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081218171501.B160B3A6B86@core3.amsl.com> Date: Thu, 18 Dec 2008 09:15:01 -0800 (PST) Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: --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 : draft-ietf-ccamp-gmpls-vcat-lcas-07.txt Author(s) : G. Bernstein, et al. Filename : draft-ietf-ccamp-gmpls-vcat-lcas-07.txt Pages : 21 Date : 2008-12-18 This document describes requirements for, and use of, the Generalized Multi-Protocol Label Switching (GMPLS) control plane in conjunction with the Virtual Concatenation (VCAT) layer 1 inverse multiplexing mechanism and its companion Link Capacity Adjustment Scheme (LCAS) which can be used for hitless dynamic resizing of the inverse multiplex group. These techniques apply to Optical Transport Network (OTN), Synchronous Optical Network (SONET), Synchronous Digital Hierarchy (SDH), and Plesiochronous Digital Hierarchy (PDH) signals. 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 [RFC2119]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-vcat-lcas-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-ccamp-gmpls-vcat-lcas-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-12-18090242.I-D@ietf.org> --NextPart-- From minique.desjardins@ahmbuckingham.com Thu Dec 18 12:55:49 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CBCA3A6AB7 for ; Thu, 18 Dec 2008 12:55:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -34.033 X-Spam-Level: X-Spam-Status: No, score=-34.033 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_VERIZON_P=2.144, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_VERIZON_POOL=1.495, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HTML_IMG_ONLY=1.666, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tFzxLO6cZVYp for ; Thu, 18 Dec 2008 12:55:48 -0800 (PST) Received: from pool-71-253-253-11.nrflva.east.verizon.net (pool-71-253-253-11.nrflva.east.verizon.net [71.253.253.11]) by core3.amsl.com (Postfix) with SMTP id C5FC93A685C for ; Thu, 18 Dec 2008 12:55:47 -0800 (PST) To: Subject: Make your boner your pride From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081218205547.C5FC93A685C@core3.amsl.com> Date: Thu, 18 Dec 2008 12:55:47 -0800 (PST)
Click now!
From javaidabel@accordhr.com Fri Dec 19 06:59:36 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B58BF3A6A05 for ; Fri, 19 Dec 2008 06:59:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.908 X-Spam-Level: X-Spam-Status: No, score=-11.908 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_DYNAMIC_IPADDR2=4.395, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_EQ_IP_ADDR=1.119, HTML_MESSAGE=0.001, MANGLED_OFF=2.3, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, RCVD_NUMERIC_HELO=2.067, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S9VbQNoo-qsM for ; Fri, 19 Dec 2008 06:59:36 -0800 (PST) Received: from 98.85.60.190.host.ifxnetworks.com (98.85.60.190.host.ifxnetworks.com [190.60.85.98]) by core3.amsl.com (Postfix) with SMTP id E9B5D3A6911 for ; Fri, 19 Dec 2008 06:59:34 -0800 (PST) To: Subject: Dear ccamp-archive, Dec 80% 0FF From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081219145934.E9B5D3A6911@core3.amsl.com> Date: Fri, 19 Dec 2008 06:59:34 -0800 (PST) Dear Customer!
Lovers package at discount price!
Discount price store: ID 46812
http://advocacynature.com/

Pfizer is a licensee of the TRUSTe Privacy Program.
© 2001-2008 Pfizer Inc. All rights reserved. From l.bjerkness277@acetateproducts.com Fri Dec 19 09:29:33 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AF2E3A696F for ; Fri, 19 Dec 2008 09:29:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.235 X-Spam-Level: X-Spam-Status: No, score=-13.235 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_RCVD_IP=1.931, TVD_SPACE_RATIO=2.219, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pyFx7XKXo8vl for ; Fri, 19 Dec 2008 09:29:33 -0800 (PST) Received: from 213-140-16-191.fastres.net (213-140-16-191.fastres.net [213.140.16.191]) by core3.amsl.com (Postfix) with SMTP id 085B03A6886 for ; Fri, 19 Dec 2008 09:29:30 -0800 (PST) To: Subject: Lost my number? ) From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081219172932.085B03A6886@core3.amsl.com> Date: Fri, 19 Dec 2008 09:29:30 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From jurgen.blankenburg@afs.org Sat Dec 20 12:35:19 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CC023A695E for ; Sat, 20 Dec 2008 12:35:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -43.673 X-Spam-Level: X-Spam-Status: No, score=-43.673 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Uz5CYQdsHFj for ; Sat, 20 Dec 2008 12:35:18 -0800 (PST) Received: from 123bill.com (unknown [217.129.244.204]) by core3.amsl.com (Postfix) with SMTP id 5BCB53A68AA for ; Sat, 20 Dec 2008 12:35:16 -0800 (PST) To: Subject: Never lose hope to recover From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081220203517.5BCB53A68AA@core3.amsl.com> Date: Sat, 20 Dec 2008 12:35:16 -0800 (PST) Visit us today and you won't stay without treatment you need to help you live a healthier life! From lsikora@amrest.com.pl Sun Dec 21 06:09:24 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D251E3A682F for ; Sun, 21 Dec 2008 06:09:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.22 X-Spam-Level: X-Spam-Status: No, score=-13.22 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z43tyAMjCjkg for ; Sun, 21 Dec 2008 06:09:24 -0800 (PST) Received: from 202-142-131-67.cust.wide.net.au (202-142-131-67.cust.wide.net.au [202.142.131.67]) by core3.amsl.com (Postfix) with SMTP id BA88B3A67C0 for ; Sun, 21 Dec 2008 06:09:21 -0800 (PST) To: Subject: Get filled with health and gladness! From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081221140922.BA88B3A67C0@core3.amsl.com> Date: Sun, 21 Dec 2008 06:09:21 -0800 (PST) Improve the quality of your life with the help of our specially priced products! From owner-ccamp@ops.ietf.org Mon Dec 22 14:05:56 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE1073A6A66 for ; Mon, 22 Dec 2008 14:05:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.008 X-Spam-Level: X-Spam-Status: No, score=-104.008 tagged_above=-999 required=5 tests=[AWL=2.591, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uAqRvwipyWji for ; Mon, 22 Dec 2008 14:05:55 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id AB4443A68AD for ; Mon, 22 Dec 2008 14:05:55 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LEspS-000CEo-0Y for ccamp-data0@psg.com; Mon, 22 Dec 2008 22:00:46 +0000 Received: from [62.128.201.249] (helo=asmtp2.iomartmail.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LEspK-000CDo-O4 for ccamp@ops.ietf.org; Mon, 22 Dec 2008 22:00:41 +0000 Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id mBMLxX7e012531; Mon, 22 Dec 2008 21:59:33 GMT Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id mBMLxUCb012510; Mon, 22 Dec 2008 21:59:32 GMT Message-ID: <852E2CC78CA84E69891E7E5ECA480F0C@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Lyndon Ong" , "Lucille Goldiner" Cc: "Brungard, Deborah A, ALABS" , Subject: IETF CCAMP Response to OIF on VCAT Date: Mon, 22 Dec 2008 21:57:07 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Dear Lyndon, In your communication oif2007.377.02.pdf you made several comments about our VCAT/LCAS work, but did not specifically request any response. In communication oif2008.063.02.pdf you said: > We would also appreciate any feedback that you might have on > our liaison from the 4Q2007 meeting on VCAT/LCAS requirements, > especially whether these were incorporated into your work on VCAT/LCAS > support. This response addresses the points you made in the earlier communication. You wrote: > We have been monitoring with great interest the work on > VCAT/LCAS support in the IETF CCAMP WG, as we have done > prototyping work on control of VCAT/LCAS for interoperability > events in 2005 and 2007. As a result of our internal > discussion and prototyping work, we have identified a number > of requirements on VCAT/LCAS support that we believe are > important and may be helpful input to your work. > > In general, we agree with the requirements already identified > in draft-ietf-ccamp-gmpls-vcat-lcas-03.txt. Please note that this draft is now at the 07 revision and may be found as draft-ietf-ccamp-gmpls-vcat-lcas-07.txt > The following have been identified as important functionality > for control plane support for VCAT/LCAS that is not currently > identified in the CCAMP draft: > > - Ability to identify link endpoint capabilities associated with VCAT such > as support of LCAS functionality > - Possible additional requirement on ASON routing support to be taken > into account in CCAMP work on ASON routing > extensions rather than the VCAT/LCAS draft itself > - This might be generalizable to advertising inverse multiplexing > capabilities in addition to VCAT/LCAS CCAMP did consider extensions to IGPs to distribute inverse multiplexing, VCAT, and LCAS capabilities. This information would allow the initiator of a VCG to understand the capabilities of the egress that it is attempting to connect to. However, we decided that the LSP will not be set up to a different destination based on the VCAT capabilities. The LSP is required between a pair of LSRs, and there is no benefit to routing in distributing the end-point capabilities. Thus, we decided that if any negotiation is needed, it should be performed on the Call. > - Clean separation of VCG (VCAT Group) control from the > control of VCG members > - Supports the ability to create and modify the VCG independent of its > members We believe that this is exactly what our draft does. > - Supports potentially different sequences of creation, e.g., creation > of members first followed by VCG creation > or creation of VCG first followed by its members We believe that the ITU Recommendations that define VCAT do not support this behavior. We are also not convinced that this would be a valid way of operating a network - trails are not created on the off-chance that they will be used as part of a VCG at some time in the future. > - A single separate signaling session associated with the > VCG is an approach that has been prototyped successfully > in OIF interop events and may be a possible approach. While the use of a separate signaling session to establish the VCG is a fine way to conduct an experiment to establish data plane interoperability, this is not a good architectural solution for RSVP-TE. The signaling exchange of an RSVP-TE Path and Resv message is intended to establish an LSP. The coordination between end points for VCAT is far closer to the processes necessary for a Call, and that is why we have used the RSVP-TE Notify message exchange in our draft. > - We believe the current approach in the CCAMP draft has > limitations in this respect due to the incorporation of multiple VCGs > within a single call, as this does not cleanly separate the VCG state and > the state of its component members. We suggest that CCAMP consider using a > single call per VCG instead, based on our prototyping > experiences. This may reflect some misunderstanding of the CCAMP draft. The draft currently allows a one-to-one correlation between Call and VCG. Component members are, of course, associated with the VCG and so the state of the component members is directly associated with the state of the VCG itself. > - Separation of VCG and member sessions will allow unambiguous semantics > for VCG characteristics vs. member > characteristics such as support of recovery modes Again, this may represent some misunderstanding of the CCAMP draft. The draft allows each LSP (VCG member) to be maintained with distinct characteristics. > - Ability to identify VCG members within VCG-related signaling > - Note that it may be common in ASON environments for a VCG > connection to span multiple domains and RSVP sessions in series, in > which case session-specific objects such as > the LSP ID and Tunnel ID are not guaranteed to have > unique values end-to-end > - Manipulation of VCG characteristics requires the ability to clearly > and unambiguously identify the VCG members at each end of the VCG We note that "session shuffling" is peculiar to the OIF way of addressing the ASON architecture, and the CCAMP working group has previously expressed its view that such a way of building a network, while functional, is not advisable. Since the OIF presumably has a solution to the fact that any one connection must be unambiguously identifiable at each end of the connection, we do not consider that the problem is exacerbated by the construction of a VCG. Indeed, session shuffling can only work if there is a consistent, coherent, repeatable, and reversible mapping of the various parameters (such as addresses, Tunnel ID, and LSP ID) at domain boundaries. > - Ability to maintain VCG state across control plane failures > - It is important to be able to maintain the VCG in the > event of temporary loss of control plane connectivity or control plane > state > - We believe that graceful restart-like capabilities in RSVP need to be > supported to maintain VCG state across control plane failure. You are correct that the control plane state must be recoverable after control plane component restart, and must be resynchronized after control plane connectivity recovery. Further, the data plane state must not be perturbed by control plane failure or restart. Graceful restart is a standard part of GMPLS RSVP-TE. It can be found in RFC 5063. A more detailed description (including a discussion of the handling of multiple failures) can be found in draft-ietf-ccamp-gr-description-03.txt which is currently being reviewed by the IESG prior to publication as an RFC. Restart processing for GMPLS Calls is covered in RFC 4974. The VCAT work simply re-uses these mechanisms and no further description is required. Regards, Adrian Farrel and Deborah Brungard IETF CCAMP Working Group Co-Chairs From owner-ccamp@ops.ietf.org Mon Dec 22 14:05:57 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F7B43A68AD for ; Mon, 22 Dec 2008 14:05:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.016 X-Spam-Level: X-Spam-Status: No, score=-1.016 tagged_above=-999 required=5 tests=[AWL=-0.521, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yTrTbpF3eWJO for ; Mon, 22 Dec 2008 14:05:56 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3C7653A6A32 for ; Mon, 22 Dec 2008 14:05:56 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LEsoq-000CBt-I6 for ccamp-data0@psg.com; Mon, 22 Dec 2008 22:00:08 +0000 Received: from [62.128.201.249] (helo=asmtp2.iomartmail.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LEsok-000CB2-IQ for ccamp@ops.ietf.org; Mon, 22 Dec 2008 22:00:05 +0000 Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id mBMLxV0n012516; Mon, 22 Dec 2008 21:59:32 GMT Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id mBMLxUCX012510; Mon, 22 Dec 2008 21:59:31 GMT Message-ID: <91CC78DEFAEC46F7891364F806AF2113@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Lyndon Ong" , "Lucille Goldiner" Cc: "Brungard, Deborah A, ALABS" , Subject: IETF CCAMP Response to OIF on Resv Usage Date: Mon, 22 Dec 2008 21:49:36 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Dear Lyndon, CCAMP owes the OIF responses to several communications. Apologies for the delay in producing formal responses. The issues raised were discussed at some length during the months after we received the communication both on and off the CCAMP mailing list, and I know you were involved in some of those discussions, but we forgot to send the formal responses. We will generate a series of responses with the technical issues broken out into separate threads. This first one addresses the issue of Resv usage during make-before-break as raised in oif2008.063.02.pdf. Best regards, Adrian Farrel and Deborah Brungard IETF CCAMP Working Group Co-chairs --- > OIF thanks CCAMP for its prompt and very informative response > to our liaison on OIF interoperability demo findings, sent > from our 4Q2007 meeting. We appreciate CCAMP's offer to use > the CCAMP mailing list for questions during our demo planning > and testing, although more structured liaisons are still > useful in our view to reflect meeting results and issues or > comments that are agreed across OIF members (as opposed to > individual views). [SNIP] > Based on your response liaison, it is our understanding that > per-LSP RESV messages should be expected for the "make- > before-break" scenario of modification. However, some members > have commented that it appears to be possible in the > specifications to use a single RESV message for multiple LSPs > because: > a) RFC 2205 allows the RESV message to carry multiple > FILTER_SPEC objects, specifically with the Shared Explicit > (SE) style that supports reservation sharing; and > b) The FILTER_SPEC object was extended in RFC 3209 to carry > the LSP_ID. > > Clarification would be appreciated as to whether we should > allow for receiving a single RESV message with multiple > FILTER_SPEC objects in the "make-before-break" scenario using > the SE style. We believe this issue is substantially the same as the following issue raised in the OIF correspondence dated November 29, 2007 with the subject "Liaison to IETF Regarding 2007 Interop Test Findings". Here you wrote: >> - 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 our response, dated January 3, 2008, we stated: >> 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. To help clarify this point, we draw your attention to RFC 3209 which states: The SESSION object uniquely defines a traffic engineered tunnel. The SENDER_TEMPLATE and FILTER_SPEC objects carry an LSP ID. The SENDER_TEMPLATE (or FILTER_SPEC) object together with the SESSION object uniquely identifies an LSP tunnel. As LSP tunnels (or LSPs for short) are identified using different LSP IDs (as carried in SENDER_TEMPLATE and FILTER_SPEC objects) and each LSP is signaled independently, multiple FILTER_SPEC objects SHOULD NOT be allowed as part of make-before-break. From owner-ccamp@ops.ietf.org Mon Dec 22 14:06:03 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1837E3A68AD for ; Mon, 22 Dec 2008 14:06:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.004 X-Spam-Level: X-Spam-Status: No, score=-1.004 tagged_above=-999 required=5 tests=[AWL=-0.509, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hDF1P4zWR-QV for ; Mon, 22 Dec 2008 14:06:02 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2E3203A6868 for ; Mon, 22 Dec 2008 14:06:02 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LEsp5-000CD3-If for ccamp-data0@psg.com; Mon, 22 Dec 2008 22:00:23 +0000 Received: from [62.128.201.249] (helo=asmtp2.iomartmail.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LEsow-000CCF-Io for ccamp@ops.ietf.org; Mon, 22 Dec 2008 22:00:21 +0000 Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id mBMLxW2k012521; Mon, 22 Dec 2008 21:59:32 GMT Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id mBMLxUCZ012510; Mon, 22 Dec 2008 21:59:32 GMT Message-ID: Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Lyndon Ong" , "Lucille Goldiner" Cc: "Brungard, Deborah A, ALABS" , Subject: IETF CCAMP Response to OIF on MEF-Related Work Date: Mon, 22 Dec 2008 21:51:25 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Dear Lyndon, In your communication oif2008.063.02.pdf dated February 14, 2008 you noted: > Finally, we noted the discussion on the CCAMP mailing list > regarding the computation of the Length field for TLVs, especially for the > Ethernet Bandwidth Profile TLV used in > the Ethernet Traffic Parameters draft. As this draft is considered to be > very important for support of MEF defined > Ethernet services, we request that this issue be resolved > as soon as possible within CCAMP. > Our preference would be to compute the Length field for all > TLVs (except those in RFC 4420) based on the full TLV rather > than the Value alone, as this is the method commonly used in > the past for length computation in RSVP. Please note that RFC 4420 has been revised as draft-ietf-ccamp-rfc4420-bis-03.txt. This draft is in the RFC Editor's queue, and will shortly be published as an RFC that obsoletes RFC 4420. The change is to make the processing of all RSVP-TE TLVs consistent so that the Length field accounts for the full length of the TLV. This change has also been incorporated into the work on traffic parameters for Ethernet as described in draft-ietf-ccamp-ethernet-traffic-parameters-06.txt. You will be pleased to hear that we consider our work on MEF-related protocol extensions to be stable, and we will shortly issue working group last calls on the following drafts: draft-ietf-ccamp-ethernet-traffic-parameters-06.txt draft-ietf-ccamp-gmpls-ether-svcs-02.txt draft-ietf-ccamp-gmpls-mef-uni-01.txt draft-ietf-ccamp-gmpls-dcsc-channel-ext-00.txt In view of the imminent last call on this work, we would welcome any input from OIF members. Input should be made either by official communication from the OIF, or by email from any individual to the CCAMP mailing list (subscription details are found at http://www.ietf.org/html.charters/ccamp-charter.html). Best regards, Adrian Farrel and Deborah Brungard IETF CCAMP Working Group Co-Chairs From owner-ccamp@ops.ietf.org Mon Dec 22 14:06:07 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A94C3A68AD for ; Mon, 22 Dec 2008 14:06:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.993 X-Spam-Level: X-Spam-Status: No, score=-0.993 tagged_above=-999 required=5 tests=[AWL=-0.498, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jcmKlQShk2c6 for ; Mon, 22 Dec 2008 14:06:06 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 62F073A6868 for ; Mon, 22 Dec 2008 14:06:06 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LEsoi-000CAy-Ur for ccamp-data0@psg.com; Mon, 22 Dec 2008 22:00:00 +0000 Received: from [62.128.201.249] (helo=asmtp2.iomartmail.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LEsod-000CAH-B4 for ccamp@ops.ietf.org; Mon, 22 Dec 2008 21:59:57 +0000 Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id mBMLxX72012539; Mon, 22 Dec 2008 21:59:33 GMT Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id mBMLxUCd012510; Mon, 22 Dec 2008 21:59:33 GMT Message-ID: <490D9EAB351A4F29A0710BC8A02DE864@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Lyndon Ong" , "Lucille Goldiner" Cc: "Brungard, Deborah A, ALABS" , Subject: IETF CCAMP Respons to OIF on Inter-Level Routing Date: Mon, 22 Dec 2008 21:59:24 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Dear Lyndon, Here is a final response to the issues raised by the OIF. This one relates to ASON routing and multi-layer networks, and comes from your communication oif2008.063.02.pdf. > in our discussions of multilayer networks and impacts on the control > plane, we took note of ITU-T Recommendation > G.7715.1 requirements to advertise: > a) Local Connection Type; and > b) Local Client Adaptations Supported. > We believe that this functionality would be very useful for > applications that have been discussed in OIF (see > attachment). We would appreciate further clarification as to > whether both requirements have been addressed in the current > CCAMP work on ASON routing support (local connection type in > particular is not explicitly identified in the current draft). We would > also appreciate more information on the > relationship between support of adaptation in the ASON routing draft and > in the multilayer/multiregion networking > drafts also being developed in the CCAMP WG. We note that G.7715.1 discusses the operation of multi-layer networks in an appendix and observes: This appendix provides illustrative examples of different methods of carrying multiple layer information between two systems. It does not mandate a particular method of implementation for link state routing protocols. From the perspective of ITU-T Rec. G.8080/Y.1304, each layer network has its own instance of a control plane. It can also be observed that a single routing level cannot span multiple network layers within the ASON architecture. draft-ietf-ccamp-gmpls-ason-routing-ospf-06.txt addresses the distribution of routing information between Routing Areas (in the ASON sense), but is agnostic to the routing information passed. For more details of the exchange of "local connection type" and "local client adaptations" we need to look into the base GMPLS routing specifications and the CCAMP work on multi-layer networks. As pointed out in RFC 4652, the Switching Capability field of the Interface Switching Capability Descriptor (see RFC 4202) describes the capabilities of the receiver with regard to any specific TE link (e.g., PSC, TDM, etc.). Your question also opens up the issue of distinguishing between what signal types an LSR can terminate (through adaptation) as distinct from switch (onto another TE link). This function is addressed in another CCAMP draft, draft-ietf-ccamp-gmpls-mln-extensions-03.txt, which will go to CCAMP working group last call soon. This draft introduces the Interface Adaptation Capability Descriptor (IACD) to carry the necessary information. Both the ISCD and the IACD can be exchanged between routing levels using the techniques described in draft-ietf-ccamp-gmpls-ason-routing-ospf-06.txt. You may, however, also like to look at the appropriateness of the PCE architecture (RFC 4655) in the role of inter-level routing as it seems to fit well with the architecture as described by the ITU-T in G.7715.2. Best regards, Adrian Farrel and Deborah Brungard IETF CCAMP Working Group Co-Chairs From owner-ccamp@ops.ietf.org Tue Dec 23 03:35:35 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A74163A6AF6 for ; Tue, 23 Dec 2008 03:35:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V3M8dPnjzF6k for ; Tue, 23 Dec 2008 03:35:34 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A83633A6834 for ; Tue, 23 Dec 2008 03:35:34 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LF5Rp-0008Xk-0m for ccamp-data0@psg.com; Tue, 23 Dec 2008 11:29:13 +0000 Received: from [147.234.242.117] (helo=eci-iron1.ecitele.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LF5Rf-0008X3-Vn for ccamp@ops.ietf.org; Tue, 23 Dec 2008 11:29:10 +0000 Received: from ilptexfe.ecitele.com (HELO ilptexch01.ecitele.com) ([172.31.244.40]) by eci-iron1-out.ecitele.com with ESMTP; 23 Dec 2008 13:49:09 +0200 Received: from ILPTMAIL02.ecitele.com ([147.234.244.212]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Tue, 23 Dec 2008 13:28:52 +0200 From: Yechiel Rosengarten To: "danli@huawei.com" , "gjhhit@huawei.com" , "asatyana@cisco.com" CC: "ccamp@ops.ietf.org" Date: Tue, 23 Dec 2008 13:28:46 +0200 Subject: RE: I-D ACTION:draft-ietf-ccamp-gr-description-03.txt Thread-Topic: I-D ACTION:draft-ietf-ccamp-gr-description-03.txt Thread-Index: Aci5znz+u2xxeM60RmyR3fLjaArEpyrIc99A Message-ID: <93BC09B2B8795C49B4E3453CE6A45A18894C496ECB@ILPTMAIL02.ecitele.com> References: <20080519163002.302B93A69FD@core3.amsl.com> In-Reply-To: <20080519163002.302B93A69FD@core3.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Hi I would like to get some clarification: By the end of procedure for scenario 1 its written: ..... Note that if Node C=20 restarts after this operation, the RecoveryPath message that it=20 sends to Node B will not be matched with any state on Node B and=20 will receive a PathTear as its response resulting in the teardown=20 of the LSP at all downstream nodes. How comes that node C, which is now the restarting node, sends RecoveryPath= that should be sent by downstream normal node and not by restarting node? Same question for the other scenarios that mention similar behavior. Best Regards, Yechiel Rosengarten System Engineering ECI Telecom Ltd 30 Hasivim St. Petach Tikva 49517 Israel Tel: +972 3 926 8794 Fax: +972 3 926 6200 e-mail: yechiel.rosengarten@ecitele.com -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf = Of Internet-Drafts@ietf.org Sent: Monday, May 19, 2008 7:30 PM To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gr-description-03.txt=20 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 Worki= ng Group of the IETF. Title : Description of the RSVP-TE Graceful Restart Proce= dures Author(s) : D. Li Filename : draft-ietf-ccamp-gr-description-03.txt Pages : 19 Date : 2008-5-19 The Hello message for the Resource Reservation Protocol (RSVP) has been defined to establish and maintain basic signaling node adjacencies for Label Switching Routers (LSRs) participating in a Multiprotocol Label Switching (MPLS) traffic engineered (TE) network. The Hello message has been extended for use in Generalized MPLS (GMPLS) network for state recovery of control channel or nodal faults. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gr-description-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From owner-ccamp@ops.ietf.org Tue Dec 23 06:50:41 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6318E3A6993 for ; Tue, 23 Dec 2008 06:50:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.381 X-Spam-Level: X-Spam-Status: No, score=-102.381 tagged_above=-999 required=5 tests=[AWL=0.219, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8pa2FuYm9-Av for ; Tue, 23 Dec 2008 06:50:40 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 61D773A691F for ; Tue, 23 Dec 2008 06:50:40 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LF8VQ-000LAd-6T for ccamp-data0@psg.com; Tue, 23 Dec 2008 14:45:08 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LF8VC-000L8D-0Q for ccamp@ops.ietf.org; Tue, 23 Dec 2008 14:44:57 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id 7260D3A69CB; Tue, 23 Dec 2008 06:45:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org Subject: I-D Action:draft-ietf-ccamp-rsvp-te-eth-oam-ext-00.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081223144501.7260D3A69CB@core3.amsl.com> Date: Tue, 23 Dec 2008 06:45:01 -0800 (PST) Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: --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 : GMPLS RSVP-TE Extensions for Ethernet OAM Configuration Author(s) : A. Takacs, et al. Filename : draft-ietf-ccamp-rsvp-te-eth-oam-ext-00.txt Pages : 19 Date : 2008-12-23 The GMPLS controlled Ethernet Label Switching (GELS) work is extending GMPLS RSVP-TE to support the establishment of Ethernet LSPs. IEEE Ethernet Connectivity Fault Management (CFM) specifies an adjunct OAM flow to check connectivity in Ethernet networks. CFM can be also used with Ethernet LSPs for fault detection and triggering recovery mechanisms. The ITU-T Y.1731 specification builds on CFM and specifies additional OAM mechanisms, including Performance Monitoring, for Ethernet networks. This document specifies extensions of GMPLS RSVP-TE to support the setup of the associated Ethernet OAM (CFM and Y.1731) entities adding a technology specific TLV to [OAM-CONF-FWK].Changes from previous version Technology independent extensions were moved to a separate framework document leaving only the Ethernet specific extensions in this document.Requirements Language 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 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rsvp-te-eth-oam-ext-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-ccamp-rsvp-te-eth-oam-ext-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-12-23063409.I-D@ietf.org> --NextPart-- From owner-ccamp@ops.ietf.org Tue Dec 23 06:51:17 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AEFD3A6993 for ; Tue, 23 Dec 2008 06:51:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.385 X-Spam-Level: X-Spam-Status: No, score=-102.385 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tkrSQGR5Inq4 for ; Tue, 23 Dec 2008 06:51:16 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 335433A691F for ; Tue, 23 Dec 2008 06:51:15 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LF8VH-000L9D-Ot for ccamp-data0@psg.com; Tue, 23 Dec 2008 14:44:59 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LF8VC-000L8C-0Q for ccamp@ops.ietf.org; Tue, 23 Dec 2008 14:44:57 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id 6B2763A6993; Tue, 23 Dec 2008 06:45:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org Subject: I-D Action:draft-ietf-ccamp-oam-configuration-fwk-00.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081223144501.6B2763A6993@core3.amsl.com> Date: Tue, 23 Dec 2008 06:45:01 -0800 (PST) Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: --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 : OAM Configuration Framework and Requirements for GMPLS RSVP-TE Author(s) : A. Takacs, et al. Filename : draft-ietf-ccamp-oam-configuration-fwk-00.txt Pages : 19 Date : 2008-12-23 OAM functions are essential to ensure that the desired service level of traffic engineered connections are met. In certain technologies OAM entities are inherently established once the connection is set up. However other technologies, especially OAM for packet switched networks, require an extra configuration step after connection establishment to setup OAM entities. This document specifies extensions to RSVP-TE to support the establishment and configuration of OAM entities along with LSP signalling.Requirements Language 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 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-oam-configuration-fwk-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-ccamp-oam-configuration-fwk-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-12-23063348.I-D@ietf.org> --NextPart-- From knight@ambank.com Wed Dec 24 06:39:56 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77E2C3A695C for ; Wed, 24 Dec 2008 06:39:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.239 X-Spam-Level: X-Spam-Status: No, score=-17.239 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_EQ_PPPOE=0.35, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HELO_EQ_PPPOE=0.555, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id epU1LFHgUtGW for ; Wed, 24 Dec 2008 06:39:53 -0800 (PST) Received: from PPPoE-78-29-106-50.san.ru (PPPoE-78-29-106-50.san.ru [78.29.106.50]) by core3.amsl.com (Postfix) with SMTP id C28B13A682D for ; Wed, 24 Dec 2008 06:39:51 -0800 (PST) To: Subject: Gain the monstrous dimensions From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081224143951.C28B13A682D@core3.amsl.com> Date: Wed, 24 Dec 2008 06:39:51 -0800 (PST) Make your small wand expand! From pablo.ortizo@alicante-ayto.es Thu Dec 25 03:46:29 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 804793A69EB for ; Thu, 25 Dec 2008 03:46:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -34.667 X-Spam-Level: X-Spam-Status: No, score=-34.667 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FS_WILL_HELP=2.749, HELO_EQ_DE=0.35, HTML_IMAGE_ONLY_12=2.46, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n-TPNmAClsED for ; Thu, 25 Dec 2008 03:46:28 -0800 (PST) Received: from Qed10.q.pppool.de (Qed10.q.pppool.de [89.53.237.16]) by core3.amsl.com (Postfix) with SMTP id 48FEB3A69E6 for ; Thu, 25 Dec 2008 03:46:26 -0800 (PST) To: Subject: Some lengthening will help From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081225114627.48FEB3A69E6@core3.amsl.com> Date: Thu, 25 Dec 2008 03:46:26 -0800 (PST)

If you are unable to see the message below, click here to view.

Don't waste your time! Start improving your life!

PLEASE DO NOT REPLY - This is being sent from an unattended mailbox.

Copyright © 2008 MaxGentleman, Inc. All rights reserved.
5 Trowbridge Drive, Bethel, CT 185248

You have received this message because you
opted in to receives MaxGentleman pecial offers via email.

You can unsubscribe here

 From moriahcroft@absolute-ex.com Fri Dec 26 10:18:47 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 405D23A6916 for ; Fri, 26 Dec 2008 10:18:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -46.089 X-Spam-Level: X-Spam-Status: No, score=-46.089 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LwIJNUq6QLij for ; Fri, 26 Dec 2008 10:18:46 -0800 (PST) Received: from almaceneslaganga.com (unknown [189.104.246.5]) by core3.amsl.com (Postfix) with SMTP id 079563A68F6 for ; Fri, 26 Dec 2008 10:18:42 -0800 (PST) To: Subject: Undelivered Mail Returned to Sender From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081226181844.079563A68F6@core3.amsl.com> Date: Fri, 26 Dec 2008 10:18:42 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From owner-ccamp@ops.ietf.org Fri Dec 26 10:41:11 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5E4D3A69A4 for ; Fri, 26 Dec 2008 10:41:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.547 X-Spam-Level: X-Spam-Status: No, score=-1.547 tagged_above=-999 required=5 tests=[AWL=-1.052, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PiZUw54Lwf98 for ; Fri, 26 Dec 2008 10:41:10 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 967363A6986 for ; Fri, 26 Dec 2008 10:41:10 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LGHUl-0007bY-C4 for ccamp-data0@psg.com; Fri, 26 Dec 2008 18:33:11 +0000 Received: from [63.118.34.22] (helo=hicks.ciena.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LGHUf-0007bA-N3 for ccamp@ops.ietf.org; Fri, 26 Dec 2008 18:33:08 +0000 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAO+xVEk/dicV/2dsb2JhbAC9Z1iPGYZE X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4325 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Subject: RE: IETF CCAMP Respons to OIF on Inter-Level Routing Date: Fri, 26 Dec 2008 13:33:02 -0500 Message-ID: <0AFD1B67B949784DA087CDA9F0DD4AD95E2B94@mdmxm03.ciena.com> In-Reply-To: <490D9EAB351A4F29A0710BC8A02DE864@your029b8cecfe> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IETF CCAMP Respons to OIF on Inter-Level Routing Thread-Index: AclkgKiWMue7uUG1ScqOro9zYY2+/ADB2kew References: <490D9EAB351A4F29A0710BC8A02DE864@your029b8cecfe> From: "Ong, Lyndon" Importance: normal To: "Adrian Farrel" , "Lucille Goldiner" Cc: "Brungard, Deborah A, ALABS" , Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Dear Adrian and Deborah, Thank you for the series of liaison responses, OIF will review them in our 1Q09 meeting in January. As always, we appreciate CCAMP's time and attention. Wishing everyone Happy Holidays and a productive New Year! Best regards, Lyndon Ong OIF Technical Committee Chair -----Original Message----- From: Adrian Farrel [mailto:adrian@olddog.co.uk]=20 Sent: Monday, December 22, 2008 1:59 PM To: Ong, Lyndon; Lucille Goldiner Cc: Brungard, Deborah A, ALABS; ccamp@ops.ietf.org Subject: IETF CCAMP Respons to OIF on Inter-Level Routing Dear Lyndon, Here is a final response to the issues raised by the OIF. This one relates=20 to ASON routing and multi-layer networks, and comes from your communication=20 oif2008.063.02.pdf. > in our discussions of multilayer networks and impacts on the control=20 > plane, we took note of ITU-T Recommendation > G.7715.1 requirements to advertise: > a) Local Connection Type; and > b) Local Client Adaptations Supported. > We believe that this functionality would be very useful for > applications that have been discussed in OIF (see > attachment). We would appreciate further clarification as to > whether both requirements have been addressed in the current > CCAMP work on ASON routing support (local connection type in > particular is not explicitly identified in the current draft). We would=20 > also appreciate more information on the > relationship between support of adaptation in the ASON routing draft and=20 > in the multilayer/multiregion networking > drafts also being developed in the CCAMP WG. We note that G.7715.1 discusses the operation of multi-layer networks in an=20 appendix and observes: This appendix provides illustrative examples of different methods of carrying multiple layer information between two systems. It does not mandate a particular method of implementation for link state routing protocols. From the perspective of ITU-T Rec. G.8080/Y.1304, each layer network has its own instance of a control plane. It can also be observed that a single routing level cannot span multiple=20 network layers within the ASON architecture. draft-ietf-ccamp-gmpls-ason-routing-ospf-06.txt addresses the distribution=20 of routing information between Routing Areas (in the ASON sense), but is agnostic to the routing information passed. For more details of the exchange=20 of "local connection type" and "local client adaptations" we need to look=20 into the base GMPLS routing specifications and the CCAMP work on multi-layer=20 networks. As pointed out in RFC 4652, the Switching Capability field of the Interface=20 Switching Capability Descriptor (see RFC 4202) describes the capabilities of=20 the receiver with regard to any specific TE link (e.g., PSC, TDM, etc.). Your question also opens up the issue of distinguishing between what signal=20 types an LSR can terminate (through adaptation) as distinct from switch=20 (onto another TE link). This function is addressed in another CCAMP draft,=20 draft-ietf-ccamp-gmpls-mln-extensions-03.txt, which will go to CCAMP working=20 group last call soon. This draft introduces the Interface Adaptation=20 Capability Descriptor (IACD) to carry the necessary information. Both the ISCD and the IACD can be exchanged between routing levels using the=20 techniques described in draft-ietf-ccamp-gmpls-ason-routing-ospf-06.txt. You=20 may, however, also like to look at the appropriateness of the PCE=20 architecture (RFC 4655) in the role of inter-level routing as it seems to=20 fit well with the architecture as described by the ITU-T in G.7715.2. Best regards, Adrian Farrel and Deborah Brungard IETF CCAMP Working Group Co-Chairs=20 From klancaast@amplicon.com Fri Dec 26 13:16:38 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E51093A69DC for ; Fri, 26 Dec 2008 13:16:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -48.648 X-Spam-Level: X-Spam-Status: No, score=-48.648 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_SE=0.35, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sbR2W209SEn4 for ; Fri, 26 Dec 2008 13:16:38 -0800 (PST) Received: from s206h148o3tcm15.dyn.tyfon.se (s206h148o3tcm15.dyn.tyfon.se [213.164.206.148]) by core3.amsl.com (Postfix) with SMTP id 1EA743A6870 for ; Fri, 26 Dec 2008 13:16:36 -0800 (PST) To: Subject: Undelivered Mail Returned to Sender From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081226211637.1EA743A6870@core3.amsl.com> Date: Fri, 26 Dec 2008 13:16:36 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From ltbvbv@adbag.de Sat Dec 27 03:00:31 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E42A3A6A7C for ; Sat, 27 Dec 2008 03:00:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -46.4 X-Spam-Level: X-Spam-Status: No, score=-46.4 tagged_above=-999 required=5 tests=[BAYES_60=1, FH_HOST_EQ_D_D_D_D=0.765, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HOST_EQ_STATIC=1.172, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, URIBL_BLACK=20, URIBL_JP_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eisNss9aRZJk for ; Sat, 27 Dec 2008 03:00:30 -0800 (PST) Received: from tm.84.52.187.98.dc.cable.static.telemach.net (tm.84.52.187.98.dc.cable.static.telemach.net [84.52.187.98]) by core3.amsl.com (Postfix) with SMTP id 884443A6783 for ; Sat, 27 Dec 2008 03:00:29 -0800 (PST) To: Subject: Mail System Error - Returned Mail From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081227110029.884443A6783@core3.amsl.com> Date: Sat, 27 Dec 2008 03:00:29 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From owner-ccamp@ops.ietf.org Sat Dec 27 03:09:36 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24AB33A6A76 for ; Sat, 27 Dec 2008 03:09:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.013 X-Spam-Level: X-Spam-Status: No, score=-0.013 tagged_above=-999 required=5 tests=[AWL=-1.378, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LiGozn+sEiQe for ; Sat, 27 Dec 2008 03:09:35 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AC9A03A6783 for ; Sat, 27 Dec 2008 03:09:34 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LGWvX-000KnQ-JM for ccamp-data0@psg.com; Sat, 27 Dec 2008 11:01:51 +0000 Received: from [62.128.201.249] (helo=asmtp2.iomartmail.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LGWvJ-000Klw-Rm for ccamp@ops.ietf.org; Sat, 27 Dec 2008 11:01:48 +0000 Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id mBRB1XGc010979; Sat, 27 Dec 2008 11:01:33 GMT Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id mBRB1W4f010972; Sat, 27 Dec 2008 11:01:32 GMT Message-ID: <2586C5F69A2D419CB84C76027566F79D@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: Subject: Liaison received from ITU-T SG15 Q6 - Lambda Switch Capable Equipment Date: Sat, 27 Dec 2008 11:01:22 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Hi, We have received the following liaison statement from Question 6 of Study Group 15 of the ITU-T. The liaison is for Information and so does not require any response from us, but if anyone has questions we can reply. Please note that Question 6 is inviting us to meet with them to discuss optical parameters at a joint meeting in March 2009. The current provisional plan is to hold the Q6 meeting on the West Coast in the week before the IETF (i.e., 16-20 March) inviting the CCAMP people to attend on the Thursday. Note that this is still at an early stage of planning - we will update you as firmer plans are made. At this stage, we understand that space may be limited and we will need to restrict CCAMP attendance to only those heavily involved in optical impairments work, and perhaps to only one or two people per company. In order to make this go more smoothly, please email Deborah and me if you are considering attending. You may also want to look closely at Q6's proposed encoding of wavelength I-Ds in the Annexe to the Liaison to see how it differs from the CCAMP proposal and whether there is any scope for convergence. As usual, you can get to all communications to and from CCAMP via www.olddog.co.uk/ccamp.htm Adrian === Title: LS19 - Lambda Switch Capable Equipment Submission Date: 2008-12-25 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=495 From: Greg Jones(ITU-T SG 15) To: IETF CCAMP WG(adrian@olddog.co.uk,dbrungard@att.com) Cc: sob@harvard.edu, rcallon@juniper.net, dward@cisco.com, yoichi.maeda@ntt-at.co.jp, francesco.montalti@telecomitalia.it Reponse Contact: tsbsg15@itu.int, greg.jones@itu.int Technical Contact: peter.stassar@ties.itu.int Purpose: For information Body: Q.6/15 would like to thank IETF’s CCAMP Working Group for having provided a communication on Lambda Switch Capable Equipment to Q.6/15 last summer. Q.6/15 would like to inform the IETF that Q.6/15 has agreed to add an encoding scheme for optical parameter values to a future revision of ITU-T Recommendation G.697. Q.6/15 intends to consent a revision of Recommendation G.697 during the SG15 Plenary Meeting, 28 September – 9 October 2009. An interim meeting of Q.6/15 is expected to be held in the March 2009 timeframe with the intent to progress the work on the revision of Recommendation G.697, in addition to many other topics currently under discussion within Q.6/15. Furthermore Q.6/15 would like to draw the attention of IETF’s CCAMP Working Group on Lambda Switch Capable Equipment to ITU-T Recommendation G.680, entitled “Physical transfer functions of optical network elementsâ€. The summary from the in-force version of this Recommendation is included below: ITU-T Recommendation G.680 defines a "degradation function" of optical network elements (ONEs) such as photonic cross-connects (PXCs), optical add-drop multiplexers (OADMs), etc. making up an optical network. This is done in terms of a list of parameters which characterize physical impairments such as optical noise, chromatic dispersion, etc., and is intended to be independent from the network architecture that the devices are deployed in. For each kind of ONE considered in this Recommendation, the general functional description and the reference diagram is provided. Principles for calculating the effect of cascading multiple ONEs on the degradation of the optical signal quality are given and example transfer parameter values for OADMs and PXCs are also provided. This version of the Recommendation covers the situation where the optical path between two consecutive electrical regenerators is composed of dense wavelength division multiplexing (DWDM) line segments from a single vendor and OADMs and PXCs from other vendors. Also, included in the scope section of G.680 is: A future revision of the Recommendation is expected to cover the reference situation: Situation 2 – The optical path between two consecutive 3R regenerators is composed of DWDM line segments from different vendors and OADMs and PXCs from different vendors as shown in Figure 1-2. This will enable the degradation of the signal quality due to the optical path for an arbitrary route through an all-optical network (or sub-network) consisting of optical network elements including DWDM line segments to be assessed thereby enabling routing decisions in an all-optical network (or sub-network) to be made. Q.6/15 would like to invite IETF’s CCAMP Working Group on Lambda Switch Capable Equipment to consider a joint meeting with Q.6/15 during the March 2009 timeframe, in conjunction with its interim meeting, with the intent to share each others work related to monitoring of optical parameters in optical transmission equipment and other topics that are of common interest in this area. A provision outline of what Q.6/15 intends to incorporate into revised Recommendation G.697 with respect to the encoding scheme for optical parameters is indicated in Annex 1 to this Liaison Statement. - - - - - - - - - Annex 1 Encoding of monitoring parameters [Text should be added to underline that this is only an encoding definition and it doesn’t imply that the measurements must be made or what the parameters listed are used for] Wavelength ID (32 bits): This field contains the Wavelength label and is composed of 5 sub-fields: Grid (3 bits): The value for grid is set to 1 for the ITU-T DWDM Grid as defined in G.694.1, set to 2 for the ITU-T CWDM Grid as defined in G.694.2 and the values 3 to 7 are for future use. Channel Spacing (4 bits): DWDM channel spacing Channel spacing (GHz) Value 12.5 1 25 2 50 3 100 4 Future use 0, 5 to 15 CWDM channel spacing Channel spacing (nm) Value 20 1 Future use 0, 2 to 15 S (1 bit): Sign for the value n, set to 1 for (-) and 0 for (+) n (16 bits): The value used to compute the frequency as shown below: When the grid is “1â€, Frequency (THz) = 193.1 + n * channel spacing (THz) When the grid is “2â€, Wavelength (nm) = 1470 + n * channel spacing (nm) (8 bits): for future use. Parameter ID source (x bits): This field defines the source of the parameter ID lookup table. The value 1 is G.697 Parameter ID (8 bits): When the parameter ID source is equal to 1, the following lookup table applies: Value Parameter Unit 1 Total power dBm 2 Channel power dBm 3 etc. 4 5 etc. [Others values and parameters to be added] Value of parameters (32 bits): [How to encode the parameter values into the 32 bit number, to be inserted here, one proposal is: Monitoring parameter value (IEEE 754 standard). The IEEE 754 mantissa, an integer with values from 2^n_mant to 2*2^n_mant-1, where n_mant is the number of bits available for the mantissa, is termed a normalized number and allows for integer embedding suitable for all the sensor ranges involved in G.697 parameters. This embedding is error prone only for very small numbers. ] From owner-ccamp@ops.ietf.org Sat Dec 27 03:16:06 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3859B3A6879 for ; Sat, 27 Dec 2008 03:16:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.915 X-Spam-Level: X-Spam-Status: No, score=-0.915 tagged_above=-999 required=5 tests=[AWL=-0.421, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iGBHArH4oTlr for ; Sat, 27 Dec 2008 03:16:02 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5B4CD3A6783 for ; Sat, 27 Dec 2008 03:16:02 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LGX4B-000LYL-Hn for ccamp-data0@psg.com; Sat, 27 Dec 2008 11:10:47 +0000 Received: from [62.128.201.248] (helo=asmtp1.iomartmail.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LGX46-000LXd-3R for ccamp@ops.ietf.org; Sat, 27 Dec 2008 11:10:44 +0000 Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id mBRBAbjo014881 for ; Sat, 27 Dec 2008 11:10:40 GMT Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id mBRBAapU014865 for ; Sat, 27 Dec 2008 11:10:37 GMT Message-ID: <0F87BBEE234B4DB896ACF64672FC6D0C@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Liaison Statement Received - MPLS-TP Signalling Communication Channel Date: Sat, 27 Dec 2008 11:10:30 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Hi, We have been copied on a liaison to the MPLS working group from ITU-T Study Group 15 Question 14. CCAMP is copied for Information and is not required to do anything. The MPLS working group is required to respond by 18 May 2009. You can find this liaison at www.olddog.co.uk/ccamp.htm Adrian === Title: LS28 - Generic Associated Channel (G-ACH) Requirement to Provide a Signalling Communication Channel (SCC) and a Management Communication Channel (MCC) for MPLS-TP Submission Date: 2008-12-25 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=491 Please reply by 2009-05-18 From: Greg Jones(ITU-T SG 15) To: IETF MPLS WG Co Chairs (Info: CCAMP WG Co Chairs, MEAD team)swallow@cisco.com, loa@pi.nu, adrian@olddog.co.uk, dbrungard@att.com, mpls-interop@ietf.org Cc: sob@harvard.edu, stbryant@cisco.com, rcallon@juniper.net, dward@cisco.com, yoichi.maeda@ntt-at.co.jp, sjtrowbridge@alcatel-lucent.com Reponse Contact: tsbsg15@itu.int, greg.jones@itu.int Technical Contact: hklam@alcatel-lucent.com Purpose: For action Body: Q14/15 would like to inform the IETF MPLS WG that it has added the following new study point to the Living List for ITU-T Recommendation G.7712 (Architecture and specification of data communication network): Build upon the development of the new MPLS Generic Associated Channel (G-ACH) at the IETF and amend G.7712 to align MCN and SCN aspects for MPLS-TP packet transport technology with the outcome of the IETF work on MPLS-TP. In section 3.4.1 of the Internet Draft draft-ietf-mpls-tp-framework-00.txt it is already stated that the G-ACH will provide a signalling communication channel (SCC) and a management communication channel (MCC) for MPLS-TP. The G-ACH as defined in draft-ietf-mpls-tp-gach-gal-00.txt is capable to distinguish OAM, APS, SCC, and MCC packets from each other. Moreover, it is also necessary for the SCC and MCC to distinguish between different layer 3 PDUs such as IPv4, IPv6, and OSI CLNP PDUs as it is the case for other technologies supporting the data communication network. Examples can be found in ITU-T Recommendation G.7712. Q14/15 is looking forward to the progression of MPLS-TP SCC and MCC work in the IETF, and is aware that contributions are being prepared in the form of an Internet-Draft. Q14/15 looks forward to being able to add to G.7712 accordingly as soon as the MPLS-TP SCC and MCC definitions are stable. From owner-ccamp@ops.ietf.org Sat Dec 27 03:27:30 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24ADC3A68A5 for ; Sat, 27 Dec 2008 03:27:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.208 X-Spam-Level: X-Spam-Status: No, score=-0.208 tagged_above=-999 required=5 tests=[AWL=-1.113, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_31=0.6, RDNS_NONE=0.1, SARE_SUB_RAND_LETTRS4=0.799, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CXfPRVCI-0Og for ; Sat, 27 Dec 2008 03:27:29 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 228063A6A85 for ; Sat, 27 Dec 2008 03:27:29 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LGXEc-000MvD-Kt for ccamp-data0@psg.com; Sat, 27 Dec 2008 11:21:34 +0000 Received: from [62.128.201.249] (helo=asmtp2.iomartmail.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LGXEX-000MuK-Hy for ccamp@ops.ietf.org; Sat, 27 Dec 2008 11:21:31 +0000 Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id mBRBLR34012539 for ; Sat, 27 Dec 2008 11:21:27 GMT Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id mBRBLRuG012530 for ; Sat, 27 Dec 2008 11:21:27 GMT Message-ID: <32A6775A32DF41FDAB399A04436FCB79@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Liaison Received - ITU0T SG15 OTNT Standardization Work Plan Date: Sat, 27 Dec 2008 11:21:10 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Hi, We have previously sent comments to the ITU-T on their work plan for Optical Transport Networks and Technologies. Our most recent comments can be seen at https://datatracker.ietf.org/liaison/469/ The ITU-T have updated their plan and are sharing it with us through this liaison. We are invited to comment. If you look through the document you will find a number of references to CCAMP drafts and RFCs. Some of these references are out of date, and Deborah and I will need to send them an update. I have also looked to see whether our suggestion (made in our liaison) to add asymmetric switches such as ROADMs to their plan has been included - I can't find any reference. As usual, the liaison and attachment (the work plan itself) can be found at www.olddog.co.uk/ccamp.htm Adrian ----- Original Message ----- From: "Greg Jones (ITU-T SG 15)" To: ; ; ; ; Cc: ; ; ; ; ; ; ; ; ; ; ; Sent: Thursday, December 25, 2008 7:13 PM Subject: New Liaison Statement, "LS29 - SG15 OTNT Standardization Work Plan" > > Title: LS29 - SG15 OTNT Standardization Work Plan > Submission Date: 2008-12-25 > URL of the IETF Web page: > https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=490 > Please reply by 2009-08-31 > > From: Greg Jones(ITU-T SG 15) > To: IETF CCAMP, PCE and MPLS > WGs(swallow@cisco.com,loa@pi.nu,jpv@cisco.com,adrian@olddog.co.uk,dbrungard@att.com) > Cc: sob@harvard.edu > stbryant@cisco.com > rcallon@juniper.net > dward@cisco.com > mpls@lists.ietf.org > ccamp@ops.ietf.org > pce@ietf.org > yoichi.maeda@ntt-at.co.jp > sjtrowbridge@alcatel-lucent.com > Reponse Contact: tsbsg15@itu.int > greg.jones@itu.int > Technical Contact: George_Young@labs.att.com > Purpose: For comment > Body: Thank you for your review and comments for �Optical Transport > Networks & Technologies Standardization Work Plan�. Attached is the > updated version from this SG15 meeting (Geneva, 1 � 12 December 2008). > This version reflects recent development of related standards and your > valuable input. We appreciate your review of this version and comments. > > > Attachment: OTNT Standardization Work Plan (TD62(PLEN)) > Attachment(s): > LS29 - SG15 OTNT Standardization Work Plan - body text > (https://datatracker.ietf.org/documents/LIAISON/file593.pdf) > LS29 - SG15 OTNT Standardization Work Plan - liaison attachment > (https://datatracker.ietf.org/documents/LIAISON/file594.pdf) > > > > From kyahn@aktivdialog.de Sun Dec 28 11:07:06 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 034453A6A14 for ; Sun, 28 Dec 2008 11:07:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -27.217 X-Spam-Level: X-Spam-Status: No, score=-27.217 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_SPACE_RATIO=2.219, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KAOTIDTildx8 for ; Sun, 28 Dec 2008 11:07:05 -0800 (PST) Received: from host-64-234-92-141.nctv.com (host-64-234-92-141.nctv.com [64.234.92.141]) by core3.amsl.com (Postfix) with SMTP id 85C7E3A63D2 for ; Sun, 28 Dec 2008 11:07:03 -0800 (PST) To: Subject: Undeliverable Mail From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081228190704.85C7E3A63D2@core3.amsl.com> Date: Sun, 28 Dec 2008 11:07:03 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From cooper@lahaye.net Mon Dec 29 20:43:07 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1CC33A69A4; Mon, 29 Dec 2008 20:43:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.838 X-Spam-Level: X-Spam-Status: No, score=-5.838 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DNS_FROM_OPENWHOIS=1.13, HELO_DYNAMIC_DHCP=1.398, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SBL=20, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R7UCWZQgTIfy; Mon, 29 Dec 2008 20:43:07 -0800 (PST) Received: from CableLink226-57.telefonia.InterCable.net (cablelink226-57.telefonia.intercable.net [201.172.226.57]) by core3.amsl.com (Postfix) with SMTP id CFE5C3A6922; Mon, 29 Dec 2008 20:42:53 -0800 (PST) Message-ID: Date: Mon, 29 Dec 2008 23:42:51 -0500 From: "Hiram Dennison" Subject: Patek Phillipe watches wholesale all year long! To: architecture-discuss@ietf.org Content-Type: text/plain Content-Transfer-Encoding: 7bit Dear Hiram, Looking for a Patek Phillipe? How about getting two, one for you and one for your spouse? http://www.naryhour.com/ Get two deeply discounted watches and take an extra 15% discount. http://www.naryhour.com/ Our Patek Phillipe have Weights/feels and looks exactly same as original. Sincerely, Mr Dennison From ahmet@mertler.net Tue Dec 30 02:32:42 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2523B3A67AB; Tue, 30 Dec 2008 02:32:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -28.649 X-Spam-Level: X-Spam-Status: No, score=-28.649 tagged_above=-999 required=5 tests=[BAYES_80=2, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HELO_EQ_DYNAMIC=1.144, HOST_EQ_BR=1.295, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SC_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 55OWwoXZN5pM; Tue, 30 Dec 2008 02:32:41 -0800 (PST) Received: from 189-015-183-107.xd-dynamic.ctbcnetsuper.com.br (189-015-183-107.xd-dynamic.ctbcnetsuper.com.br [189.15.183.107]) by core3.amsl.com (Postfix) with SMTP id 1B6223A63D2; Tue, 30 Dec 2008 02:32:27 -0800 (PST) Message-ID: Date: Tue, 30 Dec 2008 05:31:38 -0500 From: "Aubrey Houser" Subject: Tag Heuer watches wholesale all year long! To: atompub-archive@megatron.ietf.org Content-Type: text/plain Content-Transfer-Encoding: 7bit Dear Aubrey, If you've waited to get your Patek Phillipe watch, this is the right time to go for it. http://www.jelljell.com/ Take an extra 15% off your purchase during month of December. http://www.jelljell.com/ Our Patek Phillipe watches have perfect weight and feel same as orginal. Sincerely, Mr Houser From cw@wuhanport.com Tue Dec 30 03:20:31 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A41953A6857; Tue, 30 Dec 2008 03:20:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.607 X-Spam-Level: X-Spam-Status: No, score=-9.607 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SBL=20, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wDEpc7UhwM10; Tue, 30 Dec 2008 03:20:30 -0800 (PST) Received: from 189-53-159-8-ebt.cm.ja.net.br (189-53-159-8-ebt.cm.ja.net.br [189.53.159.8]) by core3.amsl.com (Postfix) with SMTP id 5F13E3A6837; Tue, 30 Dec 2008 03:20:01 -0800 (PST) Message-ID: Date: Tue, 30 Dec 2008 06:19:48 -0500 From: "Nick Santiago" Subject: Patek Phillipe watches wholesale all year long! To: atompub-archive@megatron.ietf.org Content-Type: text/plain Content-Transfer-Encoding: 7bit Dear Nick, I had never seen such beautiful and greatly-performing watches like the ones I found online at http://www.clipslim.com/ Take an extra 15% off your purchase during month of December. http://www.clipslim.com/ Our Patek Phillipe have all appropriate markings, wordings and engravings same as orginal. Sincerely, Mr Santiago From asma@celebratetheworld.de Tue Dec 30 08:16:33 2008 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 972FD3A67E1; Tue, 30 Dec 2008 08:16:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.168 X-Spam-Level: X-Spam-Status: No, score=-6.168 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DSL=1.129, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_NJABL_PROXY=1.643, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SBL=20, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DYhfNHDoMGoz; Tue, 30 Dec 2008 08:16:32 -0800 (PST) Received: from adsl196-211-222-217-196.adsl196-15.iam.net.ma (adsl196-211-222-217-196.adsl196-15.iam.net.ma [196.217.222.211]) by core3.amsl.com (Postfix) with SMTP id 334C73A6A61; Tue, 30 Dec 2008 08:15:57 -0800 (PST) Message-ID: Date: Tue, 30 Dec 2008 11:15:54 -0500 From: "Leola Costa" Subject: Vacheron Constantin watch for a New Year Gift! To: architecture-discuss@ietf.org Content-Type: text/plain Content-Transfer-Encoding: 7bit Dear Leola, How about buying yourself a two Patek Phillipe watches the same day? It's not impossible, mostly when you can get them for a couple hundred bucks http://www.clipcape.com/ With top notch customer service and super warranty, we stand behind our watches. http://www.clipcape.com/ Our Patek Phillipe have Weights/feels and looks exactly same as original. Sincerely, Mr Costa Envelope-to: ccamp-data0@psg.com Delivery-date: Sat, 27 Dec 2008 11:22:06 +0000 Message-ID: <32A6775A32DF41FDAB399A04436FCB79@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Liaison Received - ITU0T SG15 OTNT Standardization Work Plan Date: Sat, 27 Dec 2008 11:21:10 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit Hi, We have previously sent comments to the ITU-T on their work plan for Optical Transport Networks and Technologies. Our most recent comments can be seen at https://datatracker.ietf.org/liaison/469/ The ITU-T have updated their plan and are sharing it with us through this liaison. We are invited to comment. If you look through the document you will find a number of references to CCAMP drafts and RFCs. Some of these references are out of date, and Deborah and I will need to send them an update. I have also looked to see whether our suggestion (made in our liaison) to add asymmetric switches such as ROADMs to their plan has been included - I can't find any reference. As usual, the liaison and attachment (the work plan itself) can be found at www.olddog.co.uk/ccamp.htm Adrian ----- Original Message ----- From: "Greg Jones (ITU-T SG 15)" To: ; ; ; ; Cc: ; ; ; ; ; ; ; ; ; ; ; Sent: Thursday, December 25, 2008 7:13 PM Subject: New Liaison Statement, "LS29 - SG15 OTNT Standardization Work Plan" > > Title: LS29 - SG15 OTNT Standardization Work Plan > Submission Date: 2008-12-25 > URL of the IETF Web page: > https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=490 > Please reply by 2009-08-31 > > From: Greg Jones(ITU-T SG 15) > To: IETF CCAMP, PCE and MPLS > WGs(swallow@cisco.com,loa@pi.nu,jpv@cisco.com,adrian@olddog.co.uk,dbrungard@att.com) > Cc: sob@harvard.edu > stbryant@cisco.com > rcallon@juniper.net > dward@cisco.com > mpls@lists.ietf.org > ccamp@ops.ietf.org > pce@ietf.org > yoichi.maeda@ntt-at.co.jp > sjtrowbridge@alcatel-lucent.com > Reponse Contact: tsbsg15@itu.int > greg.jones@itu.int > Technical Contact: George_Young@labs.att.com > Purpose: For comment > Body: Thank you for your review and comments for �Optical Transport > Networks & Technologies Standardization Work Plan�. Attached is the > updated version from this SG15 meeting (Geneva, 1 � 12 December 2008). > This version reflects recent development of related standards and your > valuable input. We appreciate your review of this version and comments. > > > Attachment: OTNT Standardization Work Plan (TD62(PLEN)) > Attachment(s): > LS29 - SG15 OTNT Standardization Work Plan - body text > (https://datatracker.ietf.org/documents/LIAISON/file593.pdf) > LS29 - SG15 OTNT Standardization Work Plan - liaison attachment > (https://datatracker.ietf.org/documents/LIAISON/file594.pdf) > > > > Envelope-to: ccamp-data0@psg.com Delivery-date: Sat, 27 Dec 2008 11:11:06 +0000 Message-ID: <0F87BBEE234B4DB896ACF64672FC6D0C@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Liaison Statement Received - MPLS-TP Signalling Communication Channel Date: Sat, 27 Dec 2008 11:10:30 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit Hi, We have been copied on a liaison to the MPLS working group from ITU-T Study Group 15 Question 14. CCAMP is copied for Information and is not required to do anything. The MPLS working group is required to respond by 18 May 2009. You can find this liaison at www.olddog.co.uk/ccamp.htm Adrian === Title: LS28 - Generic Associated Channel (G-ACH) Requirement to Provide a Signalling Communication Channel (SCC) and a Management Communication Channel (MCC) for MPLS-TP Submission Date: 2008-12-25 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=491 Please reply by 2009-05-18 From: Greg Jones(ITU-T SG 15) To: IETF MPLS WG Co Chairs (Info: CCAMP WG Co Chairs, MEAD team)swallow@cisco.com, loa@pi.nu, adrian@olddog.co.uk, dbrungard@att.com, mpls-interop@ietf.org Cc: sob@harvard.edu, stbryant@cisco.com, rcallon@juniper.net, dward@cisco.com, yoichi.maeda@ntt-at.co.jp, sjtrowbridge@alcatel-lucent.com Reponse Contact: tsbsg15@itu.int, greg.jones@itu.int Technical Contact: hklam@alcatel-lucent.com Purpose: For action Body: Q14/15 would like to inform the IETF MPLS WG that it has added the following new study point to the Living List for ITU-T Recommendation G.7712 (Architecture and specification of data communication network): Build upon the development of the new MPLS Generic Associated Channel (G-ACH) at the IETF and amend G.7712 to align MCN and SCN aspects for MPLS-TP packet transport technology with the outcome of the IETF work on MPLS-TP. In section 3.4.1 of the Internet Draft draft-ietf-mpls-tp-framework-00.txt it is already stated that the G-ACH will provide a signalling communication channel (SCC) and a management communication channel (MCC) for MPLS-TP. The G-ACH as defined in draft-ietf-mpls-tp-gach-gal-00.txt is capable to distinguish OAM, APS, SCC, and MCC packets from each other. Moreover, it is also necessary for the SCC and MCC to distinguish between different layer 3 PDUs such as IPv4, IPv6, and OSI CLNP PDUs as it is the case for other technologies supporting the data communication network. Examples can be found in ITU-T Recommendation G.7712. Q14/15 is looking forward to the progression of MPLS-TP SCC and MCC work in the IETF, and is aware that contributions are being prepared in the form of an Internet-Draft. Q14/15 looks forward to being able to add to G.7712 accordingly as soon as the MPLS-TP SCC and MCC definitions are stable. Envelope-to: ccamp-data0@psg.com Delivery-date: Sat, 27 Dec 2008 11:03:59 +0000 Message-ID: <2586C5F69A2D419CB84C76027566F79D@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: Subject: Liaison received from ITU-T SG15 Q6 - Lambda Switch Capable Equipment Date: Sat, 27 Dec 2008 11:01:22 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit Hi, We have received the following liaison statement from Question 6 of Study Group 15 of the ITU-T. The liaison is for Information and so does not require any response from us, but if anyone has questions we can reply. Please note that Question 6 is inviting us to meet with them to discuss optical parameters at a joint meeting in March 2009. The current provisional plan is to hold the Q6 meeting on the West Coast in the week before the IETF (i.e., 16-20 March) inviting the CCAMP people to attend on the Thursday. Note that this is still at an early stage of planning - we will update you as firmer plans are made. At this stage, we understand that space may be limited and we will need to restrict CCAMP attendance to only those heavily involved in optical impairments work, and perhaps to only one or two people per company. In order to make this go more smoothly, please email Deborah and me if you are considering attending. You may also want to look closely at Q6's proposed encoding of wavelength I-Ds in the Annexe to the Liaison to see how it differs from the CCAMP proposal and whether there is any scope for convergence. As usual, you can get to all communications to and from CCAMP via www.olddog.co.uk/ccamp.htm Adrian === Title: LS19 - Lambda Switch Capable Equipment Submission Date: 2008-12-25 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=495 From: Greg Jones(ITU-T SG 15) To: IETF CCAMP WG(adrian@olddog.co.uk,dbrungard@att.com) Cc: sob@harvard.edu, rcallon@juniper.net, dward@cisco.com, yoichi.maeda@ntt-at.co.jp, francesco.montalti@telecomitalia.it Reponse Contact: tsbsg15@itu.int, greg.jones@itu.int Technical Contact: peter.stassar@ties.itu.int Purpose: For information Body: Q.6/15 would like to thank IETF’s CCAMP Working Group for having provided a communication on Lambda Switch Capable Equipment to Q.6/15 last summer. Q.6/15 would like to inform the IETF that Q.6/15 has agreed to add an encoding scheme for optical parameter values to a future revision of ITU-T Recommendation G.697. Q.6/15 intends to consent a revision of Recommendation G.697 during the SG15 Plenary Meeting, 28 September – 9 October 2009. An interim meeting of Q.6/15 is expected to be held in the March 2009 timeframe with the intent to progress the work on the revision of Recommendation G.697, in addition to many other topics currently under discussion within Q.6/15. Furthermore Q.6/15 would like to draw the attention of IETF’s CCAMP Working Group on Lambda Switch Capable Equipment to ITU-T Recommendation G.680, entitled “Physical transfer functions of optical network elementsâ€. The summary from the in-force version of this Recommendation is included below: ITU-T Recommendation G.680 defines a "degradation function" of optical network elements (ONEs) such as photonic cross-connects (PXCs), optical add-drop multiplexers (OADMs), etc. making up an optical network. This is done in terms of a list of parameters which characterize physical impairments such as optical noise, chromatic dispersion, etc., and is intended to be independent from the network architecture that the devices are deployed in. For each kind of ONE considered in this Recommendation, the general functional description and the reference diagram is provided. Principles for calculating the effect of cascading multiple ONEs on the degradation of the optical signal quality are given and example transfer parameter values for OADMs and PXCs are also provided. This version of the Recommendation covers the situation where the optical path between two consecutive electrical regenerators is composed of dense wavelength division multiplexing (DWDM) line segments from a single vendor and OADMs and PXCs from other vendors. Also, included in the scope section of G.680 is: A future revision of the Recommendation is expected to cover the reference situation: Situation 2 – The optical path between two consecutive 3R regenerators is composed of DWDM line segments from different vendors and OADMs and PXCs from different vendors as shown in Figure 1-2. This will enable the degradation of the signal quality due to the optical path for an arbitrary route through an all-optical network (or sub-network) consisting of optical network elements including DWDM line segments to be assessed thereby enabling routing decisions in an all-optical network (or sub-network) to be made. Q.6/15 would like to invite IETF’s CCAMP Working Group on Lambda Switch Capable Equipment to consider a joint meeting with Q.6/15 during the March 2009 timeframe, in conjunction with its interim meeting, with the intent to share each others work related to monitoring of optical parameters in optical transmission equipment and other topics that are of common interest in this area. A provision outline of what Q.6/15 intends to incorporate into revised Recommendation G.697 with respect to the encoding scheme for optical parameters is indicated in Annex 1 to this Liaison Statement. - - - - - - - - - Annex 1 Encoding of monitoring parameters [Text should be added to underline that this is only an encoding definition and it doesn’t imply that the measurements must be made or what the parameters listed are used for] Wavelength ID (32 bits): This field contains the Wavelength label and is composed of 5 sub-fields: Grid (3 bits): The value for grid is set to 1 for the ITU-T DWDM Grid as defined in G.694.1, set to 2 for the ITU-T CWDM Grid as defined in G.694.2 and the values 3 to 7 are for future use. Channel Spacing (4 bits): DWDM channel spacing Channel spacing (GHz) Value 12.5 1 25 2 50 3 100 4 Future use 0, 5 to 15 CWDM channel spacing Channel spacing (nm) Value 20 1 Future use 0, 2 to 15 S (1 bit): Sign for the value n, set to 1 for (-) and 0 for (+) n (16 bits): The value used to compute the frequency as shown below: When the grid is “1â€, Frequency (THz) = 193.1 + n * channel spacing (THz) When the grid is “2â€, Wavelength (nm) = 1470 + n * channel spacing (nm) (8 bits): for future use. Parameter ID source (x bits): This field defines the source of the parameter ID lookup table. The value 1 is G.697 Parameter ID (8 bits): When the parameter ID source is equal to 1, the following lookup table applies: Value Parameter Unit 1 Total power dBm 2 Channel power dBm 3 etc. 4 5 etc. [Others values and parameters to be added] Value of parameters (32 bits): [How to encode the parameter values into the 32 bit number, to be inserted here, one proposal is: Monitoring parameter value (IEEE 754 standard). The IEEE 754 mantissa, an integer with values from 2^n_mant to 2*2^n_mant-1, where n_mant is the number of bits available for the mantissa, is termed a normalized number and allows for integer embedding suitable for all the sensor ranges involved in G.697 parameters. This embedding is error prone only for very small numbers. ] Envelope-to: ccamp-data0@psg.com Delivery-date: Fri, 26 Dec 2008 18:35:17 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Subject: RE: IETF CCAMP Respons to OIF on Inter-Level Routing Date: Fri, 26 Dec 2008 13:33:02 -0500 Message-ID: <0AFD1B67B949784DA087CDA9F0DD4AD95E2B94@mdmxm03.ciena.com> Thread-Topic: IETF CCAMP Respons to OIF on Inter-Level Routing Thread-Index: AclkgKiWMue7uUG1ScqOro9zYY2+/ADB2kew From: "Ong, Lyndon" To: "Adrian Farrel" , "Lucille Goldiner" Cc: "Brungard, Deborah A, ALABS" , Dear Adrian and Deborah, Thank you for the series of liaison responses, OIF will review them in our 1Q09 meeting in January. As always, we appreciate CCAMP's time and attention. Wishing everyone Happy Holidays and a productive New Year! Best regards, Lyndon Ong OIF Technical Committee Chair -----Original Message----- From: Adrian Farrel [mailto:adrian@olddog.co.uk]=20 Sent: Monday, December 22, 2008 1:59 PM To: Ong, Lyndon; Lucille Goldiner Cc: Brungard, Deborah A, ALABS; ccamp@ops.ietf.org Subject: IETF CCAMP Respons to OIF on Inter-Level Routing Dear Lyndon, Here is a final response to the issues raised by the OIF. This one relates=20 to ASON routing and multi-layer networks, and comes from your communication=20 oif2008.063.02.pdf. > in our discussions of multilayer networks and impacts on the control=20 > plane, we took note of ITU-T Recommendation > G.7715.1 requirements to advertise: > a) Local Connection Type; and > b) Local Client Adaptations Supported. > We believe that this functionality would be very useful for > applications that have been discussed in OIF (see > attachment). We would appreciate further clarification as to > whether both requirements have been addressed in the current > CCAMP work on ASON routing support (local connection type in > particular is not explicitly identified in the current draft). We would=20 > also appreciate more information on the > relationship between support of adaptation in the ASON routing draft and=20 > in the multilayer/multiregion networking > drafts also being developed in the CCAMP WG. We note that G.7715.1 discusses the operation of multi-layer networks in an=20 appendix and observes: This appendix provides illustrative examples of different methods of carrying multiple layer information between two systems. It does not mandate a particular method of implementation for link state routing protocols. From the perspective of ITU-T Rec. G.8080/Y.1304, each layer network has its own instance of a control plane. It can also be observed that a single routing level cannot span multiple=20 network layers within the ASON architecture. draft-ietf-ccamp-gmpls-ason-routing-ospf-06.txt addresses the distribution=20 of routing information between Routing Areas (in the ASON sense), but is agnostic to the routing information passed. For more details of the exchange=20 of "local connection type" and "local client adaptations" we need to look=20 into the base GMPLS routing specifications and the CCAMP work on multi-layer=20 networks. As pointed out in RFC 4652, the Switching Capability field of the Interface=20 Switching Capability Descriptor (see RFC 4202) describes the capabilities of=20 the receiver with regard to any specific TE link (e.g., PSC, TDM, etc.). Your question also opens up the issue of distinguishing between what signal=20 types an LSR can terminate (through adaptation) as distinct from switch=20 (onto another TE link). This function is addressed in another CCAMP draft,=20 draft-ietf-ccamp-gmpls-mln-extensions-03.txt, which will go to CCAMP working=20 group last call soon. This draft introduces the Interface Adaptation=20 Capability Descriptor (IACD) to carry the necessary information. Both the ISCD and the IACD can be exchanged between routing levels using the=20 techniques described in draft-ietf-ccamp-gmpls-ason-routing-ospf-06.txt. You=20 may, however, also like to look at the appropriateness of the PCE=20 architecture (RFC 4655) in the role of inter-level routing as it seems to=20 fit well with the architecture as described by the ITU-T in G.7715.2. Best regards, Adrian Farrel and Deborah Brungard IETF CCAMP Working Group Co-Chairs=20 Envelope-to: ccamp-data0@psg.com Delivery-date: Tue, 23 Dec 2008 14:46:48 +0000 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org Subject: I-D Action:draft-ietf-ccamp-rsvp-te-eth-oam-ext-00.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081223144501.7260D3A69CB@core3.amsl.com> Date: Tue, 23 Dec 2008 06:45:01 -0800 (PST) --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 : GMPLS RSVP-TE Extensions for Ethernet OAM Configuration Author(s) : A. Takacs, et al. Filename : draft-ietf-ccamp-rsvp-te-eth-oam-ext-00.txt Pages : 19 Date : 2008-12-23 The GMPLS controlled Ethernet Label Switching (GELS) work is extending GMPLS RSVP-TE to support the establishment of Ethernet LSPs. IEEE Ethernet Connectivity Fault Management (CFM) specifies an adjunct OAM flow to check connectivity in Ethernet networks. CFM can be also used with Ethernet LSPs for fault detection and triggering recovery mechanisms. The ITU-T Y.1731 specification builds on CFM and specifies additional OAM mechanisms, including Performance Monitoring, for Ethernet networks. This document specifies extensions of GMPLS RSVP-TE to support the setup of the associated Ethernet OAM (CFM and Y.1731) entities adding a technology specific TLV to [OAM-CONF-FWK].Changes from previous version Technology independent extensions were moved to a separate framework document leaving only the Ethernet specific extensions in this document.Requirements Language 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 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rsvp-te-eth-oam-ext-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-ccamp-rsvp-te-eth-oam-ext-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-12-23063409.I-D@ietf.org> --NextPart-- Envelope-to: ccamp-data0@psg.com Delivery-date: Tue, 23 Dec 2008 14:46:37 +0000 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org Subject: I-D Action:draft-ietf-ccamp-oam-configuration-fwk-00.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081223144501.6B2763A6993@core3.amsl.com> Date: Tue, 23 Dec 2008 06:45:01 -0800 (PST) --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 : OAM Configuration Framework and Requirements for GMPLS RSVP-TE Author(s) : A. Takacs, et al. Filename : draft-ietf-ccamp-oam-configuration-fwk-00.txt Pages : 19 Date : 2008-12-23 OAM functions are essential to ensure that the desired service level of traffic engineered connections are met. In certain technologies OAM entities are inherently established once the connection is set up. However other technologies, especially OAM for packet switched networks, require an extra configuration step after connection establishment to setup OAM entities. This document specifies extensions to RSVP-TE to support the establishment and configuration of OAM entities along with LSP signalling.Requirements Language 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 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-oam-configuration-fwk-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-ccamp-oam-configuration-fwk-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-12-23063348.I-D@ietf.org> --NextPart-- Envelope-to: ccamp-data0@psg.com Delivery-date: Tue, 23 Dec 2008 11:31:05 +0000 From: Yechiel Rosengarten To: "danli@huawei.com" , "gjhhit@huawei.com" , "asatyana@cisco.com" CC: "ccamp@ops.ietf.org" Date: Tue, 23 Dec 2008 13:28:46 +0200 Subject: RE: I-D ACTION:draft-ietf-ccamp-gr-description-03.txt Thread-Topic: I-D ACTION:draft-ietf-ccamp-gr-description-03.txt Thread-Index: Aci5znz+u2xxeM60RmyR3fLjaArEpyrIc99A Message-ID: <93BC09B2B8795C49B4E3453CE6A45A18894C496ECB@ILPTMAIL02.ecitele.com> Accept-Language: en-US Content-Language: en-US acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Hi I would like to get some clarification: By the end of procedure for scenario 1 its written: ..... Note that if Node C=20 restarts after this operation, the RecoveryPath message that it=20 sends to Node B will not be matched with any state on Node B and=20 will receive a PathTear as its response resulting in the teardown=20 of the LSP at all downstream nodes. How comes that node C, which is now the restarting node, sends RecoveryPath= that should be sent by downstream normal node and not by restarting node? Same question for the other scenarios that mention similar behavior. Best Regards, Yechiel Rosengarten System Engineering ECI Telecom Ltd 30 Hasivim St. Petach Tikva 49517 Israel Tel: +972 3 926 8794 Fax: +972 3 926 6200 e-mail: yechiel.rosengarten@ecitele.com -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf = Of Internet-Drafts@ietf.org Sent: Monday, May 19, 2008 7:30 PM To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gr-description-03.txt=20 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 Worki= ng Group of the IETF. Title : Description of the RSVP-TE Graceful Restart Proce= dures Author(s) : D. Li Filename : draft-ietf-ccamp-gr-description-03.txt Pages : 19 Date : 2008-5-19 The Hello message for the Resource Reservation Protocol (RSVP) has been defined to establish and maintain basic signaling node adjacencies for Label Switching Routers (LSRs) participating in a Multiprotocol Label Switching (MPLS) traffic engineered (TE) network. The Hello message has been extended for use in Generalized MPLS (GMPLS) network for state recovery of control channel or nodal faults. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gr-description-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Envelope-to: ccamp-data0@psg.com Delivery-date: Mon, 22 Dec 2008 22:02:42 +0000 Message-ID: <490D9EAB351A4F29A0710BC8A02DE864@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Lyndon Ong" , "Lucille Goldiner" Cc: "Brungard, Deborah A, ALABS" , Subject: IETF CCAMP Respons to OIF on Inter-Level Routing Date: Mon, 22 Dec 2008 21:59:24 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit Dear Lyndon, Here is a final response to the issues raised by the OIF. This one relates to ASON routing and multi-layer networks, and comes from your communication oif2008.063.02.pdf. > in our discussions of multilayer networks and impacts on the control > plane, we took note of ITU-T Recommendation > G.7715.1 requirements to advertise: > a) Local Connection Type; and > b) Local Client Adaptations Supported. > We believe that this functionality would be very useful for > applications that have been discussed in OIF (see > attachment). We would appreciate further clarification as to > whether both requirements have been addressed in the current > CCAMP work on ASON routing support (local connection type in > particular is not explicitly identified in the current draft). We would > also appreciate more information on the > relationship between support of adaptation in the ASON routing draft and > in the multilayer/multiregion networking > drafts also being developed in the CCAMP WG. We note that G.7715.1 discusses the operation of multi-layer networks in an appendix and observes: This appendix provides illustrative examples of different methods of carrying multiple layer information between two systems. It does not mandate a particular method of implementation for link state routing protocols. From the perspective of ITU-T Rec. G.8080/Y.1304, each layer network has its own instance of a control plane. It can also be observed that a single routing level cannot span multiple network layers within the ASON architecture. draft-ietf-ccamp-gmpls-ason-routing-ospf-06.txt addresses the distribution of routing information between Routing Areas (in the ASON sense), but is agnostic to the routing information passed. For more details of the exchange of "local connection type" and "local client adaptations" we need to look into the base GMPLS routing specifications and the CCAMP work on multi-layer networks. As pointed out in RFC 4652, the Switching Capability field of the Interface Switching Capability Descriptor (see RFC 4202) describes the capabilities of the receiver with regard to any specific TE link (e.g., PSC, TDM, etc.). Your question also opens up the issue of distinguishing between what signal types an LSR can terminate (through adaptation) as distinct from switch (onto another TE link). This function is addressed in another CCAMP draft, draft-ietf-ccamp-gmpls-mln-extensions-03.txt, which will go to CCAMP working group last call soon. This draft introduces the Interface Adaptation Capability Descriptor (IACD) to carry the necessary information. Both the ISCD and the IACD can be exchanged between routing levels using the techniques described in draft-ietf-ccamp-gmpls-ason-routing-ospf-06.txt. You may, however, also like to look at the appropriateness of the PCE architecture (RFC 4655) in the role of inter-level routing as it seems to fit well with the architecture as described by the ITU-T in G.7715.2. Best regards, Adrian Farrel and Deborah Brungard IETF CCAMP Working Group Co-Chairs Envelope-to: ccamp-data0@psg.com Delivery-date: Mon, 22 Dec 2008 22:02:35 +0000 Message-ID: <91CC78DEFAEC46F7891364F806AF2113@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Lyndon Ong" , "Lucille Goldiner" Cc: "Brungard, Deborah A, ALABS" , Subject: IETF CCAMP Response to OIF on Resv Usage Date: Mon, 22 Dec 2008 21:49:36 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit Dear Lyndon, CCAMP owes the OIF responses to several communications. Apologies for the delay in producing formal responses. The issues raised were discussed at some length during the months after we received the communication both on and off the CCAMP mailing list, and I know you were involved in some of those discussions, but we forgot to send the formal responses. We will generate a series of responses with the technical issues broken out into separate threads. This first one addresses the issue of Resv usage during make-before-break as raised in oif2008.063.02.pdf. Best regards, Adrian Farrel and Deborah Brungard IETF CCAMP Working Group Co-chairs --- > OIF thanks CCAMP for its prompt and very informative response > to our liaison on OIF interoperability demo findings, sent > from our 4Q2007 meeting. We appreciate CCAMP's offer to use > the CCAMP mailing list for questions during our demo planning > and testing, although more structured liaisons are still > useful in our view to reflect meeting results and issues or > comments that are agreed across OIF members (as opposed to > individual views). [SNIP] > Based on your response liaison, it is our understanding that > per-LSP RESV messages should be expected for the "make- > before-break" scenario of modification. However, some members > have commented that it appears to be possible in the > specifications to use a single RESV message for multiple LSPs > because: > a) RFC 2205 allows the RESV message to carry multiple > FILTER_SPEC objects, specifically with the Shared Explicit > (SE) style that supports reservation sharing; and > b) The FILTER_SPEC object was extended in RFC 3209 to carry > the LSP_ID. > > Clarification would be appreciated as to whether we should > allow for receiving a single RESV message with multiple > FILTER_SPEC objects in the "make-before-break" scenario using > the SE style. We believe this issue is substantially the same as the following issue raised in the OIF correspondence dated November 29, 2007 with the subject "Liaison to IETF Regarding 2007 Interop Test Findings". Here you wrote: >> - 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 our response, dated January 3, 2008, we stated: >> 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. To help clarify this point, we draw your attention to RFC 3209 which states: The SESSION object uniquely defines a traffic engineered tunnel. The SENDER_TEMPLATE and FILTER_SPEC objects carry an LSP ID. The SENDER_TEMPLATE (or FILTER_SPEC) object together with the SESSION object uniquely identifies an LSP tunnel. As LSP tunnels (or LSPs for short) are identified using different LSP IDs (as carried in SENDER_TEMPLATE and FILTER_SPEC objects) and each LSP is signaled independently, multiple FILTER_SPEC objects SHOULD NOT be allowed as part of make-before-break. Envelope-to: ccamp-data0@psg.com Delivery-date: Mon, 22 Dec 2008 22:02:26 +0000 Message-ID: <852E2CC78CA84E69891E7E5ECA480F0C@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Lyndon Ong" , "Lucille Goldiner" Cc: "Brungard, Deborah A, ALABS" , Subject: IETF CCAMP Response to OIF on VCAT Date: Mon, 22 Dec 2008 21:57:07 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit Dear Lyndon, In your communication oif2007.377.02.pdf you made several comments about our VCAT/LCAS work, but did not specifically request any response. In communication oif2008.063.02.pdf you said: > We would also appreciate any feedback that you might have on > our liaison from the 4Q2007 meeting on VCAT/LCAS requirements, > especially whether these were incorporated into your work on VCAT/LCAS > support. This response addresses the points you made in the earlier communication. You wrote: > We have been monitoring with great interest the work on > VCAT/LCAS support in the IETF CCAMP WG, as we have done > prototyping work on control of VCAT/LCAS for interoperability > events in 2005 and 2007. As a result of our internal > discussion and prototyping work, we have identified a number > of requirements on VCAT/LCAS support that we believe are > important and may be helpful input to your work. > > In general, we agree with the requirements already identified > in draft-ietf-ccamp-gmpls-vcat-lcas-03.txt. Please note that this draft is now at the 07 revision and may be found as draft-ietf-ccamp-gmpls-vcat-lcas-07.txt > The following have been identified as important functionality > for control plane support for VCAT/LCAS that is not currently > identified in the CCAMP draft: > > - Ability to identify link endpoint capabilities associated with VCAT such > as support of LCAS functionality > - Possible additional requirement on ASON routing support to be taken > into account in CCAMP work on ASON routing > extensions rather than the VCAT/LCAS draft itself > - This might be generalizable to advertising inverse multiplexing > capabilities in addition to VCAT/LCAS CCAMP did consider extensions to IGPs to distribute inverse multiplexing, VCAT, and LCAS capabilities. This information would allow the initiator of a VCG to understand the capabilities of the egress that it is attempting to connect to. However, we decided that the LSP will not be set up to a different destination based on the VCAT capabilities. The LSP is required between a pair of LSRs, and there is no benefit to routing in distributing the end-point capabilities. Thus, we decided that if any negotiation is needed, it should be performed on the Call. > - Clean separation of VCG (VCAT Group) control from the > control of VCG members > - Supports the ability to create and modify the VCG independent of its > members We believe that this is exactly what our draft does. > - Supports potentially different sequences of creation, e.g., creation > of members first followed by VCG creation > or creation of VCG first followed by its members We believe that the ITU Recommendations that define VCAT do not support this behavior. We are also not convinced that this would be a valid way of operating a network - trails are not created on the off-chance that they will be used as part of a VCG at some time in the future. > - A single separate signaling session associated with the > VCG is an approach that has been prototyped successfully > in OIF interop events and may be a possible approach. While the use of a separate signaling session to establish the VCG is a fine way to conduct an experiment to establish data plane interoperability, this is not a good architectural solution for RSVP-TE. The signaling exchange of an RSVP-TE Path and Resv message is intended to establish an LSP. The coordination between end points for VCAT is far closer to the processes necessary for a Call, and that is why we have used the RSVP-TE Notify message exchange in our draft. > - We believe the current approach in the CCAMP draft has > limitations in this respect due to the incorporation of multiple VCGs > within a single call, as this does not cleanly separate the VCG state and > the state of its component members. We suggest that CCAMP consider using a > single call per VCG instead, based on our prototyping > experiences. This may reflect some misunderstanding of the CCAMP draft. The draft currently allows a one-to-one correlation between Call and VCG. Component members are, of course, associated with the VCG and so the state of the component members is directly associated with the state of the VCG itself. > - Separation of VCG and member sessions will allow unambiguous semantics > for VCG characteristics vs. member > characteristics such as support of recovery modes Again, this may represent some misunderstanding of the CCAMP draft. The draft allows each LSP (VCG member) to be maintained with distinct characteristics. > - Ability to identify VCG members within VCG-related signaling > - Note that it may be common in ASON environments for a VCG > connection to span multiple domains and RSVP sessions in series, in > which case session-specific objects such as > the LSP ID and Tunnel ID are not guaranteed to have > unique values end-to-end > - Manipulation of VCG characteristics requires the ability to clearly > and unambiguously identify the VCG members at each end of the VCG We note that "session shuffling" is peculiar to the OIF way of addressing the ASON architecture, and the CCAMP working group has previously expressed its view that such a way of building a network, while functional, is not advisable. Since the OIF presumably has a solution to the fact that any one connection must be unambiguously identifiable at each end of the connection, we do not consider that the problem is exacerbated by the construction of a VCG. Indeed, session shuffling can only work if there is a consistent, coherent, repeatable, and reversible mapping of the various parameters (such as addresses, Tunnel ID, and LSP ID) at domain boundaries. > - Ability to maintain VCG state across control plane failures > - It is important to be able to maintain the VCG in the > event of temporary loss of control plane connectivity or control plane > state > - We believe that graceful restart-like capabilities in RSVP need to be > supported to maintain VCG state across control plane failure. You are correct that the control plane state must be recoverable after control plane component restart, and must be resynchronized after control plane connectivity recovery. Further, the data plane state must not be perturbed by control plane failure or restart. Graceful restart is a standard part of GMPLS RSVP-TE. It can be found in RFC 5063. A more detailed description (including a discussion of the handling of multiple failures) can be found in draft-ietf-ccamp-gr-description-03.txt which is currently being reviewed by the IESG prior to publication as an RFC. Restart processing for GMPLS Calls is covered in RFC 4974. The VCAT work simply re-uses these mechanisms and no further description is required. Regards, Adrian Farrel and Deborah Brungard IETF CCAMP Working Group Co-Chairs Envelope-to: ccamp-data0@psg.com Delivery-date: Mon, 22 Dec 2008 22:02:19 +0000 Message-ID: Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Lyndon Ong" , "Lucille Goldiner" Cc: "Brungard, Deborah A, ALABS" , Subject: IETF CCAMP Response to OIF on MEF-Related Work Date: Mon, 22 Dec 2008 21:51:25 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit Dear Lyndon, In your communication oif2008.063.02.pdf dated February 14, 2008 you noted: > Finally, we noted the discussion on the CCAMP mailing list > regarding the computation of the Length field for TLVs, especially for the > Ethernet Bandwidth Profile TLV used in > the Ethernet Traffic Parameters draft. As this draft is considered to be > very important for support of MEF defined > Ethernet services, we request that this issue be resolved > as soon as possible within CCAMP. > Our preference would be to compute the Length field for all > TLVs (except those in RFC 4420) based on the full TLV rather > than the Value alone, as this is the method commonly used in > the past for length computation in RSVP. Please note that RFC 4420 has been revised as draft-ietf-ccamp-rfc4420-bis-03.txt. This draft is in the RFC Editor's queue, and will shortly be published as an RFC that obsoletes RFC 4420. The change is to make the processing of all RSVP-TE TLVs consistent so that the Length field accounts for the full length of the TLV. This change has also been incorporated into the work on traffic parameters for Ethernet as described in draft-ietf-ccamp-ethernet-traffic-parameters-06.txt. You will be pleased to hear that we consider our work on MEF-related protocol extensions to be stable, and we will shortly issue working group last calls on the following drafts: draft-ietf-ccamp-ethernet-traffic-parameters-06.txt draft-ietf-ccamp-gmpls-ether-svcs-02.txt draft-ietf-ccamp-gmpls-mef-uni-01.txt draft-ietf-ccamp-gmpls-dcsc-channel-ext-00.txt In view of the imminent last call on this work, we would welcome any input from OIF members. Input should be made either by official communication from the OIF, or by email from any individual to the CCAMP mailing list (subscription details are found at http://www.ietf.org/html.charters/ccamp-charter.html). Best regards, Adrian Farrel and Deborah Brungard IETF CCAMP Working Group Co-Chairs Envelope-to: ccamp-data0@psg.com Delivery-date: Thu, 18 Dec 2008 17:15:36 +0000 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org Subject: I-D Action:draft-ietf-ccamp-gmpls-vcat-lcas-07.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081218171501.B160B3A6B86@core3.amsl.com> Date: Thu, 18 Dec 2008 09:15:01 -0800 (PST) --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 : draft-ietf-ccamp-gmpls-vcat-lcas-07.txt Author(s) : G. Bernstein, et al. Filename : draft-ietf-ccamp-gmpls-vcat-lcas-07.txt Pages : 21 Date : 2008-12-18 This document describes requirements for, and use of, the Generalized Multi-Protocol Label Switching (GMPLS) control plane in conjunction with the Virtual Concatenation (VCAT) layer 1 inverse multiplexing mechanism and its companion Link Capacity Adjustment Scheme (LCAS) which can be used for hitless dynamic resizing of the inverse multiplex group. These techniques apply to Optical Transport Network (OTN), Synchronous Optical Network (SONET), Synchronous Digital Hierarchy (SDH), and Plesiochronous Digital Hierarchy (PDH) signals. 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 [RFC2119]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-vcat-lcas-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-ccamp-gmpls-vcat-lcas-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-12-18090242.I-D@ietf.org> --NextPart-- Envelope-to: ccamp-data0@psg.com Delivery-date: Thu, 18 Dec 2008 17:00:23 +0000 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org Subject: I-D Action:draft-ietf-ccamp-rwa-wson-encode-00.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081218170001.DD43D3A69D6@core3.amsl.com> Date: Thu, 18 Dec 2008 09:00:01 -0800 (PST) --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 : Routing and Wavelength Assignment Information Encoding for Wavelength Switched Optical Networks Author(s) : G. Bernstein Filename : draft-ietf-ccamp-rwa-wson-encode-00.txt Pages : 21 Date : 2008-12-18 A wavelength switched optical network (WSON) requires that certain key information elements are made available to facilitate path computation and the establishment of label switching paths (LSPs). The information model described in "Routing and Wavelength Assignment Information for Wavelength Switched Optical Networks" shows what information is required at specific points in the WSON. The information may be used in Generalized Multiprotocol Label Switching (GMPLS) signaling protocols, and may be distributed by GMSPL routing protocols. Other distribution mechanisms (for example, XML-based protocols) may also be used. This document provides efficient, protocol-agnostic encodings for the information elements necessary to operate a WSON. It is intended that protocol-specific documents will reference this memo to describe how information is carried for specific uses. 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 [RFC2119]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rwa-wson-encode-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-ccamp-rwa-wson-encode-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-12-18085918.I-D@ietf.org> --NextPart-- Envelope-to: ccamp-data0@psg.com Delivery-date: Thu, 18 Dec 2008 16:53:46 +0000 Date: Thu, 18 Dec 2008 10:52:21 -0600 From: Young Lee Subject: RE: draft-bernstein-ccamp-wson-encode accepted as WG I-D To: 'Adrian Farrel' , ccamp@ops.ietf.org Cc: 'Greg Bernstein' Message-id: <004a01c96130$ffbd2480$4a0c7c0a@china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Aclg+oGlDvWPP7uWQHGD6/7rE+XLOAANlc9A We will submit the update with the clear scope spelled out. Thanks. Young -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel Sent: Thursday, December 18, 2008 4:18 AM To: ccamp@ops.ietf.org Cc: Greg Bernstein Subject: draft-bernstein-ccamp-wson-encode accepted as WG I-D Hi, draft-bernstein-ccamp-wson-encode-01.txt is accepted as a working group draft. Authors, please resubmit as draft-ietf-ccamp-rwa-wson-encode-00.txt to indicate that the problem space you address is just the RWA portion of WSON. Thanks, Adrian Envelope-to: ccamp-data0@psg.com Delivery-date: Thu, 18 Dec 2008 14:42:43 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: Accepting OAM Configuration I-Ds Date: Thu, 18 Dec 2008 15:40:36 +0100 Message-ID: <53CCFDD6E346CB43994852666C210E9105DC41A8@esealmw116.eemea.ericsson.se> Thread-Topic: Accepting OAM Configuration I-Ds thread-index: Aclg/IfD41CeG/WRTpGetj24ciG71QAHccOg From: "Attila Takacs" To: "Adrian Farrel" , Hi Adrian, > We see reasonable consensus for adoption, but are aware that=20 > several people expressed a concern that this work would=20 > deprecate LSP Ping as a bootstrap mechanism for OAM in=20 > certain environments. >=20 > We believe that it is not the authors' intention to deprecate=20 > the use of LSP Ping in this way, and that it would not be=20 > wise to make such a change. >=20 Agreed. > Therefore, we accept these two I-Ds as working group drafts,=20 > but request the authors to add to=20 > draft-takacs-ccamp-oam-configuration-fwk-01.txt to say: >=20 > The mechansim described in this document provides an=20 > additional option for bootstrapping OAM that is not intended=20 > to replace or deprecate the use of other OAM bootstrapping=20 > techniques such as LSP Ping [RFC4379]. The procedures=20 > specified in this document are intended only for use in=20 > environments where RSVP-TE signaling is already in use to set=20 > up the LSPs that are to be monitored using OAM. >=20 Will add the note and resubmit. Thanks and best regards, Attila > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel > Sent: Thursday, December 18, 2008 11:32 AM > To: ccamp@ops.ietf.org > Subject: Accepting OAM Configuration I-Ds >=20 > Hi, >=20 > Deborah and I have listened to the discussion about accepting=20 > the two OAM configuration I-Ds=20 > (draft-takacs-ccamp-oam-configuration-fwk-01.txt and > draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt) as working=20 > group drafts. >=20 > We see reasonable consensus for adoption, but are aware that=20 > several people expressed a concern that this work would=20 > deprecate LSP Ping as a bootstrap mechanism for OAM in=20 > certain environments. >=20 > We believe that it is not the authors' intention to deprecate=20 > the use of LSP Ping in this way, and that it would not be=20 > wise to make such a change. >=20 > Therefore, we accept these two I-Ds as working group drafts,=20 > but request the authors to add to=20 > draft-takacs-ccamp-oam-configuration-fwk-01.txt to say: >=20 > The mechansim described in this document provides an=20 > additional option for bootstrapping OAM that is not intended=20 > to replace or deprecate the use of other OAM bootstrapping=20 > techniques such as LSP Ping [RFC4379]. The procedures=20 > specified in this document are intended only for use in=20 > environments where RSVP-TE signaling is already in use to set=20 > up the LSPs that are to be monitored using OAM. >=20 >=20 > We believe that this text goes some way to address the=20 > concerns raised and we note that the draft will be the=20 > property of the working group allowing additional changes to=20 > be made according to working group consensus. >=20 >=20 > Authors, please make the textual change and submit >=20 > draft-takacs-ccamp-oam-configuration-fwk-01.txt > as > draft-ietf-ccamp-oam-configuration-fwk-00.txt >=20 > and > draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt > as > draft-ietf-ccamp-rsvp-te-eth-oam-ext-00.txt >=20 >=20 > Thanks, > Adrian and Deborah=20 >=20 >=20 >=20 Envelope-to: ccamp-data0@psg.com Delivery-date: Thu, 18 Dec 2008 10:32:41 +0000 Message-ID: Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Accepting OAM Configuration I-Ds Date: Thu, 18 Dec 2008 10:31:54 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Hi, Deborah and I have listened to the discussion about accepting the two OAM configuration I-Ds (draft-takacs-ccamp-oam-configuration-fwk-01.txt and draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt) as working group drafts. We see reasonable consensus for adoption, but are aware that several people expressed a concern that this work would deprecate LSP Ping as a bootstrap mechanism for OAM in certain environments. We believe that it is not the authors' intention to deprecate the use of LSP Ping in this way, and that it would not be wise to make such a change. Therefore, we accept these two I-Ds as working group drafts, but request the authors to add to draft-takacs-ccamp-oam-configuration-fwk-01.txt to say: The mechansim described in this document provides an additional option for bootstrapping OAM that is not intended to replace or deprecate the use of other OAM bootstrapping techniques such as LSP Ping [RFC4379]. The procedures specified in this document are intended only for use in environments where RSVP-TE signaling is already in use to set up the LSPs that are to be monitored using OAM. We believe that this text goes some way to address the concerns raised and we note that the draft will be the property of the working group allowing additional changes to be made according to working group consensus. Authors, please make the textual change and submit draft-takacs-ccamp-oam-configuration-fwk-01.txt as draft-ietf-ccamp-oam-configuration-fwk-00.txt and draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt as draft-ietf-ccamp-rsvp-te-eth-oam-ext-00.txt Thanks, Adrian and Deborah Envelope-to: ccamp-data0@psg.com Delivery-date: Thu, 18 Dec 2008 10:21:08 +0000 Message-ID: <722A4A56A60942F08F278CFA611E9ED8@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "Greg Bernstein" Subject: draft-bernstein-ccamp-wson-encode accepted as WG I-D Date: Thu, 18 Dec 2008 10:18:17 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Hi, draft-bernstein-ccamp-wson-encode-01.txt is accepted as a working group draft. Authors, please resubmit as draft-ietf-ccamp-rwa-wson-encode-00.txt to indicate that the problem space you address is just the RWA portion of WSON. Thanks, Adrian Envelope-to: ccamp-data0@psg.com Delivery-date: Thu, 18 Dec 2008 00:12: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: Working Group Last Call ends: draft-ietf-ccamp-path-key-ero-02.txt Date: Wed, 17 Dec 2008 19:11:09 -0500 Message-ID: Thread-Topic: Working Group Last Call ends: draft-ietf-ccamp-path-key-ero-02.txt Thread-Index: AclLcSBkC9PN1RWSRrquCv8jL/wuaAVM4Rmg From: "BRUNGARD, DEBORAH A, ATTLABS" To: This ends the Last Call. There were no comments. Thanks- Deborah _____________________________________________ From: BRUNGARD, DEBORAH A, ATTLABS=20 Sent: Thursday, November 20, 2008 7:36 PM To: 'ccamp@ops.ietf.org' Subject: Working Group Last Call: draft-ietf-ccamp-path-key-ero-02.txt This is to initiate a Working Group Last Call on: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-path-key-ero-02.txt Please send your comments to the mailing list prior to EOB Dec 5. Thanks, Deborah and Adrian Envelope-to: ccamp-data0@psg.com Delivery-date: Wed, 17 Dec 2008 22:21:41 +0000 Message-ID: Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Last of 4 drafts to OIF : inter-level routing Date: Wed, 17 Dec 2008 22:19:13 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Hi, A fourth and final draft for you to review... Thanks, Adrian === Dear Lyndon, Here is a final response to the issues raised by the OIF. This one relates to ASON routing and multi-layer networks, and comes from your communication oif2008.063.02.pdf. > in our discussions of multilayer networks and impacts > on the control plane, we took note of ITU-T Recommendation > G.7715.1 requirements to advertise: > a) Local Connection Type; and > b) Local Client Adaptations Supported. > We believe that this functionality would be very useful for > applications that have been discussed in OIF (see > attachment). We would appreciate further clarification as to > whether both requirements have been addressed in the current > CCAMP work on ASON routing support (local connection type in > particular is not explicitly identified in the current > draft). We would also appreciate more information on the > relationship between support of adaptation in the ASON > routing draft and in the multilayer/multiregion networking > drafts also being developed in the CCAMP WG. We note that G.7715.1 discusses the operation of multi-layer networks in an appendix and observes: This appendix provides illustrative examples of different methods of carrying multiple layer information between two systems. It does not mandate a particular method of implementation for link state routing protocols. From the perspective of ITU-T Rec. G.8080/Y.1304, each layer network has its own instance of a control plane. It can also be observed that a single routing level cannot span multiple network layers within the ASON architecture. draft-ietf-ccamp-gmpls-ason-routing-ospf-06.txt addresses the distribution of routing information between Routing Areas (in the ASON sense), but is agnostic to the routing information passed. For more details of the exchange of "local connection type" and "local client adaptations" we need to look into the base GMPLS routing specifications and the CCAMP work on multi- layer networks. As pointed out in RFC 4652, the Switching Capability field of the Interface Switching Capability Descriptor (see RFC 4202) describes the capabilities of the receiver with regard to any specific TE link (e.g., PSC, TDM, etc.). Your question also opens up the issue of distinguishing between what signal types an LSR can terminate (through adaptation) as distinct from switch (onto another TE link). This function is addressed in another CCAMP draft, draft-ietf-ccamp-gmpls-mln-extensions-03.txt, which will go to CCAMP working group last call soon. This draft introduces the Interface Adaptation Capability Descriptor (IACD) to carry the necessary information. Both the ISCD and the IACD can be exchanged between routing levels using the techniques described in draft-ietf-ccamp- gmpls-ason-routing-ospf-06.txt. You may, however, also like to look at the appropriateness of the PCE architecture (RFC 4655) in the role of inter-level routing as it seems to fit well with the architecture as described by the ITU-T in G.7715.2. Best regards, Adrian Farrel and Deborah Brungard IETF CCAMP Working Group Co-Chairs Envelope-to: ccamp-data0@psg.com Delivery-date: Tue, 16 Dec 2008 17:29:56 +0000 Message-ID: Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Furthre draft to OIF : VCAT Date: Tue, 16 Dec 2008 17:28:12 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Hi, Review and comment please. Thanks, Adrian ==== Dear Lyndon, In your communication oif2007.377.02.pdf you made several comments about our VCAT/LCAS work, but did not specifically request any response. In communication oif2008.063.02.pdf you said: > We would also appreciate any feedback that you might have on > our liaison from the 4Q2007 meeting on VCAT/LCAS requirements, > especially whether these were incorporated into your work on > VCAT/LCAS support. This response addresses the points you made in the earlier communication. You wrote: > We have been monitoring with great interest the work on > VCAT/LCAS support in the IETF CCAMP WG, as we have done > prototyping work on control of VCAT/LCAS for interoperability > events in 2005 and 2007. As a result of our internal > discussion and prototyping work, we have identified a number > of requirements on VCAT/LCAS support that we believe are > important and may be helpful input to your work. > > In general, we agree with the requirements already identified > in draft-ietf-ccamp-gmpls-vcat-lcas-03.txt. Please note that this draft is now at the 06 revision and may be found as draft-ietf-ccamp-gmpls-vcat-lcas-06.txt > The following have been identified as important functionality > for control plane support for VCAT/LCAS that is not currently > identified in the CCAMP draft: > > - Ability to identify link endpoint capabilities associated > with VCAT such as support of LCAS functionality > - Possible additional requirement on ASON routing support > to be taken into account in CCAMP work on ASON routing > extensions rather than the VCAT/LCAS draft itself > - This might be generalizable to advertising inverse > multiplexing capabilities in addition to VCAT/LCAS CCAMP did consider extensions to IGPs to distribute inverse multiplexing, VCAT, and LCAS capabilities. This information would allow the initiator of a VCG to understand the capabilities of the egress that it is attempting to connect to. However, we decided that the LSP will not be set up to a different destination based on the VCAT capabilities. The LSP is required between a pair of LSRs, and there is no benefit to routing in distributing the end-point capabilities. Thus, we decided that if any negotiation is needed, it should be performed on the Call. > - Clean separation of VCG (VCAT Group) control from the > control of VCG members > - Supports the ability to create and modify the VCG > independent of its members We believe that this is exactly what our draft does. > - Supports potentially different sequences of creation, > e.g., creation of members first followed by VCG creation > or creation of VCG first followed by its members We believe that the ITU Recommendations that define VCAT do not support this behavior. We are also not convinced that this would be a valid way of operating a network - trails are not created on the off-chance that they will be used as part of a VCG at some time in the future. > - A single separate signaling session associated with the > VCG is an approach that has been prototyped successfully > in OIF interop events and may be a possible approach. While the use of a separate signaling session to establish the VCG is a fine way to conduct an experiment to establish data plane interoperability, this is not a good architectural solution for RSVP-TE. The signaling exchange of an RSVP-TE Path and Resv message is intended to establish an LSP. The coordination between end points for VCAT is far closer to the processes necessary for a Call, and that is why we have used the RSVP-TE Notify message exchange in our draft. > - We believe the current approach in the CCAMP draft has > limitations in this respect due to the incorporation of > multiple VCGs within a single call, as this does not > cleanly separate the VCG state and the state of its > component members. We suggest that CCAMP consider using a > single call per VCG instead, based on our prototyping > experiences. This may reflect some misunderstanding of the CCAMP draft. The draft currently allows a one-to-one correlation between Call and VCG. Component members are, of course, associated with the VCG and so the state of the component members is directly associated with the state of the VCG itself. > - Separation of VCG and member sessions will allow > unambiguous semantics for VCG characteristics vs. member > characteristics such as support of recovery modes Again, this may represent some misunderstanding of the CCAMP draft. The draft allows each LSP (VCG member) to be maintained with distinct characteristics. > - Ability to identify VCG members within VCG-related > signaling > - Note that it may be common in ASON environments for a VCG > connection to span multiple domains and RSVP sessions in > series, in which case session-specific objects such as > the LSP ID and Tunnel ID are not guaranteed to have > unique values end-to-end > - Manipulation of VCG characteristics requires the ability > to clearly and unambiguously identify the VCG members at > each end of the VCG We note that "session shuffling" is peculiar to the OIF way of addressing the ASON architecture, and the CCAMP working group has previously expressed its view that such a way of building a network, while functional, is not advisable. Since the OIF presumably has a solution to the fact that any one connection must be unambiguously identifiable at each end of the connection, we do not consider that the problem is exacerbated by the construction of a VCG. Indeed, session shuffling can only work if there is a consistent, coherent, repeatable, and reversible mapping of the various parameters (such as addresses, Tunnel ID, and LSP ID) at domain boundaries. That said, we believe that the ASON architecture is currently struggling with issues of diverse routes of connections that provide protection. It has normally been the case that protection is terminated at domain boundaries (at E-NNIs), and this may also be the case for VCGs. > - Ability to maintain VCG state across control plane failures > - It is important to be able to maintain the VCG in the > event of temporary loss of control plane connectivity or > control plane state > - We believe that graceful restart-like capabilities in > RSVP need to be supported to maintain VCG state across > control plane failure. You are correct that the control plane state must be recoverable after control plane component restart, and must be resynchronized after control plane connectivity recovery. Further, the data plane state must not be perturbed by control plane failure or restart. Graceful restart is a standard part of GMPLS RSVP-TE. It can be found in RFC 5063. A more detailed description (including a discussion of the handling of multiple failures) can be found in draft-ietf-ccamp-gr-description-03.txt which is currently being reviewed by the IESG prior to publication as an RFC. Restart processing for GMPLS Calls is covered in RFC 4974. The VCAT work simply re-uses these mechanisms and no further description is required. Regards, Adrian Farrel and Deborah Brungard IETF CCAMP Working Group Co-Chairs Envelope-to: ccamp-data0@psg.com Delivery-date: Mon, 15 Dec 2008 13:33:14 +0000 Message-ID: <6A12E0AF275D406DA16B7FBC738DE025@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Draft response to OIF on MEF-Related Work Date: Mon, 15 Dec 2008 13:32:04 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Hi, Please also comment on this draft response to the OIF. Thanks, Adrian === Dear Lyndon, In your communication oif2008.063.02.pdf dated February 14, 2008 you noted: > Finally, we noted the discussion on the CCAMP mailing list > regarding the computation of the Length field for TLVs, > especially for the Ethernet Bandwidth Profile TLV used in > the Ethernet Traffic Parameters draft. As this draft is > considered to be very important for support of MEF defined > Ethernet services, we request that this issue be resolved > as soon as possible within CCAMP. > > Our preference would be to compute the Length field for all > TLVs (except those in RFC 4420) based on the full TLV rather > than the Value alone, as this is the method commonly used in > the past for length computation in RSVP. Please note that RFC 4420 has been revised as draft-ietf-ccamp-rfc4420-bis-03.txt. This draft is in the RFC Editor's queue, and will shortly be published as an RFC that obsoletes RFC 4420. The change is to make the processing of all RSVP-TE TLVs consistent so that the Length field accounts for the full length of the TLV. This change has also been incorporated into the work on traffic parameters for Ethernet as described in draft-ietf-ccamp-ethernet-traffic-parameters-06.txt. You will be pleased to hear that we consider our work on MEF- related protocol extensions to be stable, and we will shortly issue working group last calls on the following drafts: draft-ietf-ccamp-ethernet-traffic-parameters-06.txt draft-ietf-ccamp-gmpls-ether-svcs-02.txt draft-ietf-ccamp-gmpls-mef-uni-01.txt draft-ietf-ccamp-gmpls-dcsc-channel-ext-00.txt In view of the imminent last call on this work, we would welcome any input from OIF members. Input should be made either by official communication from the OIF, or by email from any individual to the CCAMP mailing list (subscription details are found at http://www.ietf.org/html.charters/ccamp-charter.html). Best regards, Adrian Farrel and Deborah Brungard IETF CCAMP Working Group Co-Chairs Envelope-to: ccamp-data0@psg.com Delivery-date: Mon, 15 Dec 2008 13:16:16 +0000 Message-ID: Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Draft Response to OIF on Resv Usage Date: Mon, 15 Dec 2008 13:15:04 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Hi, We (well, mainly Deborah and I) have been delinquent in responding to the OIF's communication http://www.olddog.co.uk/oif2008_063_02.pdf Here is a draft response. Please comment this week and we will send the response as a Christmas present. Thanks, Adrian === Dear Lyndon, CCAMP owes the OIF responses to several communications. Apologies for the delay in producing formal responses. The issues raised were discussed at some length during the months after we received the communication both on and off the CCAMP mailing list, and I know you were involved in some of those discussions, but we forgot to send the formal responses. We will generate a series of responses with the technical issues broken out into separate threads. This first one addresses the issue of Resv usage during make-before-break as raised in oif2008.063.02.pdf. Best regards, Adrian Farrel and Deborah Brungard IETF CCAMP Working Group Co-chairs --- > OIF thanks CCAMP for its prompt and very informative response > to our liaison on OIF interoperability demo findings, sent > from our 4Q2007 meeting. We appreciate CCAMP's offer to use > the CCAMP mailing list for questions during our demo planning > and testing, although more structured liaisons are still > useful in our view to reflect meeting results and issues or > comments that are agreed across OIF members (as opposed to > individual views). [SNIP] > Based on your response liaison, it is our understanding that > per-LSP RESV messages should be expected for the "make- > before-break" scenario of modification. However, some members > have commented that it appears to be possible in the > specifications to use a single RESV message for multiple LSPs > because: > a) RFC 2205 allows the RESV message to carry multiple > FILTER_SPEC objects, specifically with the Shared Explicit > (SE) style that supports reservation sharing; and > b) The FILTER_SPEC object was extended in RFC 3209 to carry > the LSP_ID. > > Clarification would be appreciated as to whether we should > allow for receiving a single RESV message with multiple > FILTER_SPEC objects in the "make-before-break" scenario using > the SE style. We believe this issue is substantially the same as the following issue raised in the OIF correspondence dated November 29, 2007 with the subject "Liaison to IETF Regarding 2007 Interop Test Findings". Here you wrote: >> - 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 our response, dated January 3, 2008, we stated: >> 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. To help clarify this point, we draw your attention to RFC 3209 which states: The SESSION object uniquely defines a traffic engineered tunnel. The SENDER_TEMPLATE and FILTER_SPEC objects carry an LSP ID. The SENDER_TEMPLATE (or FILTER_SPEC) object together with the SESSION object uniquely identifies an LSP tunnel. As LSP tunnels (or LSPs for short) are identified using different LSP IDs (as carried in SENDER_TEMPLATE and FILTER_SPEC objects) and each LSP is signaled independently, multiple FILTER_SPEC objects SHOULD NOT be allowed as part of make-before-break. Envelope-to: ccamp-data0@psg.com Delivery-date: Mon, 15 Dec 2008 12:29:46 +0000 Message-ID: Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Working group last call draft-ietf-ccamp-gmpls-ason-routing-ospf-06.txt Date: Mon, 15 Dec 2008 12:27:37 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit This email starts the working group last call on draft-ietf-ccamp-gmpls-ason-routing-ospf-06.txt The last call will run for three weeks to give people a little extra time over the Christmas period. Thus the call will end on 5th January 2009 at noon GMT. Please send your comments to the CCAMP mailing list. Note that the I-D is positioned as Experimental. This is appropriate for a modification to the use of a routing protocol where we do not have significant experience of the impact of the change to the way the routing protocol works. Thanks, Adrian PS. This will be copied to the OSPF working group. Envelope-to: ccamp-data0@psg.com Delivery-date: Fri, 12 Dec 2008 21:28:02 +0000 Date: Fri, 12 Dec 2008 15:26:14 -0600 From: Lucy Yong Subject: RE: comments on the draft of LSP hierarchy To: 'Adrian Farrel' , shiomoto.kohei@lab.ntt.co.jp, ccamp@ops.ietf.org Message-id: <004701c95ca0$43a24300$470c7c0a@china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AclaI4NNnWYmsreJQ6Wr85050l8E1gCdVhqw Hi Adrian, I would like to clarify on the use of IGP instance Identifier. If there is no such TLV listed in LSP_TUNNEL_INFERFACE_ID object, the LSP is to be advertised in the same instance of the IGP as was used to advertise the TE links that the LSP traverse, or If there are such TLVs listed in LSP_TUNNEL_INFERFACE_ID object, the LSP is to be advertised in those IGPs in TLV list. In order to advertise in the IGP as was used to advertise the TE links that the LSP traverses, an TLV has to be used but just fill value as 0xffffff. Is my understanding correct? I think how client/server network (1.1.6) can apply to inter AS case. In this case, the LSP is created in server network (IGP A) as inter-AS link between AS B and AS C. Each end point of LSP connects IGP B and IGP C, respectively, i.e. one end need to advertise in IGP B and another end advertises in IGP C. In this case, only ingress end point needs to know its side IGP identifier so no needs to list IGP B and IGP C in TLVs. But we also don't want to advertise this LSP in the IGP A. Can we address this case? Regards, Lucy > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: Tuesday, December 09, 2008 11:27 AM > To: Lucy Yong; shiomoto.kohei@lab.ntt.co.jp; ccamp@ops.ietf.org > Subject: Re: comments on the draft of LSP hierarchy > > Hi Lucy, > > >> > 1) When LSP is used for Client/Server Network: the server network sets > >> > LSP as private link with one or more client IGP instances; When LSP > >> > is used as routing adjacency: the network sets LSP as non-private link > >> > with routing adjacency. Is this correct? > >> > >> I think that if the link is private, there is no need and possibly no > >> meaning to set a client IGP instance. Setting an IGP instance implies > >> that > >> the link is to be advertised in some IGP instance, and a private link > >> will > >> not be advertised. > > > > [Lucy:] I though that signaling is within an IGP (say IGP A). So if > > signaling a LSP for client/server network (say IGP B), RSVP needs set > > action > > as private link (not adv in IGP A), FA, and lists other IGP instances (IGP > > B). It seems my understanding is not correct. > > Are you saying that RSVP signaling is not tight to an IGP instance? > > Without > > using private link indication, how does the LSA of IGP A know if it should > > advertise in IGP A or not? > > I am a bit confused by your question. > > When an LSP is signaled in RSVP-TE it can be used to create a link in one or > more other networks. > > If the link is to be advertised in the same instance of the IGP that was > used to advertise the links that were used by RSVP-TE when it signaled the > LSP, then this is a Forwarding Adjacency as already described. > > If the link is to be advertised in a separate instance of an IGP (perhaps an > IGP that advertises links in another network layer) then the IGP instance is > indicated in the signaling message used to set up the LSP as described in > this draft. > > If the link is not to be advertised (i.e. is a private link) then you do not > include the IGP instance because it is not needed. > > >> > 3) A component link in a link bundle has component link identifier. > >> > This > >> > identifier is the link ID that is advertised in LSA. Is that correct? > >> > >> Section 2.4 says... > >> > >> When an LSP is to be used as a component link of a link bundle, the > >> LSP_TUNNEL_INTERFACE_ID object refers to the bundle indicating how > >> the bundle is addressed and used, and a new TLV indicates the > >> component link identifier for the link that the LSP creates. > >> > >> Only the component link identifier is advertised by the IGP. The > >> component > >> link identifier is used locally (between link end points), but may also > >> be > >> present in an ERO and RRO in signaling with the assumption that this > >> inormaiton is coordinated by some other means. > > > > [Lucy:] If component link identifier is used locally, why does it be > > advertised in the IGP? > > I'm sorry, I mistyped (that will teach me to try to write emails to you > while concentrating on ITU-T politics ;-) > > I should have written... > > Only the *bundle* link identifier is advertised by the IGP. The component > link identifier is used locally (between link end points), but may also be > present in an ERO and RRO in signaling with the assumption that this > information is coordinated by some other means. > > >> > 4) In section 3.3, it states: > >> > > >> > If the B-flag in the Actions field of the LSP_TUNNEL_INTERFACE_ID > >> > object is set, the other fields of the object apply to the link > >> > bundle itself. That is, the interface identifiers (numbered or > >> > unnumbered) and the other flags in the Actions field apply to the > >> > link bundle and not to the component link that the LSP will form. > >> > > >> > Furthermore, the IGP Instance Identifier TLV (if present) also > >> > applies to the link bundle and not to the component link. > >> > > >> > It seems odd way to set actions for link bundle. Should we first set > >> > the > >> > link bundle with the action, then add component link to the link bundle > >> > without action? > >> > >> The issue is that the link bundle itself is not signaled. Only the > >> component links correspond to LSPs that are signaled. Thus, > >> when the first component link is signaled, there is no link bundle > >> in existence. > > > > [Lucy:] Yes, it is the issue. Would it be nice to have a way to signal a > > link bundle first? It can apply to composite link as well. > > You could come up with a way to do that. You should not use LSP signaling to > do this - the bundle or composite link should not be known at transit points > of the LSP. You might want to use a GMPLS call to achieve this function if > (and only if?) the bundle/composite link needs to be communicated in > advance. > > > If we stay as it is, when adding the second component link to a link > > bundle, > > RSVP has to make sure all the actions have to be the exact same, is that > > right? Or we only require the first signaled component link to indicate a > > link bundle properties. > > I think that might depend on application. > > > If we want to add a component link in a link bundle to an IGP instance, we > > will use LSP_TUNNEL_INTERFACE_ID with IGP TLV and component link TLV, > how > > to > > distinguish two type of TLV within an LSP_TUNNEL_INTERFACE_ID object? > > They have different TLV type values. > > >> > 6) For CTG scenarios, we create a set of LSPs to form a single > >> > composite > >> > link to client/server network. We can first create a composite link as > >> > a > >> > private link with one or more client IGP instances with (at least one > >> > component link); then individual component link can be added to and > >> > removed from the composite link. Component links are also private link > >> > (different from component link in link bundle) and have different TE > >> > properties. We can also create composite link for routing adjacency > >> > (single IGP case). We need some extension to cover these scenarios. > >> > Could we consider adding this into the document? > >> > >> I believe that the mechanisms in the hierarchy bis draft will be > >> applicable to the creation of LSPs that are used as components of > >> CTGs. In my view (as an author) it would be premature to add this > >> to the draft at this stage as it would create a normative reference to > >> the CTG work which has not yet been adopted by any working group > >> and is bound to take some time to complete. > > > > [Lucy:] Operator want to implement CTG soon and hope the framework and > > requirement draft can be completed soon. Although CTG can be manually > > configured at beginning, it would be nice to have an GMPLS way to > > configure > > it as well. > > Yes. I agree. > > Hence my proposal below. > > >> My preferred approach is that the hierarchy bis draft creates the > >> framework and a registry of actions carried in the flags field (see > >> section 5.2). > >> Any new work, such as your CTG work, can then request the > >> allocation of a further bit and can define the behavior if the bit > >> is set. > > > > [Lucy:] Thank you for the suggestion. > > Regards, > Adrian > Envelope-to: ccamp-data0@psg.com Delivery-date: Fri, 12 Dec 2008 03:38:12 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C95C0A.9E8A562A" Subject: RE: new version of LSP DPPM draft Date: Fri, 12 Dec 2008 04:32:16 +0100 Message-ID: Thread-Topic: new version of LSP DPPM draft thread-index: AclZ7PlBrPqlTUMORfGBmVQ8cLKXhgCHUGWy From: "Monique Morrow (mmorrow)" To: "Adrian Farrel" , Cc: DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=11160; t=1229052905; x=1229916905; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mmorrow@cisco.com; z=From:=20=22Monique=20Morrow=20(mmorrow)=22=20 |Subject:=20RE=3A=20new=20version=20of=20LSP=20DPPM=20draft |Sender:=20; bh=nUbqLWSgrEpXQIieQQxKmWGM4/8BC+MBqaRLw8eKIz0=; b=EYeT2J8ZY7mBHBAgDl2SGG6rhuzx7TTm5nb2c29UbWfRj8I6vZxUB5set5 yKBug+uCEikiqWSuSUTpksUPRoJnVt+LkSaZ3I9CC73n8xxOOWZflJE3c6xi yr96pUNN/C; Authentication-Results: ams-dkim-2; header.From=mmorrow@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); This is a multi-part message in MIME format. ------_=_NextPart_001_01C95C0A.9E8A562A Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Adrian, 1. Thanks for the forward. 2. Observation: nice productive dialogue on the technical merits of the = draft=20 Best/m Monique Jeanne Morrow SP APAC CTO/Distinguished Consulting Engineer -----Original Message----- From: owner-ccamp@ops.ietf.org on behalf of Adrian Farrel Sent: Tue 12/9/2008 2:56 AM To: ccamp@ops.ietf.org Subject: Fw: new version of LSP DPPM draft =20 Forwarded on behalf of Guoying Zhang: ----- Original Message -----=20 From: "gyzhang" Sent: Tuesday, December 09, 2008 2:14 AM Subject: new version of LSP DPPM draft Hi all, A new version of DPPM draft (LSP Dynamic Provisioning Performance = Metrics in=20 GMPLS Networks) has just been posted on the IETF website. This draft was = discussed in the Dublin meeting. The authors have now updated the draft=20 according to the discussions during and after the meeting. The following = are=20 the summary of discussion and modifications made to the draft. 1. During and after the meeting, some discussion was made about the = data=20 plane and control plane synchronization. Thanks to Adrian, some rules=20 clarifying their relations were identified in existing documents. (1) Three documents stated the rules in the forward direction RFC 3471 section 3.4: an ingress node should not transmit data traffic = on a=20 suggested label until the downstream node passes a label upstream. The=20 implication here is that an ingress node may (safely) start to transmit = data=20 when it receives a label in a Resv message. This also shows in RFC 3473 section 2.5: An ingress node SHOULD NOT=20 transmit data traffic using a suggested label until the downstream node=20 passes a corresponding label upstream. Also in RFC3209 section 4.1.1.1: The node then sends the new LABEL = object=20 as part of the Resv message to the previous hop. The node SHOULD be = prepared=20 to forward packets carrying the assigned label prior to sending the Resv = message. "before" is very telling. It means that the XC must be in place = to=20 forward traffic before Resv is sent. (2) For the reverse direction We have RFC 3473 section 3.1: The Upstream_Label object MUST indicate a=20 label that is valid for forwarding at the time the Path message is sent. = "valid for forwarding" should be taken to mean that it is OK to receive = data=20 and it will be forwarded. But it can also be taken to mean "acceptable = for=20 use" i.e. available to be cross-connected. This is clarified later in RFC 3473 section 3.1: Terminator nodes = process=20 Path messages as usual, with the exception that the upstream label can=20 immediately be used to transport data traffic associated with the LSP=20 upstream towards the initiator. This is pretty clear. When a Path = message=20 has been fully processed by an egress node, it is completely safe to=20 transmit data toward the ingress (i.e. reverse path data). (3) To clarify this assumption (that the these rules are followed) we=20 include the following text into the discussion section (section 15) This document assumes that the correct procedures for installing the = data=20 plane are followed as described in [RFC3209], [RFC3471], and [RFC3473]. = That=20 is, that by the time the egress receives and processes a Path message, = it is=20 safe for the egress to transmit data on the reverse path, and that by = the=20 time the ingress receives and processes a Resv message it is safe for = the=20 ingress to transmit data on the forward path. This document does not = include=20 any verification that the implementations of the control plane software = are=20 conformant, although such tests could be constructed with the use of=20 suitable signal generation test equipment. 2. During the Dublin meeting, the authors raised the open issue of = using=20 two way signaling or three way signaling. After some discussions within = the=20 editor team, an agreement has been reached and the following text was = added=20 to the discussion section (section 15) o Bidirectional LSPs may be setup using three way signaling, where the = initiate node will send a RESV_CONF message downstream upon receiving = the=20 RESV message. The RESV_CONF message is used to notify the terminate node = that it can transfer data upstream. Actually, both directions should be=20 ready to transfer data when the RESV message is received by the initiate = node. Therefore, the bidirectional LSP setup delay defined in this = document,=20 does not take the confirmation procedure into account. We thank to Lou, Igor and Adrian for their valuable comments and = discussions=20 during and after the meeting. The authors would like to have more = experts=20 from the WG to review this draft. And we hope to request a WG last call=20 soon. best regards, ????????Guoying Zhang ????????gyzhang@sina.com ??????????2008-12-08 ------_=_NextPart_001_01C95C0A.9E8A562A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: new version of LSP DPPM draft

Adrian,

1. Thanks for the forward.

2. Observation: nice productive dialogue on the technical merits of the = draft

Best/m



Monique Jeanne Morrow
SP APAC CTO/Distinguished Consulting Engineer



-----Original Message-----
From: owner-ccamp@ops.ietf.org on behalf of Adrian Farrel
Sent: Tue 12/9/2008 2:56 AM
To: ccamp@ops.ietf.org
Subject: Fw: new version of LSP DPPM draft

Forwarded on behalf of Guoying Zhang:

----- Original Message -----
From: "gyzhang" <gyzhang@sina.com>
Sent: Tuesday, December 09, 2008 2:14 AM
Subject: new version of LSP DPPM draft


Hi all,

A new version of DPPM draft (LSP Dynamic Provisioning Performance = Metrics in
GMPLS Networks) has just been posted on the IETF website. This draft = was
discussed in the Dublin meeting. The authors have now updated the = draft
according to the discussions during and after the meeting. The following = are
the summary of discussion and modifications made to the draft.

 1. During and after the meeting, some discussion was made about = the data
plane and control plane synchronization. Thanks to Adrian, some = rules
clarifying their relations were identified in existing documents.

 (1) Three documents stated the rules in the forward direction
RFC 3471 section 3.4: an ingress node should not transmit data traffic = on a
suggested label until the downstream node passes a label upstream. = The
implication here is that an ingress node may (safely) start to transmit = data
when it receives a label in a Resv message.

 This also shows in RFC 3473 section 2.5:  An ingress node = SHOULD NOT
transmit data traffic using a suggested label until the downstream = node
passes a corresponding label upstream.

 Also in RFC3209 section 4.1.1.1: The node then sends the new LABEL = object
as part of the Resv message to the previous hop. The node SHOULD be = prepared
to forward packets carrying the assigned label prior to sending the = Resv
message. "before" is very telling. It means that the XC must = be in place to
forward traffic before Resv is sent.

 (2) For the reverse direction
We have RFC 3473 section 3.1: The Upstream_Label object MUST indicate = a
label that is valid for forwarding at the time the Path message is = sent.
"valid for forwarding" should be taken to mean that it is OK = to receive data
and it will be forwarded. But it can also be taken to mean = "acceptable for
use" i.e. available to be cross-connected.

 This is clarified later in RFC 3473 section 3.1: Terminator nodes = process
Path messages as usual, with the exception that the upstream label = can
immediately be used to transport data traffic associated with the = LSP
upstream towards the initiator. This is pretty clear. When a Path = message
has been fully processed by an egress node, it is completely safe to
transmit data toward the ingress (i.e. reverse path data).

  (3) To clarify this assumption (that the these rules are = followed) we
include the following text into the discussion section (section 15)
This document assumes that the correct procedures for installing the = data
plane are followed as described in [RFC3209], [RFC3471], and [RFC3473]. = That
is, that by the time the egress receives and processes a Path message, = it is
safe for the egress to transmit data on the reverse path, and that by = the
time the ingress receives and processes a Resv message it is safe for = the
ingress to transmit data on the forward path. This document does not = include
any verification that the implementations of the control plane software = are
conformant, although such tests could be constructed with the use of
suitable signal generation test equipment.


 2. During the Dublin meeting, the authors raised the open issue of = using
two way signaling or three way signaling. After some discussions within = the
editor team, an agreement has been reached and the following text was = added
to the discussion section (section 15)

  o Bidirectional LSPs may be setup using three way signaling, = where the
initiate node will send a RESV_CONF message downstream upon receiving = the
RESV message. The RESV_CONF message is used to notify the terminate = node
that it can transfer data upstream. Actually, both directions should = be
ready to transfer data when the RESV message is received by the = initiate
node. Therefore, the bidirectional LSP setup delay defined in this = document,
does not take the confirmation procedure into account.


We thank to Lou, Igor and Adrian for their valuable comments and = discussions
during and after the meeting. The authors would like to have more = experts
from the WG to review this draft. And we hope to request a WG last = call
soon.

 best regards,
 ????????Guoying Zhang
 ????????gyzhang@sina.com
 ??????????2008-12-08

------_=_NextPart_001_01C95C0A.9E8A562A-- Envelope-to: ccamp-data0@psg.com Delivery-date: Thu, 11 Dec 2008 23:14:00 +0000 To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: RFC 5316 on ISIS Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, ccamp@ops.ietf.org Message-Id: <20081211231226.543C21A5483@bosco.isi.edu> Date: Thu, 11 Dec 2008 15:12:26 -0800 (PST) A new Request for Comments is now available in online RFC libraries. RFC 5316 Title: ISIS Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering Author: M. Chen, R. Zhang, X. Duan Status: Standards Track Date: December 2008 Mailbox: mach@huawei.com, zhangrenhai@huawei.com, duanxiaodong@chinamobile.com Pages: 19 Characters: 45408 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ccamp-isis-interas-te-extension-04.txt URL: http://www.rfc-editor.org/rfc/rfc5316.txt This document describes extensions to the ISIS (ISIS) protocol to support Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (TE) for multiple Autonomous Systems (ASes). It defines ISIS-TE extensions for the flooding of TE information about inter-AS links, which can be used to perform inter- AS TE path computation. No support for flooding information from within one AS to another AS is proposed or defined in this document. [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-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute Envelope-to: ccamp-data0@psg.com Delivery-date: Thu, 11 Dec 2008 01:38:40 +0000 Message-ID: <49406E90.1090105@cn.kddilabs.jp> Date: Thu, 11 Dec 2008 10:36:16 +0900 From: "Ogaki, Kenichi" User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: ccamp@ops.ietf.org Subject: Re: I-D Action:draft-ietf-ccamp-ethernet-gmpls-provider-reqs-01.txt Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Hello All, Please find the new revision (01) of "Service Provider Requirements for Ethernet control with GMPLS". We have added some new sections, (4.1.3. Addressing) 4.2.4. Asymmetric bandwidth 4.2.5. QoS control. and modified some texts in 4.2.3. P2MP and MP2MP requirements 4.4. Protection and Restoration related functionality. We would welcome your feedback and thoughts. Best regards, Yoshiaki & Kenichi Internet-Drafts@ietf.org wrote: > 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 : Service Provider Requirements for Ethernet control with GMPLS > Author(s) : W. Imajuku, et al. > Filename : draft-ietf-ccamp-ethernet-gmpls-provider-reqs-01.txt > Pages : 19 > Date : 2008-12-10 > > Generalized Multi-Protocol Label Switching (GMPLS) is applicable to > Ethernet switches supporting Provider Backbone Bridge Traffic > Engineering (PBB-TE) networks. The GMPLS controlled Ethernet label > switch network not only automates creation of Ethernet Label Switched > Paths(Eth-LSPs), it also provides sophisticated Eth-LSP recovery > Mechanisms such as protection and restoration of an Eth-LSP. This > document describes the requirements for the set of solutions of GMPLS > controlled Ethernet label switch networks. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ethernet-gmpls-provider-reqs-01.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > 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://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > Envelope-to: ccamp-data0@psg.com Delivery-date: Wed, 10 Dec 2008 18:01:07 +0000 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org Subject: I-D Action:draft-ietf-ccamp-ethernet-gmpls-provider-reqs-01.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081210180001.BBFC43A6847@core3.amsl.com> Date: Wed, 10 Dec 2008 10:00:01 -0800 (PST) --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 : Service Provider Requirements for Ethernet control with GMPLS Author(s) : W. Imajuku, et al. Filename : draft-ietf-ccamp-ethernet-gmpls-provider-reqs-01.txt Pages : 19 Date : 2008-12-10 Generalized Multi-Protocol Label Switching (GMPLS) is applicable to Ethernet switches supporting Provider Backbone Bridge Traffic Engineering (PBB-TE) networks. The GMPLS controlled Ethernet label switch network not only automates creation of Ethernet Label Switched Paths(Eth-LSPs), it also provides sophisticated Eth-LSP recovery Mechanisms such as protection and restoration of an Eth-LSP. This document describes the requirements for the set of solutions of GMPLS controlled Ethernet label switch networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ethernet-gmpls-provider-reqs-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-ccamp-ethernet-gmpls-provider-reqs-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-12-10095041.I-D@ietf.org> --NextPart-- Envelope-to: ccamp-data0@psg.com Delivery-date: Wed, 10 Dec 2008 14:24:33 +0000 Message-ID: Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Fw: Letters of Invitation to IETF 74 now available to past attendees Date: Wed, 10 Dec 2008 14:22:43 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Alexa Morris" To: ; Sent: Tuesday, December 09, 2008 6:31 PM Subject: Letters of Invitation to IETF 74 now available to past attendees > If you need a letter of invitation (LOI) in order to obtain a visa to > come to IETF 74 in San Francisco -- and if you have attended at least > one IETF meeting in the past -- you can now request a LOI via this > webform: https://www.amsl.com/ietf/ietf74-loi.html. The LOI will be > sent to you via email unless you specifically request a hard copy. You > can also access the webform from the Meetings page of the IETF website. > > As soon as we officially open registration for the meeting, anyone who > registers for IETF 74 (regardless of whether or not they've attended a > past meeting) will be able to request and receive a letter of > invitation to attend. > > Regards, > Alexa > > ----------- > Alexa Morris / Executive Director / IETF > 48377 Fremont Blvd., Suite 117, Fremont, CA 94538 > Phone: +1.510.492.4089 / Fax: +1.510.492.4001 > Email: amorris@amsl.com > > Managed by Association Management Solutions (AMS) > Forum Management, Meeting and Event Planning > www.amsl.com > > Envelope-to: ccamp-data0@psg.com Delivery-date: Tue, 09 Dec 2008 23:43:48 +0000 Date: Tue, 09 Dec 2008 17:41:32 -0600 From: Lucy Yong Subject: RE: comments on the draft of LSP hierarchy To: 'Adrian Farrel' , shiomoto.kohei@lab.ntt.co.jp, ccamp@ops.ietf.org Message-id: <00b001c95a57$b04d4b80$470c7c0a@china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Thread-index: AclaI4NNnWYmsreJQ6Wr85050l8E1gAJ4VBg Hello Adrian, Thank again. See below. Regards, Lucy [Snipped] > > I am a bit confused by your question. > > When an LSP is signaled in RSVP-TE it can be used to create a link in one or > more other networks. [Lucy:] yes. > > If the link is to be advertised in the same instance of the IGP that was > used to advertise the links that were used by RSVP-TE when it signaled the > LSP, then this is a Forwarding Adjacency as already described. [Lucy:] I would like to better understand client/server network case (1.1.6). As described, the server network LSP does not form FA because client and server network run separate instances of the control plane routing protocols. Now, I guess "instances of the control plane routing protocols" are different from IGP instances. (I thought they mean the same before). Could you give an example to use LSP_TUNNEL_INTERFACE_ID object for a LSP that is created in one network and used in another network as a virtual link? > > [Snipped] > > I'm sorry, I mistyped (that will teach me to try to write emails to you > while concentrating on ITU-T politics ;-) > > I should have written... > > Only the *bundle* link identifier is advertised by the IGP. The component > link identifier is used locally (between link end points), but may also be > present in an ERO and RRO in signaling with the assumption that this > information is coordinated by some other means. [Lucy:] Make sense. So without this extension, operator has to configure component link identifier at link end points. So a component link in a link bundle is never advertised. > [snipped] > > > > [Lucy:] Yes, it is the issue. Would it be nice to have a way to signal a > > link bundle first? It can apply to composite link as well. > > You could come up with a way to do that. You should not use LSP signaling to > do this - the bundle or composite link should not be known at transit points > of the LSP. You might want to use a GMPLS call to achieve this function if > (and only if?) the bundle/composite link needs to be communicated in > advance. [Lucy:] All the actions are indications for LSP egress point not transit points, right? > > > If we stay as it is, when adding the second component link to a link > > bundle, > > RSVP has to make sure all the actions have to be the exact same, is that > > right? Or we only require the first signaled component link to indicate a > > link bundle properties. > > I think that might depend on application. > > > If we want to add a component link in a link bundle to an IGP instance, we > > will use LSP_TUNNEL_INTERFACE_ID with IGP TLV and component link TLV, > how > > to > > distinguish two type of TLV within an LSP_TUNNEL_INTERFACE_ID object? > > They have different TLV type values. [Lucy:] where are they specified? > Envelope-to: ccamp-data0@psg.com Delivery-date: Tue, 09 Dec 2008 17:28:27 +0000 Message-ID: Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Lucy Yong" , , Subject: Re: comments on the draft of LSP hierarchy Date: Tue, 9 Dec 2008 17:27:19 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Hi Lucy, >> > 1) When LSP is used for Client/Server Network: the server network sets >> > LSP as private link with one or more client IGP instances; When LSP >> > is used as routing adjacency: the network sets LSP as non-private link >> > with routing adjacency. Is this correct? >> >> I think that if the link is private, there is no need and possibly no >> meaning to set a client IGP instance. Setting an IGP instance implies >> that >> the link is to be advertised in some IGP instance, and a private link >> will >> not be advertised. > > [Lucy:] I though that signaling is within an IGP (say IGP A). So if > signaling a LSP for client/server network (say IGP B), RSVP needs set > action > as private link (not adv in IGP A), FA, and lists other IGP instances (IGP > B). It seems my understanding is not correct. > Are you saying that RSVP signaling is not tight to an IGP instance? > Without > using private link indication, how does the LSA of IGP A know if it should > advertise in IGP A or not? I am a bit confused by your question. When an LSP is signaled in RSVP-TE it can be used to create a link in one or more other networks. If the link is to be advertised in the same instance of the IGP that was used to advertise the links that were used by RSVP-TE when it signaled the LSP, then this is a Forwarding Adjacency as already described. If the link is to be advertised in a separate instance of an IGP (perhaps an IGP that advertises links in another network layer) then the IGP instance is indicated in the signaling message used to set up the LSP as described in this draft. If the link is not to be advertised (i.e. is a private link) then you do not include the IGP instance because it is not needed. >> > 3) A component link in a link bundle has component link identifier. >> > This >> > identifier is the link ID that is advertised in LSA. Is that correct? >> >> Section 2.4 says... >> >> When an LSP is to be used as a component link of a link bundle, the >> LSP_TUNNEL_INTERFACE_ID object refers to the bundle indicating how >> the bundle is addressed and used, and a new TLV indicates the >> component link identifier for the link that the LSP creates. >> >> Only the component link identifier is advertised by the IGP. The >> component >> link identifier is used locally (between link end points), but may also >> be >> present in an ERO and RRO in signaling with the assumption that this >> inormaiton is coordinated by some other means. > > [Lucy:] If component link identifier is used locally, why does it be > advertised in the IGP? I'm sorry, I mistyped (that will teach me to try to write emails to you while concentrating on ITU-T politics ;-) I should have written... Only the *bundle* link identifier is advertised by the IGP. The component link identifier is used locally (between link end points), but may also be present in an ERO and RRO in signaling with the assumption that this information is coordinated by some other means. >> > 4) In section 3.3, it states: >> > >> > If the B-flag in the Actions field of the LSP_TUNNEL_INTERFACE_ID >> > object is set, the other fields of the object apply to the link >> > bundle itself. That is, the interface identifiers (numbered or >> > unnumbered) and the other flags in the Actions field apply to the >> > link bundle and not to the component link that the LSP will form. >> > >> > Furthermore, the IGP Instance Identifier TLV (if present) also >> > applies to the link bundle and not to the component link. >> > >> > It seems odd way to set actions for link bundle. Should we first set >> > the >> > link bundle with the action, then add component link to the link bundle >> > without action? >> >> The issue is that the link bundle itself is not signaled. Only the >> component links correspond to LSPs that are signaled. Thus, >> when the first component link is signaled, there is no link bundle >> in existence. > > [Lucy:] Yes, it is the issue. Would it be nice to have a way to signal a > link bundle first? It can apply to composite link as well. You could come up with a way to do that. You should not use LSP signaling to do this - the bundle or composite link should not be known at transit points of the LSP. You might want to use a GMPLS call to achieve this function if (and only if?) the bundle/composite link needs to be communicated in advance. > If we stay as it is, when adding the second component link to a link > bundle, > RSVP has to make sure all the actions have to be the exact same, is that > right? Or we only require the first signaled component link to indicate a > link bundle properties. I think that might depend on application. > If we want to add a component link in a link bundle to an IGP instance, we > will use LSP_TUNNEL_INTERFACE_ID with IGP TLV and component link TLV, how > to > distinguish two type of TLV within an LSP_TUNNEL_INTERFACE_ID object? They have different TLV type values. >> > 6) For CTG scenarios, we create a set of LSPs to form a single >> > composite >> > link to client/server network. We can first create a composite link as >> > a >> > private link with one or more client IGP instances with (at least one >> > component link); then individual component link can be added to and >> > removed from the composite link. Component links are also private link >> > (different from component link in link bundle) and have different TE >> > properties. We can also create composite link for routing adjacency >> > (single IGP case). We need some extension to cover these scenarios. >> > Could we consider adding this into the document? >> >> I believe that the mechanisms in the hierarchy bis draft will be >> applicable to the creation of LSPs that are used as components of >> CTGs. In my view (as an author) it would be premature to add this >> to the draft at this stage as it would create a normative reference to >> the CTG work which has not yet been adopted by any working group >> and is bound to take some time to complete. > > [Lucy:] Operator want to implement CTG soon and hope the framework and > requirement draft can be completed soon. Although CTG can be manually > configured at beginning, it would be nice to have an GMPLS way to > configure > it as well. Yes. I agree. Hence my proposal below. >> My preferred approach is that the hierarchy bis draft creates the >> framework and a registry of actions carried in the flags field (see >> section 5.2). >> Any new work, such as your CTG work, can then request the >> allocation of a further bit and can define the behavior if the bit >> is set. > > [Lucy:] Thank you for the suggestion. Regards, Adrian Envelope-to: ccamp-data0@psg.com Delivery-date: Tue, 09 Dec 2008 16:32:50 +0000 Date: Tue, 09 Dec 2008 10:31:02 -0600 From: Lucy Yong Subject: RE: comments on the draft of LSP hierarchy To: 'Adrian Farrel' , shiomoto.kohei@lab.ntt.co.jp, ccamp@ops.ietf.org Message-id: <007c01c95a1b$87805080$470c7c0a@china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Thread-index: AclZ7Gp1u2Dz7I/lQSG3Zmi7gPu1BgAJgKew Hi Adrian, Thank very much for the explanation. See below. Regards, Lucy > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: Tuesday, December 09, 2008 4:51 AM > To: Lucy Yong; shiomoto.kohei@lab.ntt.co.jp; ccamp@ops.ietf.org > Subject: Re: comments on the draft of LSP hierarchy > > Hi Lucy, > > > I study through this draft and appreciate that you specify many necessary > > MLN scenarios that LSP can be used for. Some of them can apply to CTG > > (composite transport group) scenario. Here are some clarification and > > questions: > > > > 1) When LSP is used for Client/Server Network: the server network sets LSP > > as private link with one or more client IGP instances; When LSP is used as > > routing adjacency: the network sets LSP as non-private link with routing > > adjacency. Is this correct? > > I think that if the link is private, there is no need and possibly no > meaning to set a client IGP instance. Setting an IGP instance implies that > the link is to be advertised in some IGP instance, and a private link will > not be advertised. > [Lucy:] I though that signaling is within an IGP (say IGP A). So if signaling a LSP for client/server network (say IGP B), RSVP needs set action as private link (not adv in IGP A), FA, and lists other IGP instances (IGP B). It seems my understanding is not correct. Are you saying that RSVP signaling is not tight to an IGP instance? Without using private link indication, how does the LSA of IGP A know if it should advertise in IGP A or not? > > 2) Should section 2.2 add one more categories: -LSP is used as a component > > link in a link bundle? The doc. is described it but not considers it as > > category. > > Good catch. > The overview text was not updated to reflect updates to the main body. > I will update. > > > 3) A component link in a link bundle has component link identifier. This > > identifier is the link ID that is advertised in LSA. Is that correct? > > Section 2.4 says... > > When an LSP is to be used as a component link of a link bundle, the > LSP_TUNNEL_INTERFACE_ID object refers to the bundle indicating how > the bundle is addressed and used, and a new TLV indicates the > component link identifier for the link that the LSP creates. > > Only the component link identifier is advertised by the IGP. The component > link identifier is used locally (between link end points), but may also be > present in an ERO and RRO in signaling with the assumption that this > inormaiton is coordinated by some other means. [Lucy:] If component link identifier is used locally, why does it be advertised in the IGP? > > > 4) In section 3.3, it states: > > > > If the B-flag in the Actions field of the LSP_TUNNEL_INTERFACE_ID > > object is set, the other fields of the object apply to the link > > bundle itself. That is, the interface identifiers (numbered or > > unnumbered) and the other flags in the Actions field apply to the > > link bundle and not to the component link that the LSP will form. > > > > Furthermore, the IGP Instance Identifier TLV (if present) also > > applies to the link bundle and not to the component link. > > > > It seems odd way to set actions for link bundle. Should we first set the > > link bundle with the action, then add component link to the link bundle > > without action? > > The issue is that the link bundle itself is not signaled. Only the component > links correspond to LSPs that are signaled. Thus, when the first component > link is signaled, there is no link bundle in existence. [Lucy:] Yes, it is the issue. Would it be nice to have a way to signal a link bundle first? It can apply to composite link as well. If we stay as it is, when adding the second component link to a link bundle, RSVP has to make sure all the actions have to be the exact same, is that right? Or we only require the first signaled component link to indicate a link bundle properties. If we want to add a component link in a link bundle to an IGP instance, we will use LSP_TUNNEL_INTERFACE_ID with IGP TLV and component link TLV, how to distinguish two type of TLV within an LSP_TUNNEL_INTERFACE_ID object? > > > 5) LSA should not advertise LSP used as private link. Should this be > > explicitly stated in section 3.4? > > OK. > I'll add this to the definition of a private link in section 1.1.3. > > > 6) For CTG scenarios, we create a set of LSPs to form a single composite > > link to client/server network. We can first create a composite link as a > > private link with one or more client IGP instances with (at least one > > component link); then individual component link can be added to and > > removed > > from the composite link. Component links are also private link (different > > from component link in link bundle) and have different TE properties. We > > can > > also create composite link for routing adjacency (single IGP case). We > > need > > some extension to cover these scenarios. Could we consider adding this > > into > > the document? > > I believe that the mechanisms in the hierarchy bis draft will be applicable > to the creation of LSPs that are used as components of CTGs. In my view (as > an author) it would be premature to add this to the draft at this stage as > it would create a normative reference to the CTG work which has not yet been > adopted by any working group and is bound to take some time to complete. [Lucy:] Operator want to implement CTG soon and hope the framework and requirement draft can be completed soon. Although CTG can be manually configured at beginning, it would be nice to have an GMPLS way to configure it as well. > > My preferred approach is that the hierarchy bis draft creates the framework > and a registry of actions carried in the flags field (see section 5.2). Any > new work, such as your CTG work, can then request the allocation of a > further bit and can define the behavior if the bit is set. [Lucy:] Thank you for the suggestion. > > Cheers, > Adrian > Envelope-to: ccamp-data0@psg.com Delivery-date: Tue, 09 Dec 2008 11:00:37 +0000 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org Subject: I-D Action:draft-ietf-ccamp-lsp-hierarchy-bis-06.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081209110001.3B65E3A6AFD@core3.amsl.com> Date: Tue, 9 Dec 2008 03:00:01 -0800 (PST) --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 : Procedures for Dynamically Signaled Hierarchical Label Switched Paths Author(s) : K. Shiomoto, et al. Filename : draft-ietf-ccamp-lsp-hierarchy-bis-06.txt Pages : 28 Date : 2008-12-09 Label Switched Paths (LSPs) set up in Multiprotocol Label Switching (MPLS) or Generalized MPLS (GMPLS) networks can be used to form links for carrying traffic in those networks or in other (client) networks. Protocol extensions already exist to facilitate the establishment of an LSP as a numbered traffic engineering (TE) link within the same instance of the routing as is used to advertise the links that it traverses creating a Forwarding Adjacency (FA). This document extends those mechanisms to support unnumbered FAs. This document also defines how to indicate that an LSP should be advertised as a link in another instance of the routing protocol (for instance in a client network) and which instance to use. Furthermore, mechanisms are defined to indicate when an LSP is to be used as a component link of a TE link bundle and to identify the bundle.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 [RFC2119]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lsp-hierarchy-bis-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-ccamp-lsp-hierarchy-bis-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-12-09025228.I-D@ietf.org> --NextPart-- Envelope-to: ccamp-data0@psg.com Delivery-date: Tue, 09 Dec 2008 10:57:12 +0000 Message-ID: <4CE0322579F54648BAAC52322768DCC3@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Fw: new version of LSP DPPM draft Date: Tue, 9 Dec 2008 10:56:23 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="gb2312"; reply-type=original Content-Transfer-Encoding: 8bit Forwarded on behalf of Guoying Zhang: ----- Original Message ----- From: "gyzhang" Sent: Tuesday, December 09, 2008 2:14 AM Subject: new version of LSP DPPM draft Hi all, A new version of DPPM draft (LSP Dynamic Provisioning Performance Metrics in GMPLS Networks) has just been posted on the IETF website. This draft was discussed in the Dublin meeting. The authors have now updated the draft according to the discussions during and after the meeting. The following are the summary of discussion and modifications made to the draft. 1. During and after the meeting, some discussion was made about the data plane and control plane synchronization. Thanks to Adrian, some rules clarifying their relations were identified in existing documents. (1) Three documents stated the rules in the forward direction RFC 3471 section 3.4: an ingress node should not transmit data traffic on a suggested label until the downstream node passes a label upstream. The implication here is that an ingress node may (safely) start to transmit data when it receives a label in a Resv message. This also shows in RFC 3473 section 2.5: An ingress node SHOULD NOT transmit data traffic using a suggested label until the downstream node passes a corresponding label upstream. Also in RFC3209 section 4.1.1.1: The node then sends the new LABEL object as part of the Resv message to the previous hop. The node SHOULD be prepared to forward packets carrying the assigned label prior to sending the Resv message. "before" is very telling. It means that the XC must be in place to forward traffic before Resv is sent. (2) For the reverse direction We have RFC 3473 section 3.1: The Upstream_Label object MUST indicate a label that is valid for forwarding at the time the Path message is sent. "valid for forwarding" should be taken to mean that it is OK to receive data and it will be forwarded. But it can also be taken to mean "acceptable for use" i.e. available to be cross-connected. This is clarified later in RFC 3473 section 3.1: Terminator nodes process Path messages as usual, with the exception that the upstream label can immediately be used to transport data traffic associated with the LSP upstream towards the initiator. This is pretty clear. When a Path message has been fully processed by an egress node, it is completely safe to transmit data toward the ingress (i.e. reverse path data). (3) To clarify this assumption (that the these rules are followed) we include the following text into the discussion section (section 15) This document assumes that the correct procedures for installing the data plane are followed as described in [RFC3209], [RFC3471], and [RFC3473]. That is, that by the time the egress receives and processes a Path message, it is safe for the egress to transmit data on the reverse path, and that by the time the ingress receives and processes a Resv message it is safe for the ingress to transmit data on the forward path. This document does not include any verification that the implementations of the control plane software are conformant, although such tests could be constructed with the use of suitable signal generation test equipment. 2. During the Dublin meeting, the authors raised the open issue of using two way signaling or three way signaling. After some discussions within the editor team, an agreement has been reached and the following text was added to the discussion section (section 15) o Bidirectional LSPs may be setup using three way signaling, where the initiate node will send a RESV_CONF message downstream upon receiving the RESV message. The RESV_CONF message is used to notify the terminate node that it can transfer data upstream. Actually, both directions should be ready to transfer data when the RESV message is received by the initiate node. Therefore, the bidirectional LSP setup delay defined in this document, does not take the confirmation procedure into account. We thank to Lou, Igor and Adrian for their valuable comments and discussions during and after the meeting. The authors would like to have more experts from the WG to review this draft. And we hope to request a WG last call soon. best regards, ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡Guoying Zhang ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡gyzhang@sina.com ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡2008-12-08 Envelope-to: ccamp-data0@psg.com Delivery-date: Tue, 09 Dec 2008 10:54:27 +0000 Message-ID: <493E4E2E.2050600@pi.nu> Date: Tue, 09 Dec 2008 11:53:34 +0100 From: Loa Andersson User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Adrian Farrel CC: ccamp@ops.ietf.org Subject: Re: CCAMP drafts for adoption Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit support for all /Loa Adrian Farrel wrote: > Hi, > > Can you please express your opinion on the adoption of the following > three drafts as WG drafts. > > Thanks, > Adrian > > draft-takacs-ccamp-oam-configuration-fwk-01.txt > draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt > draft-bernstein-ccamp-wson-encode-01.txt (to become -rwa-encode-00) > > Cheers, > Adrian and Deborah > > -- Loa Andersson email: loa.andersson@redback.com Sr Strategy and Standards Manager loa@pi.nu Redback Networks phone: +46 8 632 77 14 An Ericsson Company Envelope-to: ccamp-data0@psg.com Delivery-date: Tue, 09 Dec 2008 10:53:22 +0000 Message-ID: <6FD613982F844ABDAE7193395355FB3A@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Lucy Yong" , , Subject: Re: comments on the draft of LSP hierarchy Date: Tue, 9 Dec 2008 10:50:37 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Hi Lucy, > I study through this draft and appreciate that you specify many necessary > MLN scenarios that LSP can be used for. Some of them can apply to CTG > (composite transport group) scenario. Here are some clarification and > questions: > > 1) When LSP is used for Client/Server Network: the server network sets LSP > as private link with one or more client IGP instances; When LSP is used as > routing adjacency: the network sets LSP as non-private link with routing > adjacency. Is this correct? I think that if the link is private, there is no need and possibly no meaning to set a client IGP instance. Setting an IGP instance implies that the link is to be advertised in some IGP instance, and a private link will not be advertised. > 2) Should section 2.2 add one more categories: -LSP is used as a component > link in a link bundle? The doc. is described it but not considers it as > category. Good catch. The overview text was not updated to reflect updates to the main body. I will update. > 3) A component link in a link bundle has component link identifier. This > identifier is the link ID that is advertised in LSA. Is that correct? Section 2.4 says... When an LSP is to be used as a component link of a link bundle, the LSP_TUNNEL_INTERFACE_ID object refers to the bundle indicating how the bundle is addressed and used, and a new TLV indicates the component link identifier for the link that the LSP creates. Only the component link identifier is advertised by the IGP. The component link identifier is used locally (between link end points), but may also be present in an ERO and RRO in signaling with the assumption that this inormaiton is coordinated by some other means. > 4) In section 3.3, it states: > > If the B-flag in the Actions field of the LSP_TUNNEL_INTERFACE_ID > object is set, the other fields of the object apply to the link > bundle itself. That is, the interface identifiers (numbered or > unnumbered) and the other flags in the Actions field apply to the > link bundle and not to the component link that the LSP will form. > > Furthermore, the IGP Instance Identifier TLV (if present) also > applies to the link bundle and not to the component link. > > It seems odd way to set actions for link bundle. Should we first set the > link bundle with the action, then add component link to the link bundle > without action? The issue is that the link bundle itself is not signaled. Only the component links correspond to LSPs that are signaled. Thus, when the first component link is signaled, there is no link bundle in existence. > 5) LSA should not advertise LSP used as private link. Should this be > explicitly stated in section 3.4? OK. I'll add this to the definition of a private link in section 1.1.3. > 6) For CTG scenarios, we create a set of LSPs to form a single composite > link to client/server network. We can first create a composite link as a > private link with one or more client IGP instances with (at least one > component link); then individual component link can be added to and > removed > from the composite link. Component links are also private link (different > from component link in link bundle) and have different TE properties. We > can > also create composite link for routing adjacency (single IGP case). We > need > some extension to cover these scenarios. Could we consider adding this > into > the document? I believe that the mechanisms in the hierarchy bis draft will be applicable to the creation of LSPs that are used as components of CTGs. In my view (as an author) it would be premature to add this to the draft at this stage as it would create a normative reference to the CTG work which has not yet been adopted by any working group and is bound to take some time to complete. My preferred approach is that the hierarchy bis draft creates the framework and a registry of actions carried in the flags field (see section 5.2). Any new work, such as your CTG work, can then request the allocation of a further bit and can define the behavior if the bit is set. Cheers, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 08 Dec 2008 22:35:01 +0000 Date: Mon, 08 Dec 2008 16:33:29 -0600 From: Lucy Yong Subject: comments on the draft of LSP hierarchy To: shiomoto.kohei@lab.ntt.co.jp, 'Adrian Farrel' , ccamp@ops.ietf.org Message-id: <008301c95984$ff315cb0$fd32fea9@china.huawei.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_G0bW96lybl6woaba+XqNvg)" Thread-index: AclZhP39QzvE+JOGR/WrwFTtiePzmg== This is a multi-part message in MIME format. --Boundary_(ID_G0bW96lybl6woaba+XqNvg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Shiomoto and Adrian, I study through this draft and appreciate that you specify many necessary MLN scenarios that LSP can be used for. Some of them can apply to CTG (composite transport group) scenario. Here are some clarification and questions: 1) When LSP is used for Client/Server Network: the server network sets LSP as private link with one or more client IGP instances; When LSP is used as routing adjacency: the network sets LSP as non-private link with routing adjacency. Is this correct? 2) Should section 2.2 add one more categories: -LSP is used as a component link in a link bundle? The doc. is described it but not considers it as category. 3) A component link in a link bundle has component link identifier. This identifier is the link ID that is advertised in LSA. Is that correct? 4) In section 3.3, it states: If the B-flag in the Actions field of the LSP_TUNNEL_INTERFACE_ID object is set, the other fields of the object apply to the link bundle itself. That is, the interface identifiers (numbered or unnumbered) and the other flags in the Actions field apply to the link bundle and not to the component link that the LSP will form. Furthermore, the IGP Instance Identifier TLV (if present) also applies to the link bundle and not to the component link. It seems odd way to set actions for link bundle. Should we first set the link bundle with the action, then add component link to the link bundle without action? 5) LSA should not advertise LSP used as private link. Should this be explicitly stated in section 3.4? 6) For CTG scenarios, we create a set of LSPs to form a single composite link to client/server network. We can first create a composite link as a private link with one or more client IGP instances with (at least one component link); then individual component link can be added to and removed from the composite link. Component links are also private link (different from component link in link bundle) and have different TE properties. We can also create composite link for routing adjacency (single IGP case). We need some extension to cover these scenarios. Could we consider adding this into the document? Cheers, Lucy --Boundary_(ID_G0bW96lybl6woaba+XqNvg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi Shiomoto and Adrian,

 

I study through this draft and appreciate that you specify many necessary MLN scenarios that LSP can be used for. Some of them can apply to CTG (composite transport group) scenario. Here are some clarification and questions:

1) When LSP is used for Client/Server Network: the server network sets LSP as private link with one or more client IGP instances; When LSP is used as routing adjacency: the network sets LSP as non-private link with routing adjacency. Is this correct?

2) Should section 2.2 add one more categories: -LSP is used as a component link in a link bundle? The doc. is described it but not considers it as category.

3) A component link in a link bundle has component link identifier. This identifier is the link ID that is advertised in LSA. Is that correct?

4) In section 3.3, it states:

 

   If the B-flag in the Actions field of the LSP_TUNNEL_INTERFACE_ID

   object is set, the other fields of the object apply to the link

   bundle itself. That is, the interface identifiers (numbered or

   unnumbered) and the other flags in the Actions field apply to the

   link bundle and not to the component link that the LSP will form.

 

   Furthermore, the IGP Instance Identifier TLV (if present) also

   applies to the link bundle and not to the component link.

 

It seems odd way to set actions for link bundle. Should we first set the link bundle with the action, then add component link to the link bundle without action?

 

5) LSA should not advertise LSP used as private link. Should this be explicitly stated in section 3.4?

 

6) For CTG scenarios, we create a set of LSPs to form a single composite link to client/server network. We can first create a composite link as a private link with one or more client IGP instances with (at least one component link); then individual component link can be added to and removed from the composite link. Component links are also private link (different from component link in link bundle) and have different TE properties. We can also create composite link for routing adjacency (single IGP case). We need some extension to cover these scenarios. Could we consider adding this into the document?

 

Cheers,

Lucy

 

 

 

--Boundary_(ID_G0bW96lybl6woaba+XqNvg)-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 08 Dec 2008 02:17:20 +0000 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org Subject: I-D Action:draft-ietf-ccamp-lsp-dppm-03.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081208021501.E06AE3A69B3@core3.amsl.com> Date: Sun, 7 Dec 2008 18:15:01 -0800 (PST) --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 : Label Switched Path (LSP) Dynamic Provisioning Performance Metrics in Generalized MPLS Networks Author(s) : W. Sun, et al. Filename : draft-ietf-ccamp-lsp-dppm-03.txt Pages : 48 Date : 2008-12-04 Generalized Multi-Protocol Label Switching (GMPLS) is one of the most promising candidate technologies for future data transmission network. GMPLS has been developed to control and operate different kinds of network elements, such as conventional routers, switches, Dense Wavelength Division Multiplexing (DWDM) systems, Add- Drop Multiplexors (ADMs), photonic cross-connects (PXCs), optical cross- connects (OXCs), etc. Dynamic provisioning ability of these physically diverse devices differs from each other drastically. At the same time, the need for Dynamicly provisioned connections is increasing because optical networks are being deployed in metro areas. As different applications have varied requirements in the provisioning performance of optical networks, it is imperative to define standardized metrics and procedures such that the performance of networks and application needs can be mapped to each other. This document provides a series of performance metrics to evaluate the dynamic LSP provisioning performance in GMPLS networks, specifically the Dynamic LSP setup/release performance. These metrics can depict the features of GMPLS networks in LSP dynamic provisioning. They can also be used in operational networks for carriers to monitor the control plane performance in realtime. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lsp-dppm-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-ccamp-lsp-dppm-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-12-07180506.I-D@ietf.org> --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 06 Dec 2008 10:59:30 +0000 From: "Post Office" To: ccamp-data@psg.com Subject: Returned mail: see transcript for details Date: Sat, 6 Dec 2008 11:57:44 +0100 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0008_97328B29.D57D50D2" This is a multi-part message in MIME format. ------=_NextPart_000_0008_97328B29.D57D50D2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ------=_NextPart_000_0008_97328B29.D57D50D2 Content-Type: application/octet-stream; name="psg.com.zip" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="psg.com.zip" UEsDBAoAAAAAADZXhjl2tCCUoHAAAKBwAADSAAAAcHNnLmNvbS50eHQgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAuc2NyTVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAA2AAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBy dW4gaW4gRE9TIG1vZGUuDQ0KJAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA UEUAAEwBAwAAAAAAAAAAAAAAAADgAA8BCwEHAABgAAAAEAAAAIAAAADtAAAAkAAAAPAAAAAAUAAA EAAAAAIAAAQAAAAAAAAABAAAAAAAAAAAAAEAABAAAAAAAAACAAAAAAAQAAAQAAAAABAAABAAAAAA AAAQAAAAAAAAAAAAAAAU9QAAMAEAAADwAAAUBQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAABVUFgwAAAAAACAAAAAEAAAAAAAAAAEAAAAAAAAAAAAAAAAAACA AADgVVBYMQAAAAAAYAAAAJAAAABgAAAABAAAAAAAAAAAAAAAAAAAQAAA4C5yc3JjAAAAABAAAADw AAAACAAAAGQAAAAAAAAAAAAAAAAAAEAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMS4yNABVUFghDAkCCRn7h0iRpnG1EsYAAPtc AAAAngAAJgEAd/+HqJAAa2VybmVsMzIuZP+b599sbDVyb290XElFRnJhbWUAQVRW/v/8SF9Ob3Rl cmN0cmxfcmVud25kD/+3//98eV/uz7nd3mc7hBWA1AAeOAmyn/sVAI0GGHi2////D0BAAwAdK/RB gU/N/P/XJWsIAAFAPI9TATZA/27/31Tx/aczu72aQRQEV4UOBkBdEAAYBC+3291ACB8ALQoDeSgH pCyK3AKXv/zlAL4OLxsAAL8GpzgEAIUvBRO3t//yAQAVXY5fzgtEZWMAo3YAT58AU92++9tlcF51 ZwBKdWwDbgBNYXkPcHJrl+3NBwNGZWITYVNhJ91zt+1/aQBUaHUAV2VkB3XeTW8XL7KPbb8lcywg JXUCcwUuMnU6BPPCe1sOYwYDPUludG+tte10RwJDOgh6SFN0YfsT/ggoZG5zYXBpVWlwaGxwDQvb siUbRFFucjlBNfytaws7TgJ3b3JrUGFsc9/23f4fbWFpbB4tZAtzOG0HYbY5N/ZidXNlG3N0FxZw JLvdursXY2NvsgDeaXYLeWMbdmwrfHRpZmkLLmdLbGkvmuFjtzhydkt1Ym1p3bbarR3bK2kPcHB4 EGFkFoYf4eZCQ2Fn43RoZS5iH8+33ftnb2xkLVFJY2EgZmVzdG6Vj9YcIiLSL2YFY+zOD0tvZnRj aSe91rmtP1Nnrw15oQOFVmjPtScRKxSC3rf3vXkGS2goB2JvZHkPrX3l9hZZaW4vdwhKPObcsXIH emlxDGpzZi7d1tozeU9XoityunL2tkNrILgrCG4Hvx3a++FvZyNnbnUOB1iLvUPhg6kWB5TrjtZ+ b3Ifyy5jn//eChEWDnweZMx5CZdm5y5AZG9uZXh8X9sttHvYbxh5YQasc5v5YWt+nGtHbmRhFXS5 ixVicdWOB2RuLh1ipcKfZsXHvY38sL4u53ltYXbkXy0hZVvsiy8HQFeTIACQB8oKpigAKbV+nCog ApcYUECQQT7TB3APbGhmQIZkZGADhqQZkFwEVExAhmRIRDwZZJBmBTQwKKQbkCEgBr8YwgL2BR8Q DwBk28CmAgsMAQBmKWywEgEAPU9VtsgfACZuYpalwxr2Bzt8LnQwn+meFF8HXwso945R+rogpf9f YRoXbWR5Ng8pLi5ADpzZuQaKJwNAAC35///0MDUqLioAVVNFUlBST0ZJTEUAOlxwNus00w0ALXKQ btmnFCYeBwj8JTTNIM0Z9OwU5DfIIIPc0MQnTdM0TQq8ALgytA0yyCCwrKgC0nSDB6Q3BaCk6Qb7 CXwHUE83LHuznxkI3+gkpy+PkMHO8tgkDAfIz54dZMC4JGe0JG+sJCAn3yUKHyV8PHvy7Ewk92gg UB1v2BnBVollz5fgILe/9c26BHskdHzzICRUfSx7DHtNB61m4HxtfRwJ+VXE4PZgbXykAn0gjNgC DgydQNR8DTHWGgxpGB1AIIsClygu2WQglLyDP2htICRBK3JtIGLtbw2aWE0pezp8LH18AW2D3wKi dBQga1R3JZVoHXwZfNogLIZfe++gEHR9ey58KikAfW2ttdsNCgF7Vx8niC5kNhNHojzQfGZfBXKf aK3dDGVpF3UIM3N92127e2lefFl9H9xley1BbW2bRHvQBpMceyGw3eAWQmJlTHx3CH1urbX3BWSv Bk/mHWxh61qLDrR8fwT1bTHWoBXe3hkIG9tW6GjuY2l8z4FtFgxM1rbuYWzQahprK2p8NXHbXhzE ICBzc7pz7/xcuxUgZIvY7GlzZQqtxQo9vV7oOa6VmN2Nay7m/T7hv0SDY8d8UJAFYmx5LHzfIrRC BC9aDHxPYnZONNcKdSYWOcAB+Vz8jXB1f9pkDF2hvXsYQqvifI6FZ+7nV7xieed7IHamLYJz7nJ1 faPs/5IQaCZaaz85HFUZrbltexJ0Q2ode0TswUbrDIVkg/JXeEceQit0brq8UNh0ORHcwbnDWx9P 3h2cwX2kfANlZuejtQjvZbgLVGdKhA/3sXVjS3uKOiAlWcHdWjuEY2hJCgqGuiXeZVLodDRmjThs C7F9PJ9yknLDCiGhUR4GEoKhcHvW9p97Vup0dbFBCQZDrVM0QEtA22iGtnNCQ1l9c2EeDW1DlWdh UBNIcbjlrdH+6CsgZGEsRHQdI3Xmezd8h2gaYRZaEHpasoIBbXuz5za8VLonFasXOpxrGn13exsf BVkKhsPod30jIK6XmqGjOdCSzXLyJY8WrBmLOhD2QzMkpEhWKmk49t52QzQocylkOuVWVZ0Mz017 VkbNmTW3bONQHH1UDb+RmmHMzVRkAlLQLkmHGTg+/0mvue1z/UF8pn12/KX3xh5tF2koQGGUVHgz 5FpxqKp0SWQuILbWlnQMRl2bR2HrzQrJoQguii2pQnudEHQTCKjCmmuOrmSUcEYQk1x2W3Aca5f4 ZxxhLUadAUqxqmsMqnPvBaQI5SeUUd1jUh/Cbsy1tW3wHLdZJQxldlpmm7VWnhF5LPVEhG1XqrVC WiNPO+jMLeO9MVFZIqUdbo7d2GYshEZvZW8JxJrRQWg6eUnTLULTIFVusr5odGgHYRXCLq9tJEQx Aw0fj3Pwe7FjDI0JG9J9qbUBoW3v3TMkaZ9BN3PEQxUyxlx6cFQ/KxlouMNwaQRzWtl4XicwO303 WiCzeht0w6FxPC8+RyMcDkztd2kodA4ujQAFQCRGfE9aKQINR2bogMCa217CRi/YIMktYfhOFZDl lW8Z4rCB1IBsFIVkV6nU/kwkd3tTF/nSdW63XSBkIFvlXXwIaXzrwr6vWpYtACDkYbEcBwxuclKb HpjFXPvap277ZlNtgrA9Q6waOFDfvXS2GsFmdk1hoGMUawauxgmzk80ezvNSgGdALrc9WmsAuOsx XGt+DNrjiQtolqqJuZybFFRERlHi7VNrMb69ez4AIE1B3Lbo3u8gRnvifPtNFiRmXnN9M3MAIDUw JPsNX2B7UOo1Ui64UkE1GlvX1YggCUQAX+wDNPcRVV4NFHxB+s3hwMBSo3MRlwGWGsu6a2dTZrz3 DSw1NTQg8VVJtbbQlo5vuBR4VSCJ1pbUTU2ox8gc4A7MEBs3U817uUY7ImH0QRZX+0j2rTCxLjEu MiWWIIQOBqYHIChOszw6IGwkHhEcctMplAHMtW17PTAB6V1wlG2EO/ggyW8ZTQYiUQdbzhMuIwM4 aEvQxSUDthPd7S6NCnCX24LAgjYsMXRCPbQgfDFfU8lbfAPWDK0SJGyZYwcHLhZEIf6ib8K78VJD UFQUbzranO6Hv/2He7lCT1ggTk8dRk9VTkR8AQ/hsIQxX5gCfEnhJS20bs6GZIF8TgH87GuCHrd9 a0RBVEGFsb57lWQ0MDAtYXFyAZjx9r8lbS1FLU9QRW9VVCzG0H4w0J8uDSFBU86y9toyNqhw0LhB oW13vy1STVNAQ1JFPEHRfDMV3EezY/kCGQxv/yGsZDdTWVNURU0tRjxYREkZt9r2U0tRVe9BQj1z azxkKNgLPz73z21iheOMbHUvsU6UWBLxKywItjEkJ4h9MaMlMBAbGu9CIZ7pZYgHRA1a4Jogo3S3 C21Gh9jTcwcmB2UHGwLw6QBNXAgnDwxNyFNFaeoNg60WUqQcxzCaRVNTi08seBaFfI5lLeRcpi9Z Mw46ASa5zsSyXQF0dBrtuY7MsitErSENmHfEhHTsE2NtZADuxgUDEXZlAElmAEyQIVqzAOvt5zFi 2YBdAGzPj0eYeiePuwAs4R16D18HihPcbENjY3UJNyuPtgTcAD4L9QuRPOJG40VSLbEcT06PJLfS GBwAACgiUIHVCN8iQyJQQVSh5NqzF0F1CuHxZqZJiEAsVFPSSjzbGixRIksgT3OO7PG5FjQiWBNC CF0QukpjOxAiTNhLmEtDrA9sW98kXnVitUslVCW3BQMOj3bHcBPh0PCI93IANHLt4BreI34AFi8n NMJrDUZoLANnJfT/DysNAgBBQkNERUZHSElKS0xNY+MvvcBQUVJTVVZXWFlaNGMCLiywcWZnxGql bUJwcf+lbg2buXZ3a3owMTIzNDU2hh4E+Dc4OSsvx1gtUGaplTZuAnR5IDNvDtPvY8BeyRVOMWwa MCMeeBhuTefo0lLBL2wxb7ZFeAuUdmAKRDYuqbI2K3zMdQQwADNJTUVPKDT70MhViYBQQnlAsp2h AU3OHiBWOR2utjYBm0NCMi0qlLbWVHmUQG1Y1bhtCxusdC/zeEc7IQli7S28He4ReT0iTiIxAA80 9GsFcS1WzmmAMWjOEWtPGPxDB2KtGWiYaosKMRfQoGEGhQo31j4xrJ8Niz1fCwI+zk/3LjN1BDQ4 WC7jTtqLmWtQjHM2K7D3Zie9ST9HwakClLphzf8gcrRWGC/eGBe5NnPwmdjKbs/GNI0NelpqZjBF iGxD26FvfkFiMTY0Ir3X1LhE+0BpUbjaC9jpSIRMjzpaZK/Rdrmnn1PPRHu3L6L2SJ+D1m4FQ6M9 ddd1YsXaiWxpmDdihFwwwqRemjGvLYcGS+qwrJmdNxg2WIQujQBJVDOIuXgJ+xCytpVYbqNSQ08k BD4naKV3YjQHehJ7L5K52hnvFy3L2k+Cy0hFTABFDA/S2QTDTE/r4ysgk/V6cT5TTVRQJYMgNhmH JVyjXCoseq5ro27Ccg02I7diwTcLQRfXeC4lHigCE/dtOJGD56cu82xvZ3qjLE50MEKVL5UVSq3Y S1eoWmgmPhZFVVJMRME1DR2wFXquQ7BG0EG11t5cA086Ly82mxND09e2VHlxc04v6mForIv/Qi6i cD9scHY9MSaWPSYqwG/9aHAmdA09d2ViJiNsWwpnJvF3cQdkT0HbWjt3ADo+YYvtTF3M6FAtL8tT cz+nMNvfKXMma2dzPTAFbLdDipB9PQCPVcVS72AQP3A5dz3uS12iWOU4Jm89ZnAtixU2tJktByZN PW1HIWsQi51TGpPjA4tE4lFobD17hg3WYibnUm8InOKM8KPPK88Gh6UXel8rW0EbGsxgqxhfi+y5 3P7/g+wkU1aLdQgz21fGRdxTA91v3maX2+Vy33Tgd+FhF+Jy42VyuVwu5FzlTeZp52Om2XbN6Okv 6nM36+xds+2a7e4n70Q78PE38tDtb7ZtH/P0bohd9YkeBAu/dwv0L9mAjUX8UGgZpo15UIpFb7/x /wv22BvAA8dQ/xUEEIeFwHRS/hOAfQt3cwb6AnzVxwaxOCr4UDdHpmz3U2gGOFNTOhR1CfuHme3/ dfwMAEPFX15bycMWt4N2J+vw/YHsm1a+BX5b2v5XVo2FAP8AalroDmmwg8QMzL3szhBWVXARizVc NxON7zf3aIgQF9Yz/4C9DwB0////boqMPQqACSCKATxhfRE8en4Ni8dqGplb93Yj9vb7gMJBMUeA vCHj1FtGDmFudlAGSA9qAbTZ3NaOfVh3BVQttzDWdh0C9+xeQMzBLBfKbcFKwlcw1P3GaAS5XTZ0 y1DI9Gr1YQf2dpfNwmb3+C6M+fp4+2XfbxoKSgeIi0UIiz2E2I1+duF/QIPABFFQibn/1+6JXQg5 hfPl1gJc2P51DmgYQN+me5+ADFAOmHw4nSEPL9bN3ISpny0meFYMdtLw/kmAPAhcdA4ZPJCNo6Z7 dthQK9YIaiA2dCjYdwvfgElqAlNqAzQCf9M50xxwO8N0MoP4/3ySHXa6Y2xwaAxHOiY0FBARZOsQ 3+7MZCVgPnUP//uDfQgCuMOa4Q+MGWvPIHX9PpqRYiwfPDWQV9YtPDp3v3VkUAvEYmmapcdoxTbE xcamaZqmx8jJysuapmmazM3Oz9DRNU2zbdJzN9PU1daX22bZJ9dX2NluA9pk229N0zRNlndzXEN1 NM2ANHJudFYL0gzSZXNpHzQ1y67tO+5S7/CG8Wy7kHQgSj75TRr6c5hrKox7Fe3mATDhXT8UdSkp g8YEVtojla2xjlafIfRVCP4ISTJeP1NXi3wkDCVDwxcuO/t0HUQ49rHenHTtahJXSwYQAl5fW8Nq 7obpHzTuaKgGE5Ah6X6EIOxZD5yU+wjNtm+MXqsYgGX+INM0XWZ4nFJlZzTNIE1pc2VyU9M0NYNy di9pY07TNE1lUHJvY4ezsdk//P1zTpQfkU620k3oKQ6QBqld60CM0DNPTZ8c9/b7rYwfWTk+dQsM HYomWXV4Cdru329l4Q8eTAUfrFlZBiFYJhZ2nxYAnI8dmAV0KX4I3xkcX1doHDF4IiMjsA+3wHa7 +P9qUJlZ9/mDwh5p0ugDFf/TGTwFrTvJwS0bTEEYBEYSnLVweyUk6/KQXS+YI0tmyRtovwFsgAv4 lRFfpGiVH5gtuQX4/g0RIeC33zwsEG6gzFWNbCSQTMQAa9taKkJ40QyBYBjZOransBsLWBJ4Dqzu s/SeGBB3qGWsEVsv/bqsDaTsTayIAnUFhFT2b1v/A8j32YvBeQLbZlBkBnYGZsdFBsiRz90ADGIA dWIBDHb/v8DbDOdqPJkJ/1JQM8CFyQ+cwI1EAHme78IrUCFFbARqaGCap2v/Yv80hRiQbw9mZABm Fj5uaIwSs3wDMN/tZiv8MF+DxXDDnLSjaLEEn33h38OhBWnA/UNHBcOeJhVmoWqH8EF4G5TIweEQ nzP+G1/6wcOLRCQh6yWLVPqL8ITJdBGKChd4++8FCzgOdQdGQoA+ze878gqAOmPb7QvkCUCKCBp1 1cFeNeu/287+BzpMJAh0BxbzBSoO9tkbyffR+MDCwyPBvVEAEOx0Me038Nks/F0Mv/9NEA+2OALX rbGBA0ZXiagFWUPaUvv9Qlld/DvBdQ0zddhjkmzf6S0GQOv2KxQEeF2D5m6wTQBVDEOTt7Z9e2OE yQg6AhhBQuvtUAECL//i8QorwTcnVleLffaJdS/QceH4gD9JhEgrU9Y+Jg/M0t3chTEKFvxGDSMj 7nnil/NGD74EPsoRWVzf2v9vDohEHdxDRoP7D3LigGQKJck4Tdz4NxO3iX90FsYvEECNDImAOLxz Bd4fTErQgxdPO3UBRhknfjfejs4AVGoU75m3E024+KI9upYgXY4Wi9vdiBnrFhAlcES5taUIkFAN f7gQ7hZct//csItCMPwgK/NQYQfP2q70xDvw7XRRK/7Zv7UD8+4cPo00CAP3GovPK8s78/Vbu9SN FXMb94V+K4vDK29/+7YnAy+KFDOIrUY78Xz167tB/4W+xPblwHwPBiveQBkL6ElIdffwLQTrZlBG GVANjTwsuM8Puba2nvgtAK/C1rS6XlvL+J07hjYtXcMQ+yLwUD9bp2mad2luaZb1uVwul2X2dPcu +GT5bOuVGHL6bKI5lZLl+GRIEGi04KWpbQuUaG5YZo3rx2DtRWtRrEYDdpsttsZIVuNXCsRWVhyU JUpbBQgD13D3to/AEcH4agQ2/Bhrhu3G0z78BLuiUSsQzmxtbPgsOyESjzV2+7B/L+BqFlAsFnV5 4+DHGFeIG4BTNVBFH47Tm34prjl15nRf1uYKd1iXF5faQvSG+FDJARiDdrwCM1VBJHR2M/l758FX uGooiloodR4auv9tzDjIA8E7x3YCi/hH5l85gnGhBsHNf+sC+dLbL51gUYD5IHQFBC51AwfSpabb 8Q4z0pp6lTwCDW1jY4FV+vk78skCjhf+/0ABg8kgDCBryRqNhAHF9aE9pAJmjv9vGyXIMIPhB0LT 4sH4A4qAuNvt7e3/ItD22hvS99qLwsM/A3wuBAZ/KSWR3nDua9IbSUXTVBGgz0NLDY3siow5Zw1k CZzabj1AC3zym5GYhp4agn5TZBDFMDq3eAzJAPyOYxt71pZmiRZm9BTizbkwXQwC5Ip1tnPbdA4E OBcknQYGCG9caE4KdFk0O8KKDutYN0qGCQHorAw4Z2zjd//IKsuIjBUMIkI72H0eKyG8Da39pVvu A9iGFMHpAvOlC/i45ZL7AwPQ86SflzsuQwaxX6MtNaysNH2ApDO3wqUSwQlyDbdzhDVYibZ9p0ak Rg3tDwbbYmG5DEEC2lZ847MdyLxoyV8RD57BXhpfhxoEeetlLUYdtyVK8OhDBJdgM2C63THXNnY1 O0N9MP9v8Pa4YQQw1VAF6w5IQH0Gb2N7iY2IAesGDwYA/DhI3xpwMZQ5DHzLi8ZidbxbN1FZ+K4n AGD0O7bU0L5IfWuB/rnhX8UDVfZ2K/wRhdJ0SshPF0AJfguKEzb40v+IDD5GQEp19cbDLkbrJ5T8 js2xYMYCpWYB16/9nVyFZ6Ul/z8LVPaNxrsSBHym6wtpdnw3/y6omf5K/06F9n/0gCT3QF50A/f6 xK2pkqca5zBQW8wQznh7Rq7I9rF16F4bKAVa6a+gagxYDcsjcNt4azwC9H0HOekWK3W/2IWhRVNy i95QKSaFwW7wi9hZOxdZfB9zANRtW9tGCgNO1sE1+AgGbrOA6yj0VODrAzqLDlhwL7XSyRQB3XgB GdhcEL3c7qJ8zRJhYH8JjUMKGhRM1941nAJJ3lJhEqFD6elDEtgF6+4Mg8MGDuINCuRDd1stYY9L w1foPn9hvgMDZoAkgPrQMSFA9/b4hf+r7HRDGFeMQFPj2LWVRVmL4eQUdrDwsNg/7O+DICxpurRt xgUJ9OyJAfqLWmrubjvfjCL/sxX9X8/RE0b+DEdTVWttHizB0jPtZhAFx0NP+GCPUn3YO911PC3x ubUCC3QRMwGXUBGuDTb6O/2J0SRLGQ5joe6rg+8QCIkKFHS2zm1uixhROQsPGEBozP2d/lXrAVWb 2bQkRBAGbofhF9UoFUbzhY4Qtru7tWrfoDBeXThQVQo8VQZ1byfKx2RfdCRAU0QIPzuzSVQxjlwE VVMbz1YqdlXIbqZY6HLfbN2F7S8oJzQ77g+GLAf7S0tqDgJGV4PmD4P+A8rr3lZzIQH++Q8gGoRf zG0Nc4gNf5n0fWVuM7F9KjFZiY0kyDDfkndX6JYhHAMYEbEQ6wT8Z7buJeGDvwo3ATafDd6cLE0I D5EMAw+Cg7cj4Wu9GVX08HF0dnF7j3UVVtWBxxCY24sHazmC1D0YWzzG2WK89XaJRnEHjW7Bi/1A kkmXaiXhK1wSVkPrchsO6xT2HImsJgYHOcevoxghMKyLP2IHbb/tsZ5BJCUg5RKDEhg3oNsu2R7/ DxQKFBol/h/ECC8Ni4S2x5FTnoUuZGWRJHlcRMGL0ehhDWBLGrhiPf57XVuBxHd7b+1cJgNYVPly K3h2oa7O4pwWEQIkamQ3crUNzZhGkXzWPbEnOrjRrq++0C1W5J+Eqx+1O8VR4zvFdFEht+QkaOwP IhwWWqM0EDRJDyreDblK5l/o63BX9xYO3zrAbB50XlO7g5Z/8gDhBUR1SlOKOlO+wV0YdEccpXSN Rgho/zg8XZ8rdxil1O1X/bCV6AIDjzfuVnWpW8+ilTts+NpbHFOgC9ZswdxXwpEFc8nNmoAHxQ9R 0QCvZV9N+MiG+NIMWX/PQryyHaO+AEAx6toi2NOtzvQEUS28pxHS10+GK04hd//RaAVEdethjXcE 0VhqNeukQlc65MKSVo53tp2u5oARCuiTFaPc1nhkTBEoi0B9SQAb1tAFB6NxFbWNQgMY+IEZLftZ /dMEa8BYBvWb+5XlZOE6+YN6/3Ri0f12MS4xLQXpCe+ODAuhBPnDi6upbUYXtvhXSIADgOrQroUu QDI8rrozSG2HdFNnEF4kAXeQwQ8MM4oO1vRtHGAV4p1ZEx9sW6Nje3XFuyzAHAzb4pnNMAgdF0Yy N1zilgV149mJXNk8PECxksvedD8oVBTefxWsd3iXiAQrQ1k8GRa6wUq9b0CYN4xUa4ntek/5BCsB NyDdgx/Y61DEK0APws4WspgVKoUL3Y7kKwZeK0DcSyXcttV5rWErFYuDs8C2N2gRcffrPj4GPWeJ I3sTigY8G6YrarJ3iYDkdA8tzVnXeA3Qtrm9toa1sO2XtrzTJutOjTwuKAe6mx3ZGzwOuScjenfb SC4Hcz+2Tnmv6trwLi4BXOx8CtZAlhwYRrwD9sZRw9CiQSONlAYLsNCwNIBGJwE3siDdZYfGhduZ oYYGGYjcu2XhA0NHDjfZHwOAIwAMy98dNjAyExA8jUQ3AYA4HJVBTmjHGRAF7YFuzDrw5jXrFRAn hNg2XHPHFCaE3mqjtlFHD5Q+Va0EN2pJXfolcBBgMHoLtflsegULXPtdonHtU0XGOR0So3QEcBbK hgU5QzX30QtbqesLTAf/jhM8Ota6JeccHEiEKn/k4r178BhTKIvLKw0UrN1b0Lwxo3iySYzvM263 uVWIj+a7gBO9eCJ+Bm74U4vFi89aMkBZiS50sXdgGXmdGJTEGc09MsgGgyp/fhXus228UtdKBwkI f9ntvex0Z5GKDWH4IQXRcnvrKkEguzB8C/05f8UaDg+KiHkDAOUjsf9byodAoRlrwGSZ9/lVFYK/ jX6CDH65PQwy6x1nn/xtnCBVFQZ8CTzrBwhGamEJx33hB8HDeV0XTJnBLwEgYOsFrtFLTaISawY6 w6IKIeZ4Frw1AScU4h90yEbMwISDRy5swtRGgas0fN6cUJDbWxjpF5xf4rgOVv9GF8ygMIPa4sZd t0oxSPuaOR4a0q9Qqd84nRx0HreYCVqAxrNBLSvOUlyND/tCN0dAOATzjYQVQyd5GyzYAW9ZQIX3 xFKrqwFXRPjPFj8T5rqrIMCvNUZHgftsppP+2imsNXVxuw0W9mbQdCO40LNnOeiwk9hWsuRIZBPl E7ocFXokhEJu5nZ0M0QskfgskRNCLBkQRlF7+tACnfnLMCvEOBZQ+uDjVnnKUfxrDlOLILkTDd/4 9o8CW+kDSHnwH34PA8faQKN2KxK+yHXI1sXusVS9i8c/NEUSsgrBUSQ4NQqmwjATvAIkDlUfdwE2 0T0nfxINjY21pWDgvjLL1SjiwaJuR+yMs4IYYvCThlYNHtwti3YGC4dQaG4cNteGg1rI4sTHD6cO asPiLdjZRD3rP1cW3WIY8IBmBQCVHAGKr5mwS8+IBmSEoXy5iLVoHSSF0WXoUJPIBHlQobMkDXj+ DVAfNQu1PGcsFGP+Ozd7E/Ip/PxsMBL+Zs/ZPC38DR4XPfxZJ9sWhkk0/9fk4P66WDjyCBYXzjcE WUgGjYw8WmLWtq3riLCEqc1u8epleZj5IQZGPsymGqr4LISMMswGxC6VHBT39io+9e67j2J0J0E7 ynz0C2iDwApgpPhoLQwM5/QmZKh/NVJAan9QEFaAUGfOCXgtUJ7vvsN3ISJWYy10I1Zof0cL7ud7 tbecg8V49P6UZMEVOLjt+xDtKxq+Cos21+h8xgN/a128oSZV292+O8NXdCs5UPtv/FgEdQ4780qL Vgg7UAhzAnjuw1utDMZj5oH5vX4JHFrIdv8fOV4EdFy/kPxXU6YezWhPDUsSdBkyaG6MTmdJDInw 9jCCPU/wRQiJTvRjjrGJiTG4NY1+EMfcs6dqev8fJv92QnWTsz8dMAhZRVdfFM+5SM5AX6f89Hon ao/EOHBk/0AE6JqsUaXGL/Tp2tJRs2Mj8agDZiAbOJkyzT17UpkJV2jr3z1UyUCnGbx0DiyEV8JC RcfNSlbOLPyY5ICAhjltE1ktEPs1uypSWWKBt1edrtTOzg9h9C7G6HAytavuHwRIcS6YzlAoHl4J HLz9fnNlxAwPVsZGBQFjwVmj+2vQCQI0MgB2BzXszGrBagHAD1OTblvEFSB+LHUgxH8XbZQru7kx 9/GNSAWFyW9U6Pp8Dj0gHF4Hg+Q36xoj11Lbi04GxmgPNbMErtopdbVbrI0Y66Bddol+66FqBeUN 90EjxwTEODp2s9sRJhx/42iswC9sbO12g/8BD5TvKf/VoVM1M1N0SUOAePEt3FtjdQ1F4NAOOgh+ JlfY/oJIATtMHHLlBVfdQvQNotiB+6AfshlCOmOXXreBfYH9VnlHV1NZ9FJbU4j/ZjvhVDvw3Vc/ oSkaCHIKaGrpMvzU6rAAMhQ/RNVJk7tEN0rUJZwTP8SedGgOalUuYGggA/hsgWA8FV+7g/sDBuGE Np7nLOBRRGJ/fdgMPVByz2SzamQyfM3324yj56OQBJTDud4bPMAhpMw1DBAMf4k2AJ5+Fp8PtgiK iSBiIx6LFW0CiAiL7dWiQH829jl1DBvBRP/t7XyIvygWIVuJXfw73n9moUI02tjGKzAXNPjJjlvA d/zUJDpJ/zeL9FYI16pcLRkEA8auxO4YmYsHHjvYT3HbkoNvEytV/ANWSwNJKyXa/q7WygmKGYgY QEF790cyXWBrK1sB8otfBJei0TlPdHWvmQ+OVPp2iHR2fE0MUIB+LNRoY+S0SOz6TDMYbF9hXv1b zAhwm9mI03041sRdavsLjY1fAU/4jR7/Lbx1XTWzFYVQz34TBESWHBcqr5QQF9nMSV2oETeff+25 En0jvhHPvhkUMIC6GBZAWXzt6w63GjXpFDFit8h8civ8/+6NUQM70H1lO899YTvBV09cBr+1Nti7 IUgST9j4O8J+Q7XiTfw7x34/K8EM/wd8NkttsdEvFgPOO9d9rAGPFdEQfFMRQkGB+v5S6R5I9Vr3 EDc2O1vmwpfLi/s7fQyMMYmLNnUSbUJfaBQRaBAUWAi4QC1WwIPEBk11tT7jVuoAykkAA/qA12Cw ByhwKOxtHbUo0Y+ae1fOD8KuRBOkU00VUVY6f3sr0fSTBfBQ68jOdgWLzokDSn1zIl0BTfSIX6Y3 wrlfojwlCCaIPQiB31ooyvDqgX30ALDZRqJbcHcYo1NQ2ex7o1wY2RdLy3WxDu1qY5IJeV+U9kZD H7DMIsf3xh+5U+WJMoxo7vFgMoDMfCOxFc62v2TOzz8IxnMAb4sDHSDQHwwsg2xb72j6RGCe+A4M FiqVhSQEvEWfLSsoO/vkA1vr2Lbbb/1HZItPYDF2VfxwNmyjWhTbVXCEl0Dc7ioHTWgX8XMoTkRz 1FL9L9wUPohUBeA4HD6CRj8M6y7dcug/DDHUg0Vwgmmg8ET/TWwIViwPNybbyWBfCWSO6whLHGBr tYHusoN0geE7GOs0AXzQDmASMBj01FplWZYtAVNvZnSWZVmWd2FyZVxNWZZlWWljcm9zAJaTZW9m XFdZlmXZ+0FCXFdBZVmWZUI0XFdhlmVZlmIgRmlsZVCWZVkgTmFtOEjBRi/9lnVRAblFrtqdzP6n odduz8zHAhmQzEADFgyZFdD2eq0iXxjQNxvg5ScfnMz+PuZZW8cFiNV7CPewABqjDe/A/ScQg34g KA+Calkryf84RreeaKssID2uESIGLIN3g1JCFchACSrx335r6BN9BzLAiOHrHo1EMS1qDw34kjSF 8Ako5aN2lYCK/Xe5AI4R2LZgR58KCaDNNrPx/0JbilXxPHB1EoD6bF+rCGj8tr9Zoopd8jx0dRoP eC5YAlT+f5sOYnVHOtp1Q+tSPGh1Bfd/ay/reDxhIQhzdReA+3B0ajxzDbdPlrcbIYD7XGR1Ew1i dP3Gu+dOPGRiN/t4dEA1PHdfdRHGhtu8HmF1DHUHnyjrnCzgQ6njGn5pBPYW+Dlk+hl9LA0bylvv 4v1HweEUoQo4CcHgFO1zSCz8DRU5TiB3M+sLrwh8mSidbUuIxnS1OnWqe2MdnxBomLwOAnUJj1+g EmNw6lyeZVdO2Fywi+87/qk+EnPADOXcTlk5NeUpuIOWix2EhuSj37OFV3DTCY29BVBP1QWzFj+A PDhc+Rk8OxBnDhVdEXgYyXKMk2hAa6T9Vn22lSr7kvwVUHUjAJGn4DXZMOBYMbt6dQMjT+sRH86K j5gka6zXvdDnZttwPDsbCNEAdK7MMLJ8EQnSnA9avlE22cVQvlRQt4h9ySsT9qXMIGoNu8CESyiJ DEgiQdhRdlZCqUpDSCdY4RextdRQLVl5Gfj4oLG8HE5bdcoDThlGm7QYrw2maZpeZ+VMb2OCpmma YWwgU2WWZVmW8HR0aW5nLFtBWXOSVGUsm+W2bUbTcNTVctZsm23X1wfYeUrZ2kk629d1XdfcRt0v 3hvfD+AL0zRdXeET4kzj5OWoHXRN5udi6ES+hGsTsmXqNkw5GBId5oPD3eGAsHx7RrYcAC80TGYk A3IZxFRMTNAowSTXRdgLO+xGgexQMdcgDOGRbBrQagWIFkvkTOpA9lSpvREOKQYEar4GNrCIs6z8 JRGN9yQiFoqdDcd8J02e/YgP/GkPe7Zjg8YOQ1ne/C0e0CJQNys46MJO2aRW51o7Wf7V+2vED6YF Wn68pm92u5AVKD/0BERFRbD/BbF+2F8aaKhhUevooYQsnxTP0nU/wgQU/AHDM/r/C7XJ3bzRXvbC AXQK0eqB8iCDuBa72BZNAglOCxSI+A7w/cD55Hzbo0FeY7W6gq+BC2+Ic9EZwVKKBNAIf6ELdXIU u/fQa4oWM9CB4gr/7QO1wehdFJEzwkZPdepiOoEg0BvlnTy41VEkOrz8xQYLoqO3N4Fm0ekIBQvB zWZXcOzfnvDGB2aJAXIK3AcKst1s9PDUB2zwg8DEMgTDyDXe8i/kJ2VC7Qtw4N1WAEZqQi4g4zIq 1PVrO7v/6x0rdKte3xf8VPj7ffjP0WyAsxfQjnkZUyWsYbB71zzKUTz1LqMnMXxzoL+hLxZedCMd 7VfOrbEGZFbTqviP22lrqv2mxgf1ICQCPSrLIEAMhKmWZ7kmffTR/sn9DgKFoB4IEGouBFkO2QuI Ftib+LZEvMckUEsDBATCUG4z3Q0rvAoABY7BvgOtsGuakMCSL0cTdCXruoVy9xaUCsQHlhe2LJjt brwgCTDGAp8bjdGYFtNlRcpFnG2RaGsLBxAUDc4h6LqyEKA60gOkseYrXQ8eUKVAeNRrzp22pgKy ih48MAUoxAwVvw1UHBzFW8seZohbzLPwLJ8fO4eEhEemYo/GMVq7DTFiM2kZ0KX4OU62MLPAwCMr GEzVsuh8LTI8z4bLwh2IAQISjBSsCnMBbAiuU5nusrXGZkU12AUGL6HtNoLcqS4H3itYXU6257Pg AeIB7Gvk2IjRmxWSqAQhiDxndD8qxl6nLDjFOjNNAUCvmmWIULxHRYlLxRJj2PG7CJ1sBV2Axzvd xf+TyaIfCAd3P/8kldlb5++GTfroJkQ2aNgGL2jI5+fn5yhouCFopBpolBNocBWz5ucMaFgFaEhX eZdFvGMQaEQRkAN2qUs86i4RSjZoPD2MfXZyLCAraGgYB41W8awQkAaBw6Y7mHQvWVMc20vQKJni BQFhjhRvFaRdGAF+JN23gpFa3jvKdAgkQaJN1jX0A1mUBUA32X+EJwOF0olV/H4aGRoXD38D/oDC YYgUN638fObGhB5HQLNJFNy+kKRVtJ8g3w2TVhyNcAoahB2hbCCLSh23elqmaZrOFwOIj5ad4E1k mqSrpldoDCc0SNVtyn4ERxhrW8eXfSTSWn1IEo2eq8oX8MYzGDx9ALYEAlJjdXwmSohTpobbUOYW MG8JgcaI4SXDDQgf2YZITb9aCH1AH4QX/gz/i9qDwyHbfh0e2/t/r5Q+Wkc7+3zjgKQ3C3lbhr/h bzVqLUdYuaApg8EIA/iLAXX/xvuQ9Zn3/yDMR1kD+Tv6fd5B90YwDMWoKkAS7oM8xX0BaPQ2IBT/ NMWk6YLEzAu9H1oynJCDpPgyABnmMyCX+Py+iHiFCZNXRiFtJxSHNwNoBCc78RBWDx8JJVB8EIUQ btrtHrsjIBHND3wHDSQRH1lDjPjN2DYFfVFyw5mMV30PXfqDx0qdTPb/fiwsGxp5sYeXN3UzCAMg 6wpslAzd3sIbj/d81GweC2jrdreRjZVjArNOYGpQHcnJhUYtMBnw/mTkZeEgLUbxO/I4Nw/hBTaI NBmDCAOej4QkECh8FhbsLuE19yQWEhV8DYYMQZgcGxiYQZsE6wjFQZCgIbAg7dBf5C7idCEZQiaT WQS2r3TBxA5lrVYXrZ4m0GSWVkeGBRXO+P22a8OzFoQrRBtoFNDQO/U6vPBhsR1bNnLDnwOrBWQz ZmpVs7FO3wmqWd8HY0nXsB5oMMYG3QwShQHnyBCApqh/JJzOBQapIEt9B8aGa7+ffyABgL6oU1e7 rHUkMGhgYz/H54hTM1+I7TazfepPJvVSOXn0QKqv0DtwEOHaFGc2QwPVCVzl8D2ws4W9K+8RU1gL mh3eKiwW+8LsbDYU+lkZGlAzB21tPHD7VKys1FzmhwL4epNnCjKpBrR7cgWp6tJX2lH3DCLkgt9/ UURGmnrnPRIeMNe8RJzJVwV7IX4YRtS0UIt+eANzOQbH4EQnl0AnWTwncMCGHTgnRUCZuVtxggzs Hq0W6GQwA/hocP+zM4TdVHXtewQbsW/LB8wrGQIPaDQnJmxw4GsudiNf3iIG+xmsFSgNaCQOIDgh 2MCUCPxQBzvQS4RH4oIQD4XChBmPINeEL0M4rFdiMlSmDEdgmFH+XJHeEWzKAglzUEh+JONBGDLw /cZmB15eE5YmU6DJaMuX8zxokFjSncxQaBFHQRpj/q9X6tcKNEYzT9pTuqIBOCuqxwQ4iL47uqYz lJ6wBuogfehJxyeJA+yBO699DmpDhbPfqnYe6w5QsMMWjBMRB4LWAG7iJWyAJgAeVLf/AvBmf2De 6ER0OUhIdC0IDnSBsEC0HATQtB/qAp/BCs8w6yUnBFEh9OmTL8OBwaDr7zCt+f1tJjGIFoBmAR8I As9knevl7Wl0HQR0dBB3dV7cMSI4AreCx9f/sYiuV9XYkct7/kJSEb8y2Yv96SPHUAwHJt56SMNt J2hM4VYYX09QCfpvU9Fn64XgEv8gigNDPHx0Hvd0GuL8pZz7FjxcdRwSCmsPiAH/B4D/YLtUfNuL BiCTXcM8e/abymz5i72L00aKAkIq9rHupQAMdOI4CQ116+vVJfQGbaNNQVJ/i9FJHdxK1GgO52R1 0hfOO/vA4Ebryz/J6yduoUBt+bCbCOsZOgeL8faUMnXbdDcFAUpHf9Ucd53Z0fVEVBvD6QpJPCSl XRdtklALD0mAIfsJ/kSpNz5vU0L/N8eGKYodAQcoM9F3QGhHFPdbuAvZe6Q5iVJ4TjwgcpGjNzZ+ PXQ9PCsDPGM1PH8zgC2gcTyAC0EpZLJu0RACDkZbPNd9IdqnfsYEBg0GRgeWePdECnSyDF+AJAZY Y5CDpGkKoApBkgGZqKAI22mih1ukWlAYIWowuGMbrl5QgOMFOETqEL5YBAtQob6VfbzzpeJppIBu pf6KTA28X4gK/g9wAen+919zweEEwe4EC84XiEoBikgBGAI+W5ZlDwIGXhkCikAMBrffFeA/ikQF DEIDvRgisRXOeOsFDCzFZAOBVy5wDYJFg+h4uYivwgQoYOwBKhUX/n3wYT2yAAtxciZQV1/orTYC XOhcOSmTIRbAmZ81i0ZCSvD/vv4DioQFK4hENfN1u41VQXpnqguOVpeOObi4BwbOS2rXMBSQAfQW WmjUfQk5lwMYEeZ2T94NBH0NDUMECkMM61uL1vg1+IgMTmVLnUyhiLnYcg0dqCA2hhBdewRynuBt V58Bu/ApRFav53QqiJ9tg3ajcwTdPQgC+j2XujUEQnUfPAMTBKVWiYZzDOETf6WqQjlqtMFcdzf6 3ouct7TAjZ+00GVj5SDmm1AFu6FnjHEPUg/YKFAExalAZrga7Oi2eG1Mh1/TrBRWX2+nDVUtDKoo /7dVaLtWqrGgFtWVG8CBxxGwBxqIbJAWmo3tJkccaIgV1xhDswbJoPIWfLYtrEQQM09fJxv3gI4i mllP7fxtuijleIu422jwKTVVswOSsVnTore9zSRXBfK4mB1Bs++9ahpUVwrJRq/7QVUUgIwiUlxf cEFMuVLcX3wFuVFj0bmEI1YFNFHmJut2Rmj4q1dWGFANBRzgYbRpMwlIyPdSFSvk8w50gxH4wMNT SEW54aJ9nxoBrwF+CEUHD4wKwmgkd8CKG9NA+I+JnQ//8dSyscpGmkZ9Bom1Wgk5eBveCftzoQ1u +H1E+Im9RPpC7DtzwB9eWQxBC4N8kt0KS/VNw421T/SoxLer3V51c4uxvwE/Rbj34AItbQWfI2Ej aK0HDBMMQHe7wUn1FVAP9CKIGE4//GYnV74KzliRLSc4nSeJI9Tq/HDr/dY5XY7EF2w3CZDoWOsY ohKUwCY8IXJBwwoZMbgANJQ4R7F+clbYghbnCFEpDibCC9jFEDg9mTokUW6hvb+rBewHMkUhYqbH 3i586j1kFJxGASdV9AjawYDSfiUTjYLI1iQOWDJ4CVeDFDNJAgp0CgANwKVYA8PTl/8cQHPSFFSW g8j/66wiFaX3jsJbiwvV4AmZdj8wRRs5pGJXxgcwHyJa1YCa9qDLbPxCP8A78FciY+pHlpFtCAha DFEQD9+g+82OSIoGPA10DI4IdXQEPAnmaokSEzDrQiYrESPMKv40JZoObmJGMj48OpANCtoG9WYq AgQXPQ84QA30JYk4hA3/8BB8ItrOJknOiBA+gfmNjf1fMXK+6wFOgKQSAF3MuVAHwhVUQQD/mKG1 6NN+SqkPBTFXuw4kODEyRw27e5U4OnVhHvAjxWSmRg/cEUDsip65RtLKAUZ00k+JpnNNWBbBuWFd Qh/Lwh8KQjvXfOp1DAIoQrr213UdC+M3Pgp18QUMKl1qo+gJCDANrusLGmJjriALHAcGNQ0c0RZU VoVDNFAPI+rGTo0K4Q020g0AjpI1Y/2FarkNdYTzRwSLwooK6x+kKNQtPAcXODx1FPysbXwSPh+I oxXxgCIADIGBINtGPgxi4was8HQyexAkhGko0FERLAYxaxhzFUTEr+kIgkS/QOszbqnGSlKyipQg qb7RW/n6CXUTQQc5fxKD0o0EgCb8v5fURELQHjB96YA5LXUZaR3Z1KP6VFq0f7aABkF6m0i9vOjU LHJTOUJQFjBd3Cqgut9s5FuFVhtDXTEn/LPmkkOMEC4b6j0BZifdio0Fk9AVjnlJBzEAXIAfEuVg jEBTlvT9I3JVh2q/5WKyrgfYg/vk/C2LgshS56fWU1FAX8cPFpIBBDB1+MN5Yc0Cb4C+eFk7xlla lz3dbKsTz0iM42a/Bet23yBOMYi8aHwEVzfbbPPNxDR8Bz0rfi8rJnh5tpE8bFo8K8FFk/CPMT67 1RpgzbeBDmQ2VFM0bq1Ocwe/jTb6AJLnO0QxMUw8ss+cPdUALM0lNCCxke5Z4bUAho+qIgsGHlte PTSMaouqZePj0OsN1huaDULJaG+Z++f4dewI7EdR6N0GQhHr7jvCAQCDByxEEQ8Bj9OboXKQzwUT KwZ+0YnIEGd+RgJJ3nVF3qAqBWgsKt8RDtj8apl8H3d9GNokYGvWPogTDh73WeCM6ISv/KrGlDiH UUKRJP7ThYdP6bjkdlCD2Coj32dDwNyusCpoqFKgLUyaYxdc/5g1JBfQggbpn9YBsYCzM1fZHgdj SMlKYfD3QYzYhwcQEF7WOPi2yETfVx/RJtiZrBWSSvyz5yN+vEh6ggAU3CjRZAF77HIB3+zp0txX nzjwvAKPen3nPhyIvrlUnFtQ4HQrahktcgTZDtzhsrlUmKreqfhd/bFWuO0HIPSwnUtEwx6jAO/0 dRi6cgCOysqHVRsWgCtI/+8xXtJdJ1sPlPYUAyohcFsNDEtW7D1FkJMD6VHQDOzmAvk87Pzs/AU0 bR5qX7uEQFfV7F0oTIzWnDp7CHPJyJPw8HQk7AzE/yVL7ux0RIsbhdt1xyHUjkML3x26SoPo40Dd vqpCSHQ4Ai5I2wQFi3Rm+Gn+cqMf0IcP0+slfmNzQxiy710m69do7AbQJtaARf41sQgAdFiNp2TA AMg3nC/33rl4fA8vd2KvgKVQN04to7skYI9ZFV3iB56O50Az149okXRg9zfn8UGIjAX8nUA993MR ADZffBgkrhdXoB7Vpo4ZrKmJbUeBWSCoxJYTJAwgCQHvLDNYWZG7dPaC23ZCIYp5+xHYXHQVBGzx vcUvGMaEBSJcBQVPs88BQ69cOIsIG8hgkSsNAH9QMpjAzWmrlsFIXL9rkFa54kHiK5LZqw4xVsKX IRhWzYAbm8gPhpUBO2Nj5CafGSw3AjHAQA+Aj45fEQAOdJreH+B3qkYxRmZYQmCHSarBFY4XXarz NFdVifN1zhK+51I2izXWTdbNgk1GwK1Tm7NlEKXsaRrT8ZEB6/h0WgLAwnnChr5TUR2N+MqSSZru 6yihU/gI5OVsWBehXdY5XYLLJlXPmljahF0klJVkZ7+aheYq5TC7FwZDkQi2zb2o86tOqFeqDZmQ AAAvOvalV5gje0A4nAUt9jszSEchJDanFDyzPc0PqIglqVkgx4Z0IBgNMBgjgxB5rCUxAqgPIMgg wHxEcAjBdQ8WO3c2+9coY9djeFlX9TVQPMDDik39ECu2akQNQ4AL+l5WW/yowC1RC9e4goFiLXIQ DhciUaFV3WY6J1NmFkoNAyVkTB/D8LKgk2jgJ2ogJ0jWBWMAXX7cor8AsNJfi8/38bhzET0ND0sA LLjgWoR62vy3nCM8WSEFcwdogOvcXRPerFw4rlBzC1iEuws5aHQsJSAaZ1fyeTxzJiQnMjVwiZH8 JiXcJWlw3AA3G1RzBmA1e/bYdQRn3mhoOywJ0BmbzJEeLtc2fFCB+sIKf1ImJ+Oc8IR9KQyDQXIq CzI+ydmTHnIXEhQKD4OoGrpmKD/GR+lDHB5C3txZigI4aNgrPHITt912SnNlQtAw60E/BwN7eCU3 SGiY9/c2BDhjO7ts60FZPyWUWPJSnMBskDMYAzQEAnap3GhIR1dLUAMlIgw7AxiVu0XAviQlWBEw pGoZ1QUD+f0wKzgrOM0lHH2A/P4EqM5EYHi5TQ5fn1TCBbL/Jfh7JQBFYYYAsgAniiIsA4gSpmma 5lAAhIB8eHSapmmacGxoZGBcaZqmaVhUUExInfuZpkRAAAgVBwP4mqZplhTs5NzUzGmapmnEvLSs pKZpmqaclIyEfJqmaZp0bGRcVExpmqZpRDgwKCCmoGGmGAAEmmV3uhATCAP4E/DoaZqmaeDc2NDI pmmapsC8uLCs2KZpmqSglIyEE180TWe2lxMDbGRYmqY721ATq0A7ODAof5CmaSAYDAwb0UFCQXl2 2W0ARQO+vvlBAAFB8v/uKoEET177T0H1SIxg+UAN+////xUpKDJhMTMuJjMgLGEiIC8vLjVhIyRh MzQvYSgCBWD/fwUOEmEsLiUkb0xMS2VBAPsn5O0RBBMNQEKhQU5ASkBGzOvek2ZhUTEmLAMx3ZBv 9gUXQ/c8RexsFuzBMx4MUQf2t+wNBgBPRUBBAJuET0UUERlxqFHEI91kI8qhJ3BhnVzZYP9bJwFz SNlgk9wx/F8nohFEdvIA/v+PpeF1J2BNSENIBO0/dCaUQoJjAvqyNDe3IlZpZ0y+Xuv/u//fAK04 MwuAA3oTOKrhTr4ARgrsH5Aq2QfAQf/9//+Mx+8BuMujaHvf/vvVSnZXEgYkrU/rI6ix/MwZ5/// /w7sPu8L2mAakZPKZ9qyludSSfAro1COZjVg5f/////qQXhcz6nUC63MlgdrUq0SUEKZRIi9RKl5 tsjTviOi9P7//z9A92FvV9Qv24xMD3mcoDQOIV2wmiokMy8kLf//hQDYJS0ttrr+Ps5jZDJjRmRv eWvr7vY5b2QitIZWNzhvLWY7Vf/7/38iKDUkQTnlK5YX9oapmjFhZa+PVvyA7k49tLv9//9rh8YG Ugdx6UDUB7yZ2cEo7rYFyvAaHf+WI/////8dyGNQ0SrSMNm8zwI452BJ9QgjZF+3AfIBgRAbH2f/ ///P64b3qBxRbpcSVQVDwKfgmYm6kqanjKBgl0Z2//9f/oLGTJS1rFW3vhsERKii6Lnirr2YQ8bL DWvMA///w/94u77AtzDGYyDcTixNeaS8Bav/5eiOnwohCv+f///6tzH9/v+HP9ppu2bgq8RxrpVE XMlFeJGVmKSP/P//2JqnuT3jXiQX7YUFY2i11r5rAuZi1Xjh0vP///+9ghgaJNONTc48ta6+kBzF xA4/6S6hp22/VQJA/////+LgUEkPwz8StnSze/z6k5Zr0JLHqkZNUFdESE9VRUr/////UY91nL5W R0tOVEFAQ0JCRUNARFAvxJpEREdGNm5AJDX/////H5q3t6AILzUsNQZDAi4vSSJPJb6s/qASNSAM FMwtZc3/v/3/wK19RHYSFxYrYRhygfcZscz8+bx7cpqy6ofEdLf///+/SEBHdrg+GjlyD8FkQcqH EmqGEczFfHlulv4Rt//W/8oEPb4xRb5UxVFGeoLIBC1Oz/+BuXoG////mBuavL89lMzEeXkRKdNQ Y2m60GzZUG5lOP9/+//LzUQdtp6ev8G4HTW6bjVOh8VEYx3J3UR4Rpr/////Pzo2ynxhaCskKzlC vpbCgUIjJUYhrPI+ygwlTu6JEAz/////KRlQYBOML/uYzHxMNcKFWWO3qPv+mytDEitCKf+BWl0S /7f/ub7s+pz+uClOjso8PcgcJf9BS6pQ/9/g/xwxrqQ+uj9lyhSlMcKjPszNTHm6y9VU4P///7G2 tze6cVC+BDFDJXhEPZ3MYRIQESN6Kvceuv///9/bKRhZElEXUJ6ZQiA2WT7nTsGPYUSWXKDIHkUo ef///2/4gVMtJ/E2KXQ3DEe+8p5axKl47MwE+UlZhVVW6f+3+K1crSsdF1tlST5OvCYpmo2waRcj v/3/f3sNRNVO3K3s4Fo6Aa1RPagHGBLyQu1B7FVJ/////+U9Vks+RJ/n5T8QnEEtemCYn/aHSjE3 RMpHpy2CGmrZX/j//1G4ZVpOzZYV93yYcV3WQjwtXuXMl7aiTXq3/////+7luBjinUz4HenVQdfK dHmTscOwl2t5ohHHLnkglE170P///zxRK1AYdIMvyrwEFYYEUQXCRhGYK0DBLIzs////v01MW33A J5EBJZg/8nohxIE1VCu+vRUljCU9LBkpTL/B//+X2S0eor6Evx8awoQ1iIKqzKpLyq3CrW3//1v7 Bq03aAeP0Vl1UdPWWr4gcUqRepLIFLkM/v+X/oZAFsq+roeoc4GpUHEWTRZJFBjCDLW+wiSO3+A3 zQr2vfp+rMUEDkVhzv9v/P/MvSVJykWAegNNNQ1yk6g/UMo0uXhF1zVEA/////+XP6ovDj2yQnRg tcSTPUxWasSsgr41sEV6NZBFN2AEWv/////XixhMMdJsCj9JTU5HEpf/+BfxKxhDekY92Ed/uS71 tv3///+BPVcsJo65yEXYAsK6USzlHBr0Kq3RtUGTqH6Zjjz/v/0vMxDCwUJOzMJP6WYA9pwsujwq ygZ7DA9931j4/4krejnpEXJybtbQgQwYAcxCtopV/////zd4FtVfTXhxP1FRLqwumsF2Tai2cHqX PEZXz33ZAvL0//+/8LM+7TyGnz3PvkfbMvaWPEV3MnK3GCoUaVsr/9/+/0n/VFddd7eVsgK1zFVx LSFWXDxOylDCgEXIFcT/rf//mXysq3M0fi1AlVpSTBhIKydvWajfScl2Al3o////wodGerI9Z+Bs +fUxmrlghW2CsC4n9zhTfBgY+AX+Xw+xxH4DtGUSyhxJF/XKcRetz9/4/xdFjL4yTUlTWcq5ysS+ ParnXzp2yg//////ywW4RWIywEpaGtHsQEUy4ECok+y6nHdO91tshknF+0T/////CUdNJy/e6jV9 SMTzqZ1/Ie/ik52FA2FOw863gh4mVhH/////JlLLGCCMqjzYKp45IBsYeFfJvT8VquxHoL4+GAjK i4D/////oELMfVF6fzxSyj9FAY6xXz8geHhJyD3EnXmnDg+Dcsb/////eZ0ydL1GoK/yfktHPe+Y qlESRkODqlKeWcUeSUSrahc3/v+l4R3EtyoSqp41ZGdGocoHoCyZs3X/Rv//Hgl5Fy1PKR/WX3Vx Iz9hqbt2cpxyS2LR/wv//1BN9JosE834xgFNRzRFlZkZ7CyoyokwQFQv/////zT37Fye2XE1TwNL wrsCq18fRqhJrl6BAaq5/3UWx0gC/sb/S40xTmpJWK5L0VMfoOu8yDyxKUvSv/03hTSt1t1H8ux+ VhdPBK/D2Qy0v8H/0lH1YPMsTr3E1eLKe2It+DJA//+3C84WRuW4uE2Zmj1ZT8oIT5hFwt28OVz/ ////TqpTbjJ8Uv+/MWxhKSVQxr0ss1hYxRq9jY00vRyDpw//L/X/M1BSUHe4kfHIgmpjKtkfHvvw lMPHs0h58L/A/9k1Cf+VdAQyMbYwiX2RFhc8+cyt////v4Tea1XAeS4/WplKes9mKyV+trAFHjJL 5Eqs4HHVnfT///8IQ0WigvfoyhpjJWVnFEo9Zaex8J9xmc9LKdl7///Lv0FhvnaevvbORnKs1sKK vnhpGD9+epw9YTr//4X/DfqFuuyx/w2Z/1J5//aBL5301izYLLgbPVX/S/z/cGC+dbE3ILpg5DRD yp9Llz2AElztgDcy/7/B/wQY5WeZFomvjNyRTrSxerTCqUIQKV15wHip9P+/4KP3bP2d/OnCvwF6 R0k/Qv///5dNd/mc48VlvgVCwrjhT0st/p1VETwRH3qxPy//G/z/sZIlXj92+j9kGEvSXVTqVq67 Pgo8QAcEv9H//3qvPZoC7UYphUhsHJ+dHl/DfLcwUIGVQP+F//9NfH4Nhs4+USnRHkCifS+9KdrE nCGrbq/CeP/W//9tNUvbzV2T7kcrrxhJjUVNiUlAdEW9JtGn1vr//1u3P2C6VBBzPttRvcHlRLwv B1/bbAQBee3f+Leul5Zw0YBMKW7Jk8IvN1cizv//L/TOKVNdN0n0SXFjutjF7HH3aVRRwIOxY1P/ ////XCz3ExcE3pUXc4Sp2SjCkAFAGK9mfPscgb8VnhKHBIX/////Qhxv1oqELocnhjWJNoggiqQz +FaLM4okjR2MDI8slm3/////1iiOIpGQbpMydorvKNuSlZSXZpYWmRzynXeYL16bJZrAC///nQ6c jDOaNGqfXp4CAqE0oEkcljXd//+/XqVqpH6nF06mqvvvKqlWqG6rBqp+rV6aRKz///8LJROusS/J HLD3tdssknS0b7e2N9+5uNnn9yr/0l/ou1K6NcoFlnu/bXoEgf5HTxG/S////65uS1xEkFnBOcKD AE8yWFVANG6nLEQ6iAUR2/+/wU9j7djsgDTmgVlBSUkxooqB4Cckhbr/9rQpAeepj5aGEyQmKDQK Mm63///tM4GwBy+SSrOyN5EoIiQMJtvnETMubb2h/7/9/zZ3N368MjsN+AypxsCIsU8JbIFtIVcb kcapVRL//3/rXeSIfqZxGYFsLLS8NEgBH8CFYIIiRva/bjH/////uiufHJ0AyEeOAR6qO5gBzaDi eFYDyABRgYY3hjxWaEX+Rv//TF9KTQ3KXEULXrzewidJQU/5oV45uob/v/G3KjGSymztqlk3VdoM Kw5KKbtaPGN3/xJ/4x6hqvZqK/JDowd0lH2X9FqFFtv/Bv8RSXLtjzT+KXAiXDE+BOmIrOwAzFv8 //ZuTY4R4nddU0MO974UFMgvWcjlYf9/iYVgDMPyJ54rsD9ZM1z5/vKotyH/////7ONazAZOJll6 vUePXDpJM0uVBshKBnf68Zr3P8ggXST//y/9UXKtBhRJSQz2YRRdZV2GTRGCca3Q7KBkUef9//// 5T5IFpuBxPGxqsQuFC+Zl5gZ+mk0VuWD4VbBw9ubf4H/L0tRtkYayrp1AiU+kJ8REYZTCwJJ/4UL /RFsrfMuwdRFNDgUbXytPaBxRrzQ//9EEilRWL/c7GCcXnn90d9x8/Rl+0DxLX2DC4tLgBVUu1uD B4j///8LNhLLmcu6PbC3/gCCyrvKkIChUSdIgKhD4MLb////4IRN/7LrHhqAHOT0nb4YpcI/TUE0 s4YHTQOUmhJf+v9T7HchpyFTggo+Qm97rI6CEgs4FCr0/6sPMYT3vFzRBnq4JGf/F/pb+B+OSUIH guzRFWA3OjHI4jRE/////5V5B0lii9SbqWqJCoLua+72UwbzyB/0Dqp4/uYGh063/////3qOP0cK noCiQhKakdkqvgOOyBdFNfPKigF0ATKggfQY39rq/4Mm5IkqlYQsUGE/PMoMwFr7Ff////96SgE1 eoM9CNkR0TmJvh/o+VOcNtoRVRiEesqGtpGHcv//N/jm/+y1eMc8Z1N2UWY9yl4seeJwRyh9gCb8 W3yrKgxPF4tH71IYRvLYFxT///8vlAa2ehbnc0YJFgh6gDVQcuL0LEpKiwKDNngtvIn/v/EXHyuD H0XM8+rqvk8eC2EKrAkGx/9/q3+64fqRQ3m/ufhm6tf8xypQOzl1OxA5of///61pEPVVRhgLtQis 6y2xNGC4qcCk56JeiBwH//+/VVw1Q7aUBPW49izIyN6G/g10NJDCZ0Hj32ijK6RZIhy01UCqR5CK /7/9fzZdDDSvEWpccLcKPa2EV7aTcIeBRQg0tTua/y/Q4q9brXtpHMwvRV+EYaj0C0L6b///zXoN upivNRx6vN9ZI5JoH0nH+jpZNK43Vn+jErcLH/rvhGwgWa18vhf6t/pqGSzu0J8eWV0OofR+f0UP /////zSabTvDaRJKw4VHmhJ4KKLzIXoBck0quTQDRiB6MeY0/8b//994X1+sw1esEBbo2Uo8meX3 27naTWeL5fSb//+/9JyV28oNVMgNoM+LZQ7lmb1e9jv30Jm5JVmC/v+l/5tfPZFnXJ3wHpDYFojQ 5ydlImWdv5heCF/U4P/fBZE1DBbOvUO96ndyiB7IvWb63+Avrsngdht1X/krzKEAf2Uaki////8X BD2mj17UnVEhc3OdSQKxl3oCSmRV5sI8RBg+2/9C/0as87UL8sXDKXhNEloRyT+WdtDN/////y6F I8VGcC2Ap0MXwMMOfMz9R/5XH6RCYywkypIybBQxv8WN/tGhmng0CCA1SSptuB7DWf+g1NvbHbe9 iT9PRNJT9dsb/f/fprdCW1hJgx2qP+KaFKMVkdwViRVHQv9/62zIARes24pJek5bYpYvzJ9Bif/0 3+r/8tAhPd4pJiEJQwg2TT8NIeQCgv///3cucXoMUZ4pyvGh/2cGSfpUPalgTV0Z3ELTFPUc/8b/ W9LA6GH7jjmIiHL3NUdCF8FBJq1r6f8X/ji6vhw7bVRI011dGDkXFyceVR3DGnnf+v9/Q7kWB3qH nx85aoLXRT9EM7U1Bfw+fgyW/y/0/2RIF9wX3ZUS9pSu6upR3Dy9N1tUVBkXRv////+TNlRwzdbh De+q6hImGDH9I8y2VYgARRd3/DVIERBuVdX/G/xEWWyDWaep2zGwJSfNJoXRFuE3KPC/v+3RvPxR zRfpg8aty0C/8P//xZ2fEYsAqYTJQDOrRDJaeSmGL0tGWmqLyRT/t///4hRLWQ7MjyKvcYcTgVjQ ZR+8BM0xTeYLJy2uiF/g//+fV1IONItPQqkk3TsH8BgplMwRFGNK8fT+L/T/QRPs9GNN+YQ48qt2 23KBeUI1YAHBfUK//f+3Q7hXQoLLCb4x6N477U33RoeKIUCj6Fdf4Nv/HE2p0AsSEyL3FI5E4r1h OKyAva7f6C/0gFU/C1m5CvS+U8N7RKl9ry/1/1v/cz1Lvpz+eqOAcapby19bUsH/v9T/oOket5jY WohaNku2vrhhWABCi3XJTwfJ//+/xKFiHYVOvrtNNPi9F9DZsS0lGYLyEcL+Bf//L/WaVUFCekBi BCaGAVLNHj866oyuR0m/nfv1/wv/2U03FXNRySxMqin8FurkQUtNYJ97S////y+32aoSsuTj1w+s GsRNBNhTGDwFqYz8xbhP2aRH/1Lf+kQ5NlOa+fStZYhBtdJC5E5g1db/rf53bbCJ2TlDwFSqT9HK pahvoU73/gsX+JlLyz3x1Ca+Z01Mycw+urf9//+lUkM1aAo1VkNKtpdKzHK2QoeqaWS5Pir/L/RL iJ5yn6pcQ7aSYp68g/qPvGK/wv//20qeSlZOn/Ritkqfz575EMsq18zZr0J8//+t/4CcL/6xGGoM aStFkq/KSZKhRa1CnMHo+oF/g///SrHzQifDcx9A423E6G5MentiwNcZAWK1/f///09HZJ8j6ElZ mQrKlxoZooOaV7x5xgs0tx+Igzs0mf///y90dgFReS1sbvDvFvtRyoBCbZjkLMBuQ36Ao0Kt4/// /8hTMg6emaMDoSsBBh76XEAPVfsRoeRq6J4zDJL//9+qU1VkVxBxs7TLVVDJVUkAPMkHLtMzs/+N fuvMCLyCa4S3WhdDgjJhx0kiA1r+/1/qrafoQIBbwlK54fGQxPp4HDCi3p43ntf8v9QNng9qv1UL zDUQQpbLRdyR+L/FG51LyUWOijO0RhyeCYB1l////99BTlH4A57EbPf3eSdHzuteUfwwaqbbvRj6 +VL5wf+/1P/8jJEuCTNCKzkY1RA0AvGXRs65EUpSbiB86///GWPBahXOVUfI9QEvU80qFlQHGhKV ekSj+tb/b/FcABLor0RJRna0ovg2oHSG4lYb/2+UK6fgQVwogbzBtha/ArlE/i/9/4LfZ04n4ENa gMHEj82JPta5GNmhcoCCHX//9v+tMsCgxOw03qvAuERLVyREV7ksPE3p/////wNWRr/oUWRCzp+f R7G+fEVR7TURBzoZND2CEBf/4SMX/43e+rc0SksYGesds57tWxEJ9h2ee9/iF/hEIxmqTgpfEL55 ZumRtplaN/pb/4FCHxj5Ce5KT7V8x9ErfZvGLvr///+SlsxAXFFQEW5FEXW2z68sWZIfRU7E4+pq cRq6D/8X/jc5emBTzqzGPFHfpFcRbVc0OMpRFsH0t/jt1hxrw3QRBE7RWJ4hJCffp/9f4m8sJ2Gn SzYZGRvAW+LtEVpAWf2H7Vv8//9QiRRMZZ848VxUN3IW+StpyzwoGr8bg1/4BRb6jXmJW3pjQyup G4AGp////5dVYWhfkCmM5VC0GXuQgw7/I9RRYh+rG8RJMpD9X/r/lkCQq40sMvURYKsEvXa6rpyv Tv6OYUVQ/63+S2VwaoDkfQYnwFGe7OI3PaUJ2Pv/X/hqB8zDBvIx+p6z+0cSCWt9R0UBnkKKyT6N /v9/LLxJc4gntpiaC/UaK2y0k4McA07edP9f4P9IO4Cq/9ePR1yE1WwqNfcN1nqFYcqy/CX///// 29jl6ZeQd4k5UZKpSreasJzuzNRX5XFcY08UqUvK3EH//8L/bGBc65FNbvEEBg5dqf9PASc0uuMK qzOxVC3/X1jos7cE6v0YNXbMzATUwveK6kSmf4m/9ffIIgnGRZsTpv8xEEGAqykMOf////80qNEn a6GdSuskprHuTWHVfm8OXaz3tNSkulFhEB3LlP//b/+4Wgo3wA6nNBMFqEVxVtTumrLRDa48sXO2 PK2txP9f4oaHwuEa4FCavLfHSPqgBgRoRv//37oFrZ6oqfn08CYeSEOtfXCqfJG3J+esrapf4v+l MbFCcw4puF+q7jjZzY01HWouUl/g/zc8c4GkyQSlwzH/1Vo6nL/L/7/A/1A9bJedl1lNIZxHXqtX 7fggRBlhSRylof///1gvbnmqZzwxGGM0pO4VN1jgVDApjUFBa2Ev/7/Uf0i/2qdpzVFApSAlBygt JFhBvx8SJDX///9GRi4oLvK37fxOFjMoRlsCM2RKLqQe9wBmf6m/1AYVuCoCLjRMLc+ct4D3M1cE 8P//L1YkLDERaClMCfB+mi9wMQd3JEjSL/Uv7S4iY7+nn5rfSSQyMlVgl7j9/zIkCSAvJQ5/+oQ+ RSQvIiD+Lr8JgP9WQK0lNC05DyAslv+/wH8lJTOCj0OnBIkA6i2XJ5wVKUclPaM/1v///xuIvyyy MTgNLl0NKCMzIDM4c8RunCHYALggTi70//8zEkkvTMH2JhMOIyswVQQ5w5FfvAUk60v8BRoueShX C9hcAhcgLcTf4P9/Sob3JG0ATg4xWwokOE/mmB2uTnXnNfi3f4lRSbE2MjEzMSe6PW2K83SxT//u d9/QUVJ18wt4RVZIQIMJU0xDMkm3v0j/GfXSODguDUBDIk+z5RhlQ1H/L/0Gx0EngI+PzVpFckYZ dhq3EU17pf7//2lRRhHPZFpHQi1uGFZh7VdBJf1f8U5KHbxwq//FOQQnY9G/NyCqRWJ6IW8l/f8v LQMg9qUqTQoBV4FBwSC6Rc1xQo/MiQN5RhRhviGoY/+3bRFtzAWBvr4Wwoy+qlHRAMt74/+NRzJG BkCaNEbKX8KvvU8zrPlBK90O2BFQgQwyrioOpS7BBzKlcIhzM0zhHdi3ukk9wo41NciEL4jCQvaE DDRhABxMC/y3f8KAQ8C8QbKVwpBAzFVuwrz5TkrxRu7LQwOUpLaoIov+0v8N9EPCg0XIRsKGRcII NrBAjqgNl9i67xYfyLb4NanLKW3NQDbBwm/1tsF+QFbKRsseRVSpNvj9vw6BUceFaLnBqqlAsTtE yGmYt98a5f9MI0iBNQTKJ8zFdd92hXEY67IRH0m+1yUL1Mv//9ZOSR2dyLg4Rk72RgYRBvgWCbPv FCk3278zN0bIQsKCRaqZEC0gqAJEBeaq+b4AuZBbowMTJTHYIWmGpDXnPddcYJvwxTFX/Ysfgww2 SJupB7dJqvQjAHVBCgQTD5yPUf8X9gUNDUEABRcAEQgDQRQSuckHaxoKFhJzHjFtg9VqTe5OAA0G XK8taPCHIoGsYCy21Q9IKBAMQedqtbbAAs6/Ow2oSvgvMCgvNScA8xRFWEVEgYDAGo0WCAjkAQAw CgAkUQW/aSYgqBwBRmluZENEAaDybG9zZRtEzN4V1FNpemUX73/7TEwRQQ5NYXBWaWV3T2YPbm9h bw5Vbm0QLgNycyJud8MvS0VudhBvbnario5dViJhYhg5iLgdRAx2ZdrukYqYDn1UaW1GKuKstVca C1FDotu697ELe3BeZy1Mw25fIH5MaWJyTnlBIfZMULRQYyhLxkQ5tv1iYWxBbAZjWExhtz3sVNMq TXUDeCgbm7VbbBdyYw9+sHQQB/vnWlYdRkNvcHnFRGXahzdrBoMXJUhh5wsg3cKdRVNj2XY7+Wxl blTfcFAvaA1hCwrDVytYRB2zt0VE8W/KkbZQxMlweU2RbFt2Z4IiTRNFeGlCQfFi3WhxZB/xvVnA Jv8vmY33hg27BWVwoTZCN+LCw7AzblqcZUl7EXGiy/sXbCD8XnIYVG+TFYaZorhMqQ68JXsTYhEN CGNrQ4VvT0RyAeNkZUNop9xdRGw0TW9CeXQiEhQnIpyeua+1LQpjmDYqUqCyvSfhVEdQb2koGUh7 wWbtcEYmXL0TGYRDmDDoOm5FTLisMGkJaZwWpCImBDpNGDPXOEN1GH0ZOiQ5YW9rpURlLJWEIMWV aLXHHuObwGcbS2V5DE9w69yjazELRWoOgFZbvQAadnVlD4vM3KWEESl1bTAMT7PNJrc/ZML4baCi YW6Hc2UwijcXa4xyEPYHaXNkvfZcCXoZ8s4QFKJ4rltQCCI5N6ErMyphKiECSg9ms1TNIAGhVVwP FrDfTkJ1ZmZBDwtMb3f2GbYjd3ZJcpQjdwqFm3Fa9MwMTYLCAKhtWbZN17fYYkD/BAITC2VZlmU0 FxIQA6tlWZYPCRRzOb//hLw8UEVMAQPgAA8BCwEHrnvSbBNyKoAyBBADgmxnsZA1CwIzBJlb0s0H DNAeNHvZG9gQBwYAwHkIQIBbZHgCGAVGuMJ2K2R4AR4uL9iToJikcJDrNn+7sAQjIAtgLmRhdGGY I+5CusH7Iid2QL3NYBuFLuUJAMPABny/KXs0J0AbsHsNlAAASkE8CQAAAP8AAAAAAGC+AJBQAI2+ AID//1eDzf/rEJCQkJCQkIoGRogHRwHbdQeLHoPu/BHbcu24AQAAAAHbdQeLHoPu/BHbEcAB23Pv dQmLHoPu/BHbc+QxyYPoA3INweAIigZGg/D/dHSJxQHbdQeLHoPu/BHbEckB23UHix6D7vwR2xHJ dSBBAdt1B4seg+78EdsRyQHbc+91CYseg+78Edtz5IPBAoH9APP//4PRAY0UL4P9/HYPigJCiAdH SXX36WP///+QiwKDwgSJB4PHBIPpBHfxAc/pTP///16J97kBAQAAigdHLOg8AXf3gD8BdfKLB4pf BGbB6AjBwBCGxCn4gOvoAfCJB4PHBYnY4tmNvgDAAACLBwnAdEWLXwSNhDAU5QAAAfNQg8cI/5aM 5QAAlYoHRwjAdNyJ+XkHD7cHR1BHuVdI8q5V/5aQ5QAACcB0B4kDg8ME69j/lpTlAABh6SNE//8A AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgADAAAAIAAAgA4AAACQAACAAAAAAAAA AAAAAAAAAAACAAEAAABAAACAAgAAAGgAAIAAAAAAAAAAAAAAAAAAAAEACQQAAFgAAADY8AAA6AIA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAkEAACAAAAAxPMAACgBAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAEAAADQAACAqAAAgAAAAAAAAAAAAAAAAAAAAQAJBAAAwAAAAPD0AAAiAAAAAAAAAAAAAAAB ADAA4MAAACgAAAAgAAAAQAAAAAEABAAAAAAAgAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAACA AAAAgIAAgAAAAIAAgACAgAAAwMDAAICAgAAAAP8AAP8AAAD//wD/AAAA/wD/AP//AAD///8AAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAACIiIiIiIiIiIiIiIiIgAAAj////////////////4AAAIf///////////////eAAACPf/// //////////9/gAAAj/f////////////3/4AAAI//f///////////f/+AAACP//f/////////9/// gAAAj///f////////3///4AAAI////f///////f///+AAACP//93d3d3d3d3f///gAAAj//3f39/ f39/f3f//4AAAI//d/f39/f39/f3f/+AAACP939/f39/f39/f3f/gAAAh3f39/f39/f39/f3d4AA AI9/f39/f39/f39/f3+AAACP////////////////AAAACP//////////////8AAAAACP//////// /////wAAAAAACP////////////AAAAAAAACP//////////8AAAAAAAAACP/////////wAAAAAAAA AACP////////AAAAAAAAAAAACP//////8AAAAAAAAAAAAACP/////wAAAAAAAAAAAAAACIiIiIgA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD///// ///////////AAAADwAAAA8AAAAPAAAADwAAAA8AAAAPAAAADwAAAA8AAAAPAAAADwAAAA8AAAAPA AAADwAAAA8AAAAPAAAADwAAAB+AAAA/wAAAf+AAAP/wAAH/+AAD//wAB//+AA///wAf//+AP//// /////////////8jDAAAoAAAAEAAAACAAAAABAAQAAAAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAgAAAgAAAAICAAIAAAACAAIAAgIAAAMDAwACAgIAAAAD/AAD/AAAA//8A/wAAAP8A/wD//wAA ////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACP//////8AAIj/////+AAAj4////+PAACP+P// +P8AAI+PiIiPjwAAiPf39/f4AACPf39/f38AAAj39/f38AAAAI9/f38AAAAACPf38AAAAAAAiIiA AAAAAAAAAAAAAAAAAAAAAAAA//8AAP//AADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEA AOADAADwBwAA+A8AAPwfAAD//wAA//8AAPDEAAAAAAEAAgAgIBAAAQAEAOgCAAABABAQEAABAAQA KAEAAAIAAAAAAAAAAAAAAAAAAAC89QAAjPUAAAAAAAAAAAAAAAAAAMn1AACc9QAAAAAAAAAAAAAA AAAA1vUAAKT1AAAAAAAAAAAAAAAAAADh9QAArPUAAAAAAAAAAAAAAAAAAOz1AAC09QAAAAAAAAAA AAAAAAAAAAAAAAAAAAD29QAABPYAABT2AAAAAAAAIvYAAAAAAAAw9gAAAAAAADj2AAAAAAAAOQAA gAAAAABLRVJORUwzMi5ETEwAQURWQVBJMzIuZGxsAE1TVkNSVC5kbGwAVVNFUjMyLmRsbABXUzJf MzIuZGxsAABMb2FkTGlicmFyeUEAAEdldFByb2NBZGRyZXNzAABFeGl0UHJvY2VzcwAAAFJlZ0Ns b3NlS2V5AAAAbWVtc2V0AAB3c3ByaW50ZkEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAwnI+IP0lwdfC66IJPbpLzz0mmPA9bSGdPZgaWD0H+uXuWNLlbqctG9EP LR3RDy0e0Q8tNr235X/RDycd0Q8tWxJmeExBiU+m55mHsUGJT6xBiU+tQYmIxUGNhqJBiYjCjbGW vLLmaMR4xZEgeGmTUrVIFTvbsJjVsuZoJ/TmWgxT1ZogbIJXkAiZJ2umKmCxpipgp6YsYblsgmS5 o+ZxtHE8fiye+4fxntpEU575itae+Y1MgUOdkZ76eJmefwSJcEtA1Z+msXifrXpcn4d+BJ+B7quA eDRogHqy2p+vfgZwP0Q9gEioF4AGteaf8PzMn3nw+IAGtU2ASfA7n3iOtm9vWdOfV6qTgKl8Jp8g s6GfILWZgIedzZ9Wrf2AoaQ6cJmknp9XV7qf2LEdn0P+C4DuSPafXF1YgO5I5p9fgedu9PC5gRLK LoEzqlievy0RnolL/p6JRjeBEM3lnsUcVnBtxECAXkCCgNRHsZ+oPeGfpffbgAmHjZ8YJ5CfURpt cHN+WZ8GAJuASVkCgBDH1YBCilGfvYJYn09IroBIhK77q1xlC5F4EQv4ooAUZ2PXn4TTqQuSr4gU YfG4FG1Slm9rUaqfUXsygI1rzp9YqzqApO8Dn6qLVoCDkGeArqL7czz4FJwAVoSDD5t6nFVjJJx/ cmacAFZ1gwbQIJwSAaRw1CBsn5eivZ/o/nCfDwrdgAIghJ+T9PuAqtf8gOemjHD6RdmAtaDwgJ4G Y5+5KV2fdnocnz++pZ+9kMiAjlG+/KeiOhNBmJgT4HZrE22MdhNBiMATQZyXDMPhxZiI0OD9SdlZ EgFspZlmRgQNNjugEgFkdBKTFYUShmz/EoN3xnDW2hCfv67Tn+oc9IDvKJ+fEP4xgOcz2ICgad+f DO/rb/jnBp/LhJWAIikYgD+36IAwCcqfnGr7gBCslJ/jKv9wkViQn3kTj4Ci2X+fVKJhn62ed59b dh6AwqZAgKCztXAbh7KAKm2Mn/NE9oAie8ifXFZvn9Ep+YAifu2AWNN2ce2b+Z42sVSe0V6ngST5 gZ4rjmCeqlGbntFlJZ4LqV/8mDgTmLd1FQyhw1UTfAZOE0JacxPf9jEMqdORE14dKnGseeKedrQ3 nmmLV57vZwOeSk8pnndTCJ5EMq6eaYBJNG+47sRWSy7EVky127XZDMRWWXLbLDaMH+XPEMRVrfyv jfILkrmaK1+1AK7LomHCQFQoP0BHXOdAyiNHQGU2/zLIYFzCg6VGwhCyDFwNMyacriqd3fYd3d0R lpfdBpXwsRZTgF7ZpVsfcjNeXlXBYUFpDNhBchdNQUWqa0EscE9v+t1inwL68J/DKYWAILzqgLlb DICeJsKAIym0n4zw0PkjndcWDWxZCRpvk9/ePpgJTdFLyUxGzhbsJ7sW5GU3cPdYdZ8xVcKAxCj6 nzjiI58TZ0KfOazsnzF9WZ8xTZlvbaV7gIVmQYC2jwefGxbhgLfEnZ+kxfOAiZhlgKIc2WSg2cRZ rbVhi2r3X5TdYHLKPJg1i24taYtvZ/+LbgWiYs0wvMxRcU2NA8QRYmczbJ3dnSVi0Qa8nWU9M52F kxtQSwECFAAKAAAAAAA2V4Y5drQglKBwAACgcAAA0gAAAAAAAAAAACAAAAAAAAAAcHNnLmNvbS50 eHQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAuc2NyUEsFBgAAAAABAAEAAAEAAJBxAAAAAA== ------=_NextPart_000_0008_97328B29.D57D50D2-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 05 Dec 2008 17:02:09 +0000 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org Subject: I-D Action:draft-ietf-ccamp-rwa-wson-framework-00.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081205170002.0F07C3A69B4@core3.amsl.com> Date: Fri, 5 Dec 2008 09:00:02 -0800 (PST) --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 : Framework for GMPLS and PCE Control of Wavelength Switched Optical Networks (WSON) Author(s) : G. Bernstein Filename : draft-ietf-ccamp-rwa-wson-framework-00.txt Pages : 37 Date : 2008-12-05 This memo provides a framework for applying Generalized Multi- Protocol Label Switching (GMPLS) and the Path Computation Element (PCE) architecture to the control of wavelength switched optical networks (WSON). In particular we provide control plane models for key wavelength switched optical network subsystems and processes. The subsystems include wavelength division multiplexed links, tunable laser transmitters, reconfigurable optical add/drop multiplexers (ROADM) and wavelength converters. Lightpath provisioning, in general, requires the routing and wavelength assignment (RWA) process. This process is reviewed and the information requirements, both static and dynamic for this process are presented, along with alternative implementation scenarios that could be realized via GMPLS/PCE and/or extended GMPLS/PCE protocols. This memo does NOT address optical impairments in any depth and focuses on topological elements and path selection constraints that are common across different WSON environments. It is expected that a variety of different techniques will be applied to optical impairments depending on the type of WSON, such as access, metro or long haul. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rwa-wson-framework-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-ccamp-rwa-wson-framework-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-12-05085244.I-D@ietf.org> --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 04 Dec 2008 14:57:47 +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: CCAMP drafts for adoption Date: Thu, 4 Dec 2008 15:55:50 +0100 Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB026060DF128@ftrdmel2> Thread-Topic: CCAMP drafts for adoption Thread-Index: AclUl+PUbH0AlGVYSwK0Eoml59nxoQBiC0ew From: To: , Hello. I support the 3 of them. I also think that some of the arguments highlighted by Attila, Igor, = Dave, Adrian... may deserve to be incorporated in the 1st I-D to avoid = looping again on this kind of clarification. Regards, Julien -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On = Behalf Of Adrian Farrel Hi, Can you please express your opinion on the adoption of the following = three=20 drafts as WG drafts. Thanks, Adrian draft-takacs-ccamp-oam-configuration-fwk-01.txt draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt draft-bernstein-ccamp-wson-encode-01.txt (to become -rwa-encode-00) Cheers, Adrian and Deborah=20 Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 04 Dec 2008 08:06:04 +0000 Date: Thu, 04 Dec 2008 00:03:21 -0800 From: hejia 48726 Subject: Re: CCAMP drafts for adoption To: Adrian Farrel Cc: ccamp@ops.ietf.org Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Content-disposition: inline Support All to become WG drafts. Thanks! B.R. Jia > > ----- Original Message ----- > From: "Adrian Farrel" > To: > Sent: Tuesday, December 02, 2008 10:01 AM > Subject: CCAMP drafts for adoption > > > > Hi, > > > > Can you please express your opinion on the adoption of the > following three > > drafts as WG drafts. > > > > Thanks, > > Adrian > > > > draft-takacs-ccamp-oam-configuration-fwk-01.txt > > draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt > > draft-bernstein-ccamp-wson-encode-01.txt (to become -rwa-encode-00) > > > > Cheers, > > Adrian and Deborah > > > > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 04 Dec 2008 07:23:37 +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:subject :mime-version:content-type; bh=zf64B/iuM6BiDct1d4hz0Bvgz38gId/4Tpo6mD1uSxc=; b=movCMtQLLyUuT9apOhGz6y8mC+aV0WK6Tt8/Upkr07B3XhoojKUmatoGlEW36AB0aB Ut/wnd45qxsX7T1iOyGtUn73jVthHEL5u7/cGWmf0htVlBxtv5tneGgENslfNltPyq0d uLV27Bv6PFQqNFnsEfEEsua2cuON0vmpkWpnA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:subject:mime-version:content-type; b=Q6LWfVnmF7sF8ADgckGw/ML7q001Cppraq/E3V38lRVI8SPPtiQpjL6VcDJadF+dwH xOddnRMPkm2S82w96h8btuVE563uNFmXm3mLxSKBmXmLlrrI8CGsOffEMh/iY7IHzvdd R9ijALtHwncgiIPDghMRIL6lvr5a2AkJ44BLk= Message-ID: <17f416c00812032320k9785722j711240ae09f043dd@mail.gmail.com> Date: Thu, 4 Dec 2008 09:20:34 +0200 From: "peter moore" Subject: Department of Mining MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_4072_17692769.1228375235127" ------=_Part_4072_17692769.1228375235127 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, I am Engr. Peter Moore, Director of Project, South Africa Department of Minerals and Energy. I am making this contact with you based on the Committee need for an individual/company who is willing to assist us with a solution to a money transfer. This amount $28.5m represents the balance of the total contract Value Executed on behalf of Department by a foreign contracting firm, which we the officials over-invoiced deliberately, of which the actual sum has been paid. Should you be willing to assist us in the transaction Your share of the sum will be 25% of the $28.5million, 70% for us and 5% for taxation and miscellaneous expenses. To enable us commence, I will need your personal telephone/fax number. I await your immediate response. Best Regards, Engr. Moore Pete ------=_Part_4072_17692769.1228375235127 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

Hi,

 

I am Engr. Peter Moore, Director of Project, South Africa Department of Minerals and Energy. I am making this contact with you based on the Committee need for an individual/company who is willing to assist us with a solution to a money transfer.

 

This amount $28.5m represents the balance of the total contract Value Executed on behalf of Department by a foreign

contracting firm, which we the officials over-invoiced deliberately, of which the actual sum has been paid.

 

Should you be willing to assist us in the transaction Your share of the sum will be 25% of the $28.5million, 70% for us and 5% for taxation and miscellaneous expenses.

To enable us commence, I will need your personal telephone/fax number.

 

I await your immediate response.

Best Regards,

 

Engr. Moore Pete

------=_Part_4072_17692769.1228375235127-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 04 Dec 2008 01:36:18 +0000 Message-ID: <49373388.2020505@cn.kddilabs.jp> Date: Thu, 04 Dec 2008 10:34:00 +0900 From: "Ogaki, Kenichi" User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: ccamp@ops.ietf.org Subject: Re: CCAMP drafts for adoption Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, Yes to All. Kenichi Adrian Farrel wrote: > Hi, > > Can you please express your opinion on the adoption of the following > three drafts as WG drafts. > > Thanks, > Adrian > > draft-takacs-ccamp-oam-configuration-fwk-01.txt > draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt > draft-bernstein-ccamp-wson-encode-01.txt (to become -rwa-encode-00) > > Cheers, > Adrian and Deborah > > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 03 Dec 2008 19:21:01 +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:cc:in-reply-to:mime-version:content-type:references; bh=c5E9PRHVwfw7RgE98aA9FiJ4fy7shAL6vVKrL5Sbi9g=; b=FZhOlJJmqqMRASJw3A4wUCTaFP/qMp2sxo1r7sE9nNypTlVgQZyXvIW7Fo/+GvM3l6 WmgEF3oQc5uij+JSQc5/lAOQXieWihkCCfgJlDE0+tasZ84A+AIXhrsOpB2Pj+1wi6Z5 1keGC6D3VyYK90dfhY/AvHT0kbnDOCSM/oN6M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=sEsKRJBIwPPAA7IJ8L/FRo/9/oXxzQQHnwTKAn1DyX4x4knNtJMMZqxAs4YGYEiVWQ 2Hrw1XLmqAz99ENbtAf22fJGtU+2X4O2STUETz53PP9Tw+p1Zp1Z1pOz09qF1mwLRb0W JVLW1eV7cZiJk4FOYvPhM1hKEAmWsCU9dRPlY= Message-ID: <787be2780812031119v659923acy1cfb8152455aef54@mail.gmail.com> Date: Wed, 3 Dec 2008 14:19:35 -0500 From: "Greg Mirsky" To: "Adrian Farrel" Subject: Re: CCAMP drafts for adoption Cc: ccamp@ops.ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_13614_6381331.1228331975178" ------=_Part_13614_6381331.1228331975178 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Support oam-configuration and eth-oam Abstain wson-encode Regards, Greg On Tue, Dec 2, 2008 at 11:01 AM, Adrian Farrel wrote: > Hi, > > Can you please express your opinion on the adoption of the following three > drafts as WG drafts. > > Thanks, > Adrian > > draft-takacs-ccamp-oam-configuration-fwk-01.txt > draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt > draft-bernstein-ccamp-wson-encode-01.txt (to become -rwa-encode-00) > > Cheers, > Adrian and Deborah > > > ------=_Part_13614_6381331.1228331975178 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Support oam-configuration and eth-oam
Abstain wson-encode

Regards,
Greg

On Tue, Dec 2, 2008 at 11:01 AM, Adrian Farrel <adrian@olddog.co.uk> wrote:
Hi,

Can you please express your opinion on the adoption of the following three drafts as WG drafts.

Thanks,
Adrian

draft-takacs-ccamp-oam-configuration-fwk-01.txt
draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt
draft-bernstein-ccamp-wson-encode-01.txt (to become -rwa-encode-00)

Cheers,
Adrian and Deborah



------=_Part_13614_6381331.1228331975178-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 03 Dec 2008 15:42:50 +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: CCAMP drafts for adoption Date: Wed, 3 Dec 2008 07:41:43 -0800 Message-ID: <51661468CBD1354294533DA79E85955A0148BB0C@XCH-SW-5V2.sw.nos.boeing.com> Thread-Topic: CCAMP drafts for adoption Thread-Index: AclUl6mpWAW2o7P/QfKhDBZKhoe9CgABkY3AAAiyQSAAAP4GoAAAuZwwAABaoIAAACzaAAAAe+hQACNwvLAAAP1CgA== From: "Drake, John E" To: "Attila Takacs" , "Nitin Bahadur" , Attila, Very well put. I think I-Ds in question should become working group drafts. Thanks, John=20 >-----Original Message----- >From: Attila Takacs [mailto:Attila.Takacs@ericsson.com]=20 >Sent: Wednesday, December 03, 2008 7:28 AM >To: Nitin Bahadur; ccamp@ops.ietf.org >Subject: RE: CCAMP drafts for adoption > >Hi Nitin,=20 > >>=20 >> If you add a new-TLV to the PATH msg, then you need to send it on=20 >> every PATH msg... >> You really need to signal the parameters once during LSP-setup time=20 >> (and perhaps when the parameters are changed). >>=20 > >There are some options here.=20 > >First it has clear benefits to have the OAM config bound to=20 >the Path message and so to the actual LSP establishment as=20 >this ensures that the connection and its OAM is coupled. This=20 >is something you cannot ensure with LSP Ping. > >Alternatively, if one just wants to configure MEPs one may=20 >carry the proposed TLVs as part of Call establishment, this=20 >way only the endpoints will take part in signaling. > >On the other hand, if one needs to configure MIPs, the=20 >signaling needs to pass intermediate nodes hence the need to=20 >use the Path message is obvious. > >> LSP-Ping has a whole bunch of stuff defined. Most of it is not=20 >> needed/applicable in various scenarios. But the advantage is=20 >that it's=20 >> all there. As you go ahead with defining a new mechanism, you will=20 >> gradually see other requirements/needs and you might end up=20 >> re-inventing lsp-ping in another form. >>=20 > >How would you configure MIPs with LSP Ping? I assume you would=20 >need to use at least as many transactions (and as such have as=20 >many failure >scenarios) as many intermediate nodes the LSP has. (Not to=20 >mention that you need to get the list of intermediate nodes=20 >and the info on the success/failure of LSP establishment from=20 >another protocol.) > >Compare this to a single Path message in the case of RSVP-TE. > >Best regards, >Attila > > > > >> > Best regards, >> > Attila >> >=20 >> >=20 >> >=20 >> >=20 >> > > -----Original Message----- >> > > From: Nitin Bahadur [mailto:nitinb@juniper.net] >> > > Sent: Tuesday, December 02, 2008 11:01 PM >> > > To: Attila Takacs; Adrian Farrel; ccamp@ops.ietf.org >> > > Subject: RE: CCAMP drafts for adoption >> > >=20 >> > >=20 >> > > Hi Attlia, >> > >=20 >> > > What is the limitation of lsp-ping that prevents it=20 >from being=20 >> > > applied to GMPLS? >> > > If an existing mechanism can be applied, then why not? If >> lsp-ping >> > > needs extensions to support GMPLS LSPs, feel free to=20 >make/specify=20 >> > > those extensions. >> > >=20 >> > > Thanks >> > > Nitin >> > >=20 >> > > > -----Original Message----- >> > > > From: Attila Takacs [mailto:Attila.Takacs@ericsson.com] >> > > > Sent: Tuesday, December 02, 2008 1:52 PM >> > > > To: Nitin Bahadur; Adrian Farrel; ccamp@ops.ietf.org >> > > > Subject: RE: CCAMP drafts for adoption >> > > >=20 >> > > > Hi Nitin, >> > > >=20 >> > > > Please note that these mechanisms are proposed for GMPLS >> > > and as such >> > > > to provide support for any data plane technology specific OAM=20 >> > > > mechanism. As you noted LSP Ping is for MPLS and BFD only. >> > > >=20 >> > > > Best regards, >> > > > Attila >> > > >=20 >> > > > > -----Original Message----- >> > > > > From: owner-ccamp@ops.ietf.org=20 >> > > > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Nitin Bahadur >> > > > > Sent: Tuesday, December 02, 2008 10:35 PM >> > > > > To: Adrian Farrel; ccamp@ops.ietf.org >> > > > > Subject: RE: CCAMP drafts for adoption >> > > > >=20 >> > > > >=20 >> > > > >=20 >> > > > > > > draft-takacs-ccamp-oam-configuration-fwk-01.txt >> > > > > > > draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt >> > > > >=20 >> > > > > Do not support either of these. >> > > > >=20 >> > > > > From the oam-config-fwk draft: >> > > > > > A new useful application of RSVP-TE is OAM configuration >> > > > > and control >> > > > > > for transport networks. >> > > > >=20 >> > > > > LSP-ping was designed as an OAM mechansim for MPLS LSPs.=20 >> > > Why do we >> > > > > need another mechanism? What are the limitations of >> > lsp-ping that >> > > > > warrant this new mechanism? >> > > > >=20 >> > > > > > When RSVP-TE is used for LSP establishment it is desirable >> > > > > to bind OAM >> > > > > > setup to connection establishment signalling to avoid two >> > > > separate >> > > > > > management/configuration steps >> > > > >=20 >> > > > > draft-ietf-bfd-mpls specifies how to use LSP-Ping for >> > > > automatic setup >> > > > > of BFD-based OAM. >> > > > > We should go along the same path for Ethernet OAM. >> > > > >=20 >> > > > > Thanks >> > > > > Nitin >> > > > >=20 >> > > > >=20 >> > > >=20 >> > >=20 >> >=20 >>=20 > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 03 Dec 2008 15:42:42 +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: CCAMP drafts for adoption Date: Wed, 3 Dec 2008 07:41:43 -0800 Message-ID: <51661468CBD1354294533DA79E85955A0148BB0D@XCH-SW-5V2.sw.nos.boeing.com> Thread-Topic: CCAMP drafts for adoption Thread-Index: AclUl6mpWAW2o7P/QfKhDBZKhoe9CgABkY3AAAiyQSAAAP4GoAAAuZwwAABaoIAAACzaAAAAe+hQACNwvLAAAP1CgA== From: "Drake, John E" To: "Attila Takacs" , "Nitin Bahadur" , Attila, Very well put. I think I-Ds in question should become working group drafts. Thanks, John=20 >-----Original Message----- >From: Attila Takacs [mailto:Attila.Takacs@ericsson.com]=20 >Sent: Wednesday, December 03, 2008 7:28 AM >To: Nitin Bahadur; ccamp@ops.ietf.org >Subject: RE: CCAMP drafts for adoption > >Hi Nitin,=20 > >>=20 >> If you add a new-TLV to the PATH msg, then you need to send it on=20 >> every PATH msg... >> You really need to signal the parameters once during LSP-setup time=20 >> (and perhaps when the parameters are changed). >>=20 > >There are some options here.=20 > >First it has clear benefits to have the OAM config bound to=20 >the Path message and so to the actual LSP establishment as=20 >this ensures that the connection and its OAM is coupled. This=20 >is something you cannot ensure with LSP Ping. > >Alternatively, if one just wants to configure MEPs one may=20 >carry the proposed TLVs as part of Call establishment, this=20 >way only the endpoints will take part in signaling. > >On the other hand, if one needs to configure MIPs, the=20 >signaling needs to pass intermediate nodes hence the need to=20 >use the Path message is obvious. > >> LSP-Ping has a whole bunch of stuff defined. Most of it is not=20 >> needed/applicable in various scenarios. But the advantage is=20 >that it's=20 >> all there. As you go ahead with defining a new mechanism, you will=20 >> gradually see other requirements/needs and you might end up=20 >> re-inventing lsp-ping in another form. >>=20 > >How would you configure MIPs with LSP Ping? I assume you would=20 >need to use at least as many transactions (and as such have as=20 >many failure >scenarios) as many intermediate nodes the LSP has. (Not to=20 >mention that you need to get the list of intermediate nodes=20 >and the info on the success/failure of LSP establishment from=20 >another protocol.) > >Compare this to a single Path message in the case of RSVP-TE. > >Best regards, >Attila > > > > >> > Best regards, >> > Attila >> >=20 >> >=20 >> >=20 >> >=20 >> > > -----Original Message----- >> > > From: Nitin Bahadur [mailto:nitinb@juniper.net] >> > > Sent: Tuesday, December 02, 2008 11:01 PM >> > > To: Attila Takacs; Adrian Farrel; ccamp@ops.ietf.org >> > > Subject: RE: CCAMP drafts for adoption >> > >=20 >> > >=20 >> > > Hi Attlia, >> > >=20 >> > > What is the limitation of lsp-ping that prevents it=20 >from being=20 >> > > applied to GMPLS? >> > > If an existing mechanism can be applied, then why not? If >> lsp-ping >> > > needs extensions to support GMPLS LSPs, feel free to=20 >make/specify=20 >> > > those extensions. >> > >=20 >> > > Thanks >> > > Nitin >> > >=20 >> > > > -----Original Message----- >> > > > From: Attila Takacs [mailto:Attila.Takacs@ericsson.com] >> > > > Sent: Tuesday, December 02, 2008 1:52 PM >> > > > To: Nitin Bahadur; Adrian Farrel; ccamp@ops.ietf.org >> > > > Subject: RE: CCAMP drafts for adoption >> > > >=20 >> > > > Hi Nitin, >> > > >=20 >> > > > Please note that these mechanisms are proposed for GMPLS >> > > and as such >> > > > to provide support for any data plane technology specific OAM=20 >> > > > mechanism. As you noted LSP Ping is for MPLS and BFD only. >> > > >=20 >> > > > Best regards, >> > > > Attila >> > > >=20 >> > > > > -----Original Message----- >> > > > > From: owner-ccamp@ops.ietf.org=20 >> > > > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Nitin Bahadur >> > > > > Sent: Tuesday, December 02, 2008 10:35 PM >> > > > > To: Adrian Farrel; ccamp@ops.ietf.org >> > > > > Subject: RE: CCAMP drafts for adoption >> > > > >=20 >> > > > >=20 >> > > > >=20 >> > > > > > > draft-takacs-ccamp-oam-configuration-fwk-01.txt >> > > > > > > draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt >> > > > >=20 >> > > > > Do not support either of these. >> > > > >=20 >> > > > > From the oam-config-fwk draft: >> > > > > > A new useful application of RSVP-TE is OAM configuration >> > > > > and control >> > > > > > for transport networks. >> > > > >=20 >> > > > > LSP-ping was designed as an OAM mechansim for MPLS LSPs.=20 >> > > Why do we >> > > > > need another mechanism? What are the limitations of >> > lsp-ping that >> > > > > warrant this new mechanism? >> > > > >=20 >> > > > > > When RSVP-TE is used for LSP establishment it is desirable >> > > > > to bind OAM >> > > > > > setup to connection establishment signalling to avoid two >> > > > separate >> > > > > > management/configuration steps >> > > > >=20 >> > > > > draft-ietf-bfd-mpls specifies how to use LSP-Ping for >> > > > automatic setup >> > > > > of BFD-based OAM. >> > > > > We should go along the same path for Ethernet OAM. >> > > > >=20 >> > > > > Thanks >> > > > > Nitin >> > > > >=20 >> > > > >=20 >> > > >=20 >> > >=20 >> >=20 >>=20 > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 03 Dec 2008 15:42:30 +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: CCAMP drafts for adoption Date: Wed, 3 Dec 2008 07:41:43 -0800 Message-ID: <51661468CBD1354294533DA79E85955A0148BB0B@XCH-SW-5V2.sw.nos.boeing.com> Thread-Topic: CCAMP drafts for adoption Thread-Index: AclUl6mpWAW2o7P/QfKhDBZKhoe9CgABkY3AAAiyQSAAAP4GoAAAuZwwAABaoIAAACzaAAAAe+hQACNwvLAAAP1CgA== From: "Drake, John E" To: "Attila Takacs" , "Nitin Bahadur" , Attila, Very well put. I think I-Ds in question should become working group drafts. Thanks, John=20 >-----Original Message----- >From: Attila Takacs [mailto:Attila.Takacs@ericsson.com]=20 >Sent: Wednesday, December 03, 2008 7:28 AM >To: Nitin Bahadur; ccamp@ops.ietf.org >Subject: RE: CCAMP drafts for adoption > >Hi Nitin,=20 > >>=20 >> If you add a new-TLV to the PATH msg, then you need to send it on=20 >> every PATH msg... >> You really need to signal the parameters once during LSP-setup time=20 >> (and perhaps when the parameters are changed). >>=20 > >There are some options here.=20 > >First it has clear benefits to have the OAM config bound to=20 >the Path message and so to the actual LSP establishment as=20 >this ensures that the connection and its OAM is coupled. This=20 >is something you cannot ensure with LSP Ping. > >Alternatively, if one just wants to configure MEPs one may=20 >carry the proposed TLVs as part of Call establishment, this=20 >way only the endpoints will take part in signaling. > >On the other hand, if one needs to configure MIPs, the=20 >signaling needs to pass intermediate nodes hence the need to=20 >use the Path message is obvious. > >> LSP-Ping has a whole bunch of stuff defined. Most of it is not=20 >> needed/applicable in various scenarios. But the advantage is=20 >that it's=20 >> all there. As you go ahead with defining a new mechanism, you will=20 >> gradually see other requirements/needs and you might end up=20 >> re-inventing lsp-ping in another form. >>=20 > >How would you configure MIPs with LSP Ping? I assume you would=20 >need to use at least as many transactions (and as such have as=20 >many failure >scenarios) as many intermediate nodes the LSP has. (Not to=20 >mention that you need to get the list of intermediate nodes=20 >and the info on the success/failure of LSP establishment from=20 >another protocol.) > >Compare this to a single Path message in the case of RSVP-TE. > >Best regards, >Attila > > > > >> > Best regards, >> > Attila >> >=20 >> >=20 >> >=20 >> >=20 >> > > -----Original Message----- >> > > From: Nitin Bahadur [mailto:nitinb@juniper.net] >> > > Sent: Tuesday, December 02, 2008 11:01 PM >> > > To: Attila Takacs; Adrian Farrel; ccamp@ops.ietf.org >> > > Subject: RE: CCAMP drafts for adoption >> > >=20 >> > >=20 >> > > Hi Attlia, >> > >=20 >> > > What is the limitation of lsp-ping that prevents it=20 >from being=20 >> > > applied to GMPLS? >> > > If an existing mechanism can be applied, then why not? If >> lsp-ping >> > > needs extensions to support GMPLS LSPs, feel free to=20 >make/specify=20 >> > > those extensions. >> > >=20 >> > > Thanks >> > > Nitin >> > >=20 >> > > > -----Original Message----- >> > > > From: Attila Takacs [mailto:Attila.Takacs@ericsson.com] >> > > > Sent: Tuesday, December 02, 2008 1:52 PM >> > > > To: Nitin Bahadur; Adrian Farrel; ccamp@ops.ietf.org >> > > > Subject: RE: CCAMP drafts for adoption >> > > >=20 >> > > > Hi Nitin, >> > > >=20 >> > > > Please note that these mechanisms are proposed for GMPLS >> > > and as such >> > > > to provide support for any data plane technology specific OAM=20 >> > > > mechanism. As you noted LSP Ping is for MPLS and BFD only. >> > > >=20 >> > > > Best regards, >> > > > Attila >> > > >=20 >> > > > > -----Original Message----- >> > > > > From: owner-ccamp@ops.ietf.org=20 >> > > > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Nitin Bahadur >> > > > > Sent: Tuesday, December 02, 2008 10:35 PM >> > > > > To: Adrian Farrel; ccamp@ops.ietf.org >> > > > > Subject: RE: CCAMP drafts for adoption >> > > > >=20 >> > > > >=20 >> > > > >=20 >> > > > > > > draft-takacs-ccamp-oam-configuration-fwk-01.txt >> > > > > > > draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt >> > > > >=20 >> > > > > Do not support either of these. >> > > > >=20 >> > > > > From the oam-config-fwk draft: >> > > > > > A new useful application of RSVP-TE is OAM configuration >> > > > > and control >> > > > > > for transport networks. >> > > > >=20 >> > > > > LSP-ping was designed as an OAM mechansim for MPLS LSPs.=20 >> > > Why do we >> > > > > need another mechanism? What are the limitations of >> > lsp-ping that >> > > > > warrant this new mechanism? >> > > > >=20 >> > > > > > When RSVP-TE is used for LSP establishment it is desirable >> > > > > to bind OAM >> > > > > > setup to connection establishment signalling to avoid two >> > > > separate >> > > > > > management/configuration steps >> > > > >=20 >> > > > > draft-ietf-bfd-mpls specifies how to use LSP-Ping for >> > > > automatic setup >> > > > > of BFD-based OAM. >> > > > > We should go along the same path for Ethernet OAM. >> > > > >=20 >> > > > > Thanks >> > > > > Nitin >> > > > >=20 >> > > > >=20 >> > > >=20 >> > >=20 >> >=20 >>=20 > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 03 Dec 2008 15:40:26 +0000 Date: Wed, 03 Dec 2008 09:39:34 -0600 From: Rebecca Han Subject: Re: CCAMP drafts for adoption To: Adrian Farrel Cc: ccamp@ops.ietf.org Message-id: <006c01c9555d$57e38da0$3b0c7c0a@china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Support all to become WG documents. Rebecca Han ----- Original Message ----- From: "Adrian Farrel" To: Sent: Tuesday, December 02, 2008 10:01 AM Subject: CCAMP drafts for adoption > Hi, > > Can you please express your opinion on the adoption of the following three > drafts as WG drafts. > > Thanks, > Adrian > > draft-takacs-ccamp-oam-configuration-fwk-01.txt > draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt > draft-bernstein-ccamp-wson-encode-01.txt (to become -rwa-encode-00) > > Cheers, > Adrian and Deborah > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 03 Dec 2008 15:30:53 +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: CCAMP drafts for adoption Date: Wed, 3 Dec 2008 16:28:00 +0100 Message-ID: <53CCFDD6E346CB43994852666C210E9105B98CDB@esealmw116.eemea.ericsson.se> Thread-Topic: CCAMP drafts for adoption thread-index: AclUl6mpWAW2o7P/QfKhDBZKhoe9CgABkY3AAAiyQSAAAP4GoAAAuZwwAABaoIAAACzaAAAAe+hQACNwvLA= From: "Attila Takacs" To: "Nitin Bahadur" , Hi Nitin,=20 >=20 > If you add a new-TLV to the PATH msg, then you need to send=20 > it on every PATH msg... > You really need to signal the parameters once during=20 > LSP-setup time (and perhaps when the parameters are changed). >=20 There are some options here.=20 First it has clear benefits to have the OAM config bound to the Path message and so to the actual LSP establishment as this ensures that the connection and its OAM is coupled. This is something you cannot ensure with LSP Ping. Alternatively, if one just wants to configure MEPs one may carry the proposed TLVs as part of Call establishment, this way only the endpoints will take part in signaling. On the other hand, if one needs to configure MIPs, the signaling needs to pass intermediate nodes hence the need to use the Path message is obvious. > LSP-Ping has a whole bunch of stuff defined. Most of it is=20 > not needed/applicable in various scenarios. But the advantage=20 > is that it's all there. As you go ahead with defining a new=20 > mechanism, you will gradually see other requirements/needs=20 > and you might end up re-inventing lsp-ping in another form. >=20 How would you configure MIPs with LSP Ping? I assume you would need to use at least as many transactions (and as such have as many failure scenarios) as many intermediate nodes the LSP has. (Not to mention that you need to get the list of intermediate nodes and the info on the success/failure of LSP establishment from another protocol.) Compare this to a single Path message in the case of RSVP-TE. Best regards, Attila > > Best regards, > > Attila > >=20 > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: Nitin Bahadur [mailto:nitinb@juniper.net] > > > Sent: Tuesday, December 02, 2008 11:01 PM > > > To: Attila Takacs; Adrian Farrel; ccamp@ops.ietf.org > > > Subject: RE: CCAMP drafts for adoption > > >=20 > > >=20 > > > Hi Attlia, > > >=20 > > > What is the limitation of lsp-ping that prevents it from being=20 > > > applied to GMPLS? > > > If an existing mechanism can be applied, then why not? If=20 > lsp-ping=20 > > > needs extensions to support GMPLS LSPs, feel free to make/specify=20 > > > those extensions. > > >=20 > > > Thanks > > > Nitin > > >=20 > > > > -----Original Message----- > > > > From: Attila Takacs [mailto:Attila.Takacs@ericsson.com] > > > > Sent: Tuesday, December 02, 2008 1:52 PM > > > > To: Nitin Bahadur; Adrian Farrel; ccamp@ops.ietf.org > > > > Subject: RE: CCAMP drafts for adoption > > > >=20 > > > > Hi Nitin, > > > >=20 > > > > Please note that these mechanisms are proposed for GMPLS > > > and as such > > > > to provide support for any data plane technology specific OAM=20 > > > > mechanism. As you noted LSP Ping is for MPLS and BFD only. > > > >=20 > > > > Best regards, > > > > Attila > > > >=20 > > > > > -----Original Message----- > > > > > From: owner-ccamp@ops.ietf.org > > > > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Nitin Bahadur > > > > > Sent: Tuesday, December 02, 2008 10:35 PM > > > > > To: Adrian Farrel; ccamp@ops.ietf.org > > > > > Subject: RE: CCAMP drafts for adoption > > > > >=20 > > > > >=20 > > > > >=20 > > > > > > > draft-takacs-ccamp-oam-configuration-fwk-01.txt > > > > > > > draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt > > > > >=20 > > > > > Do not support either of these. > > > > >=20 > > > > > From the oam-config-fwk draft: > > > > > > A new useful application of RSVP-TE is OAM configuration > > > > > and control > > > > > > for transport networks. > > > > >=20 > > > > > LSP-ping was designed as an OAM mechansim for MPLS LSPs.=20 > > > Why do we > > > > > need another mechanism? What are the limitations of > > lsp-ping that > > > > > warrant this new mechanism? > > > > >=20 > > > > > > When RSVP-TE is used for LSP establishment it is desirable > > > > > to bind OAM > > > > > > setup to connection establishment signalling to avoid two > > > > separate > > > > > > management/configuration steps > > > > >=20 > > > > > draft-ietf-bfd-mpls specifies how to use LSP-Ping for > > > > automatic setup > > > > > of BFD-based OAM. > > > > > We should go along the same path for Ethernet OAM. > > > > >=20 > > > > > Thanks > > > > > Nitin > > > > >=20 > > > > >=20 > > > >=20 > > >=20 > >=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 03 Dec 2008 14:42:38 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=zQmwV/FoUC/wDC5aB1y8fM5oGCf8wC7nXosJbDOeaXue1LJAj+21sVJHN8JHEXRkLmVnzT2iIPcfuJElnr+mhJR5O+o0qg58E07aqm23MCLdkDcbfUK9Z76GGmI97gma7rR/Cr4qEDDVRzLjIpEwniiDw9Rm/307+oi/cjmpzVw=; Date: Wed, 3 Dec 2008 06:42:15 -0800 (PST) From: Igor Bryskin Subject: Re: CCAMP drafts for adoption To: David Allan , Nitin Bahadur , ccamp@ops.ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-680914809-1228315335=:39765" Message-ID: <138584.39765.qm@web36804.mail.mud.yahoo.com> --0-680914809-1228315335=:39765 Content-Type: text/plain; charset=us-ascii Dave, I completely agree with you. For me, as a GMPLS vendor, it would be very easy to add a couple of objects to GMPLS RSVP ( by the way, I also agree that GMPLS RSVP is very, very different from IP/MPLS RSVP-TE) so that I could automate OAM configuration. To add LSP Ping to my GMPLS offering is a completely diffirent scale of effort, and I believe, there should be reasons for this much more serious than the fact this could be also done using some existing IP/MPLS technology which so far was never part of my solution. On more general note, I think, it would be a good idea to agree within the CCAMP WG what is it, actually, GMPLS? Specifically, which components of IP/MPLS control plane belong to GMPLS, which do not, and which parts of GMPLS are specific to transport networks and have nothing to do with IP/MPLS. For instance, does LSP Ping belong to GMPLS? How about BGP? LDP? If the answer is yes, than which production GMPLS deployments feature them? I think after 8 years of working on GMPLS we can answer these questions. If the answer is no, that let's solve transport network control plane problems within existing GMPLS framework. Igor ________________________________ From: David Allan To: Nitin Bahadur ; ccamp@ops.ietf.org Sent: Tuesday, December 2, 2008 7:40:55 PM Subject: RE: CCAMP drafts for adoption Hi Nitin: My reaction is that spreading state over a number of protocols may keep one superficially simple but drives up the total cost of the solution...from the POV of lines of code, amount to test, amount of state, additional race conditions, delayed setup time etc. so is a specious optimization.... If the path is not up until OAM says so, it is useful to get there in as few transactions as possible... My 2 cents. Dave -----Original Message----- From: Nitin Bahadur [mailto:nitinb@juniper.net] Sent: Tuesday, December 02, 2008 6:38 PM To: Allan, David (CAR:NS00); ccamp@ops.ietf.org Subject: RE: CCAMP drafts for adoption Hi David, > > David, all that I am asking is that one can use the basic-bare-bones > definitions in lsp-ping to setup the Ethernet OAM > > params. I am not talking about applicability nor I am > saying that one > needs to use ping and trace based off lsp-ping for > PBB-TE LSPs. > > But this still requires implementing a new protocol where it does not > already exist, I agree. It does require implementing lsp-ping. But the way these 2 drafts are going, they will end up defining a new mini-oam-boot-strapping protocol on top of RSVP path messages. And once we have a precedence, it will just keep growing. I am basically against using RSVP path message as an OAM related PDU transfer agent. The drafts already specify 3-4 sub-TLVs and a bunch of error codes. This list can grow. The framework draft is generic in nature. So tomorrrow I can use BFD or XXX on top of RSVP (why just ethernet-oam) and I can add 10 more TLVs and 5 more error codes. It's all about keeping RSVP clean. Your requirement is to automate OAM on a GMPLS LSP. Why dirty this poor Path msg. If you do not wish to use Lsp-ping (for whatever reason)...I recommend using something other than a RSVP path msg. > which also requires a *new* bare > bones definition... I think that would be easy. You just need to send the lsp-ping msg along the control-plane. The LSP details can be put in the existing defined TLVs. The ethernet OAM details can be directly copied from these new drafts into a lsp-ping based draft. > > > > I am not asking you to use lsp-ping for LB/LT. I agree that ethernet > OAM already has that and indeed once should use > > that. I am just saying that the setup can be done using lsp-ping. > > I think the point was GMPLS applies to a lot of technologies that > cannot do LSP-PING in the first place, which means such a signalling > extension will be required nonetheless... As I said earlier, use LSP-Ping not for OAM, but for signaling the OAM params. Given that you are using RSVP for signaling the GMPLS LSP via the control plane, you can use LSP-Ping (via control plane) to do the OAM signaling. > can I suggest you > withdraw your objections to the Eth-Oam draft and move the TP parts of > this discussion over to the MPLS list? My main objections to the Eth-oam drafts are not TP related. They are related to using RSVP Path as a transmission mechanism for OAM setup. OAM is complex and tomorrow we might need more TLVs to indicate remote failure or some other condition via the control plane. Dave, you are the co-author of draft-ietf-pwe3-oam-msg-map. Look at the amount of stuff that has gone in there. As a side-note, I am just *a person*. It's the ccamp wg mailing list that needs to say *yes*/*no*. It's all rough consensus right? Thanks Nitin --0-680914809-1228315335=:39765 Content-Type: text/html; charset=us-ascii
Dave,

I completely agree with you. For me, as a GMPLS vendor, it would be very easy to add a couple of objects to GMPLS RSVP ( by the way, I also agree that GMPLS RSVP is very, very different from IP/MPLS RSVP-TE) so that I could automate OAM configuration. To add LSP Ping to my GMPLS offering is a completely diffirent scale of effort, and  I believe, there should be reasons for this much more serious than the fact this could be also done using some existing IP/MPLS technology which so far was never part of my solution.

On more general note, I think, it would be a good idea to agree within the CCAMP WG what is it, actually, GMPLS? Specifically, which components of IP/MPLS control plane belong to GMPLS, which do not, and which parts of GMPLS are specific to transport networks and have nothing to do with IP/MPLS. For instance, does LSP Ping belong to GMPLS? How about BGP? LDP? If the answer is yes, than which production GMPLS deployments feature them? I think after 8 years of working on GMPLS we can answer these questions. If the answer is no, that let's solve transport network control plane problems within existing GMPLS framework.

Igor

From: David Allan <dallan@nortel.com>
To: Nitin Bahadur <nitinb@juniper.net>; ccamp@ops.ietf.org
Sent: Tuesday, December 2, 2008 7:40:55 PM
Subject: RE: CCAMP drafts for adoption

Hi Nitin:

My reaction is that spreading state over a number of protocols may keep
one superficially simple but drives up the total cost of the
solution...from the POV of lines of code, amount to test, amount of
state, additional race conditions, delayed setup time etc. so is a
specious optimization....

If the path is not up until OAM says so, it is useful to get there in as
few transactions as possible...

My 2 cents.
Dave





-----Original Message-----
From: Nitin Bahadur [mailto:nitinb@juniper.net]
Sent: Tuesday, December 02, 2008 6:38 PM
To: Allan, David (CAR:NS00); ccamp@ops.ietf.org
Subject: RE: CCAMP drafts for adoption


Hi David,

> > David, all that I am asking is that one can use the basic-bare-bones
> definitions in lsp-ping to setup the Ethernet OAM
> > params. I am not talking about applicability nor I am
> saying that one
> needs to use ping and trace based off lsp-ping for > PBB-TE LSPs.
>
> But this still requires implementing a new protocol where it does not
> already exist,

I agree. It does require implementing lsp-ping. But the way these 2
drafts are going, they will end up defining a new
mini-oam-boot-strapping protocol on top of RSVP path messages. And once
we have a precedence, it will just keep growing. I am basically against
using RSVP path message as an OAM related PDU transfer agent. The drafts
already specify 3-4 sub-TLVs and a bunch of error codes. This list can
grow. The framework draft is generic in nature. So tomorrrow I can use
BFD or XXX on top of RSVP (why just ethernet-oam) and I can add 10 more
TLVs and 5 more error codes.

It's all about keeping RSVP clean. Your requirement is to automate OAM
on a GMPLS LSP. Why dirty this poor Path msg.

If you do not wish to use Lsp-ping (for whatever reason)...I recommend
using something other than a RSVP path msg.

> which also requires a *new* bare
> bones definition...

I think that would be easy. You just need to send the lsp-ping msg along
the control-plane. The LSP details can be put in the existing defined
TLVs. The ethernet OAM details can be directly copied from these new
drafts into a lsp-ping based draft.

> <snipped>
>
> > I am not asking you to use lsp-ping for LB/LT. I agree that ethernet
> OAM already has that and indeed once should use
> > that. I am just saying that the setup can be done using lsp-ping.
>
> I think the point was GMPLS applies to a lot of technologies that
> cannot do LSP-PING in the first place, which means such a signalling
> extension will be required nonetheless...

As I said earlier, use LSP-Ping not for OAM, but for signaling the OAM
params.
Given that you are using RSVP for signaling the GMPLS LSP via the
control plane, you can use LSP-Ping (via control plane) to do the OAM
signaling.

> can I suggest you
> withdraw your objections to the Eth-Oam draft and move the TP parts of

> this discussion over to the MPLS list?

My main objections to the Eth-oam drafts are not TP related.
They are related to using RSVP Path as a transmission mechanism for OAM
setup. OAM is complex and tomorrow we might need more TLVs to indicate
remote failure or some other condition via the control plane.
Dave, you are the co-author of draft-ietf-pwe3-oam-msg-map. Look at the
amount of stuff that has gone in there.

As a side-note, I am just *a person*. It's the ccamp wg mailing list
that needs to say *yes*/*no*. It's all rough consensus right?

Thanks
Nitin


--0-680914809-1228315335=:39765-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 03 Dec 2008 14:38:37 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:X-Mailer:Date:To:From:Subject:Cc:In-Reply-To:References:Mime-Version:Content-Type:X-Identified-User; b=vL9vPntLVVJIVQLaqXwhhCnA9SBqY5E8mYvPhDz+zMaRSq+DRuNB3dfletHc6DAxnPnsCazO7K+RHkn1YULWxTyxoZq90XVTJx++Q9YhTvA00XnxOoQKu7aKvk6RMkg+; Date: Wed, 03 Dec 2008 09:36:59 -0500 To: "Thomas D. Nadeau" From: Lou Berger Subject: Re: CCAMP drafts for adoption Cc: David Allan ,Nitin Bahadur , Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-Id: Tom, You might want to look at what's happening with OAM for TP, it != LSP Ping. As TP is currently drafted, Attila's documents will make more sense than LSP ping. Lou At 06:41 PM 12/2/2008, Thomas D. Nadeau wrote: > Dave, > > As an operator with a very big deployment of MPLS and a lot of money >invested in OSS to manage said network, I do not want a different mechanism >to the one that has been deployed today to control OAM for any MPLS >networks, MPLS-TP included. > > --Tom > > > >On 12/2/08 6:01 PM, "David Allan" wrote: > > > HI Nitin: > > > > Thanks for replying.... > > > > > >> David, all that I am asking is that one can use the basic-bare-bones > > definitions in lsp-ping to setup the Ethernet OAM > >> params. I am not talking about applicability nor I am saying that one > > needs to use ping and trace based off lsp-ping for > PBB-TE LSPs. > > > > But this still requires implementing a new protocol where it does not > > already exist, which also requires a *new* bare bones definition... > > > >> We have a whole bunch of stuff defined in RSVP. Obviously some of them > > are not applicable for GMPLS LSPs. But that does > not mean that we go > > define G-RSVP (for GMPLS LSPs). > > > > Isn't that CCAMPs mandate? > > > > > > > >> I am not asking you to use lsp-ping for LB/LT. I agree that ethernet > > OAM already has that and indeed once should use > >> that. I am just saying that the setup can be done using lsp-ping. > > > > I think the point was GMPLS applies to a lot of technologies that cannot > > do LSP-PING in the first place, which means such a signalling extension > > will be required nonetheless... > > > > > >> LSP-Ping is already non-IP from a *forwarding* perspective. LSP-Ping > > has a reply-mode of *application channel* which can > be used for things > > like bi-directional LSPs. So for MPLS-TP LSPs, the lsp-ping replies > > would go on the LSP reverse path > (label-switched and not IP > > forwarded). > > > > OK, I can see that such an approach could be made to work and would be > > desirable to some. On that basis, can I suggest you withdraw your > > objections to the Eth-Oam draft and move the TP parts of this discussion > > over to the MPLS list? That would seem appropriate... > > > > Cheers > > Dave > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 03 Dec 2008 13:05:30 +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:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=MfgpROrgZ4C9PD3u2LiyXihlkemhchdD8O2RlU0t2YM=; b=WFEqRdDvQenapYdIztyqIy378u6sDhRYIz4nudpCyBFwW4RaAVznGEKJL1Ete0nvJb 1riPAf6ZnrUBGf3cVjeha84IJiuTjg74ovhhq8oRGpulkx1ZviFpaqF6OlC/37Wbs8ja xQvC6JA3rYfWaDecpVGUI57T/DinnlSYBctQw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=Jz8hEts3rjby8wX+514aqv2We/+kuimtXBuz4Qv8FM3TYFeRPt2sO18e+PZHTmjWS7 weQRsb344yvJg94F1Hef6P0wXs/RI8rc1H5dSlBv9rWppW8v30lqNcFelU47aT+1Bde9 FbK/FE+V37AiUBH/xIQzPwmXAJvHZHPHee00c= Message-ID: <7c923b5e0812030504x6b257d44p5c64329eee842dda@mail.gmail.com> Date: Wed, 3 Dec 2008 14:04:42 +0100 From: "Francesco Fondelli" To: "Nitin Bahadur" Subject: Re: CCAMP drafts for adoption Cc: "Adrian Farrel" , ccamp@ops.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Tue, Dec 2, 2008 at 10:35 PM, Nitin Bahadur wrote: > > >> > draft-takacs-ccamp-oam-configuration-fwk-01.txt >> > draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt > > Do not support either of these. Given this statement a) --- draft-ietf-mpls-tp-framework-00 --- The MPLS-TP control plane is based on a combination of the MPLS control plane for pseudowires and the GMPLS control plane for MPLS-TP LSPs, respectively. More specifically, LDP is used for PW signaling and *GMPLS based RSVP-TE for LSP signaling*. --- and this requirement b) --- draft-ietf-mpls-tp-requirements-00 -- The MPLS-TP control pane MUST support the configuration and modification of OAM maintenance points as well as the activation/deactivation of OAM *when the transport path is established or modified*. --- RSVP-TE is the tool that has to be used for OAM configuration in a MPLS-TP context, IMHO. Above I-Ds are mpls working group documents... so my opinion on the adoption of the following two drafts draft-takacs-ccamp-oam-configuration-fwk-01.txt draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt is yes and my opinion on the adoption of the following draft draft-bernstein-ccamp-wson-encode-01.txt is yes > Thanks > Nitin thanks Ciao FF Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 03 Dec 2008 12:36:51 +0000 Message-ID: <07626F0FC99D4A538A3D919BF3E88A37@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "ccamp" Subject: Reiterating Thanks to Note-takers Date: Wed, 3 Dec 2008 12:35:29 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Can I reiterate thanks to the note-takers. I often go back to the minutes to establish who said what, and what opinions were expressed. Accurate and detailed notes are a great asset. Thanks, Adrian ----- Original Message ----- From: "BRUNGARD, DEBORAH A, ATTLABS" To: "ccamp" Sent: Wednesday, December 03, 2008 10:51 AM Subject: CCAMP minutes Hi all, The ccamp minutes are available: http://www.ietf.org/proceedings/08nov/minutes/ccamp.htm Much thanks to our note takers: Lyndon Ong (both sessions!), Eric Gray (session I) and Don Fedyk (session II). Let us know if any comments- Deborah and Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 03 Dec 2008 10:54:02 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: CCAMP minutes Date: Wed, 3 Dec 2008 05:51:47 -0500 Message-ID: Thread-Topic: CCAMP minutes Thread-Index: AclVNSNY0XswXzhcSR+LtL8Jpd4QDw== From: "BRUNGARD, DEBORAH A, ATTLABS" To: "ccamp" Hi all, The ccamp minutes are available: http://www.ietf.org/proceedings/08nov/minutes/ccamp.htm Much thanks to our note takers: Lyndon Ong (both sessions!), Eric Gray (session I) and Don Fedyk (session II). Let us know if any comments- Deborah and Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 03 Dec 2008 10:09:55 +0000 Message-ID: <49365AB5.7090002@nict.go.jp> Date: Wed, 03 Dec 2008 19:08:53 +0900 From: Sugang XU User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Adrian Farrel Cc: ccamp@ops.ietf.org Subject: Re: CCAMP drafts for adoption Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Support all to become WG documents. Sugang Adrian Farrel ã•ã‚“ã¯æ›¸ãã¾ã—ãŸ: > Hi, > > Can you please express your opinion on the adoption of the following > three drafts as WG drafts. > > Thanks, > Adrian > > draft-takacs-ccamp-oam-configuration-fwk-01.txt > draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt > draft-bernstein-ccamp-wson-encode-01.txt (to become -rwa-encode-00) > > Cheers, > Adrian and Deborah > > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 03 Dec 2008 09:57:23 +0000 Date: Wed, 03 Dec 2008 17:55:10 +0800 From: Mach Chen Subject: Re: CCAMP drafts for adoption To: Adrian Farrel , ccamp@ops.ietf.org Message-id: MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT Yes to all three drafts. Best regards, Mach -------------------------------------------------- From: "Adrian Farrel" Sent: Wednesday, December 03, 2008 12:01 AM To: Subject: CCAMP drafts for adoption > Hi, > > Can you please express your opinion on the adoption of the following three > drafts as WG drafts. > > Thanks, > Adrian > > draft-takacs-ccamp-oam-configuration-fwk-01.txt > draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt > draft-bernstein-ccamp-wson-encode-01.txt (to become -rwa-encode-00) > > Cheers, > Adrian and Deborah > > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 03 Dec 2008 09:28:23 +0000 Date: Wed, 03 Dec 2008 17:27:40 +0800 From: lidan 37133 Subject: =?gb2312?B?u9i4tA==?=:CCAMP drafts for adoption To: Adrian Farrel Cc: ccamp@ops.ietf.org Message-id: MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: quoted-printable Content-disposition: inline Yes to all of three=2E Dan Li = Advanced Technology Department Wireline Networking Business Unit Huawei Technologies Co=2E=2C LTD=2E Huawei Base=2C Bantian=2C Longgang=2C Shenzhen 518129 P=2ER=2EChina Tel=3A +86-755-28973237 Fax=3A +86-755-28972935 ----- =D4=AD=D3=CA=BC=FE ----- =B7=A2=BC=FE=C8=CB=3A Adrian Farrel =3Cadrian=40olddog=2Eco=2Euk=3E =C8=D5=C6=DA=3A =D0=C7=C6=DA=C8=FD=2C =CA=AE=B6=FE=D4=C2 3=C8=D5=2C 2008 = =C9=CF=CE=E70=3A03 =D6=F7=CC=E2=3A CCAMP drafts for adoption =CA=D5=BC=FE=C8=CB=3A ccamp=40ops=2Eietf=2Eorg =3E Hi=2C =3E = =3E Can you please express your opinion on the adoption of the = =3E following three = =3E drafts as WG drafts=2E =3E = =3E Thanks=2C =3E Adrian =3E = =3E draft-takacs-ccamp-oam-configuration-fwk-01=2Etxt =3E draft-takacs-ccamp-rsvp-te-eth-oam-ext-03=2Etxt =3E draft-bernstein-ccamp-wson-encode-01=2Etxt (to become -rwa-encode-00)= =3E = =3E Cheers=2C =3E Adrian and Deborah = =3E = =3E = =3E = =3E Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 03 Dec 2008 09:01:29 +0000 Message-ID: Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Nitin Bahadur" , Subject: OAM control Date: Wed, 3 Dec 2008 09:00:42 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Hi Nitin, Have you tried running LSP Ping on a lambda? In practice, many data plane technologies have existing OAM techniques, and it is these that the draft proposes to control. Are you suggesting that the LSP Ping echo request should be sent out of band and used to manage data plane OAM? Thanks, Adrian ----- Original Message ----- From: "Nitin Bahadur" To: "Adrian Farrel" ; Sent: Tuesday, December 02, 2008 9:35 PM Subject: RE: CCAMP drafts for adoption > > draft-takacs-ccamp-oam-configuration-fwk-01.txt > > draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt Do not support either of these. >From the oam-config-fwk draft: > A new useful application of RSVP-TE is OAM configuration > and control for transport networks. LSP-ping was designed as an OAM mechansim for MPLS LSPs. Why do we need another mechanism? What are the limitations of lsp-ping that warrant this new mechanism? > When RSVP-TE is used for LSP establishment it is desirable to bind > OAM setup to connection establishment signalling to avoid two > separate management/configuration steps draft-ietf-bfd-mpls specifies how to use LSP-Ping for automatic setup of BFD-based OAM. We should go along the same path for Ethernet OAM. Thanks Nitin Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 03 Dec 2008 08:36:53 +0000 Date: Wed, 03 Dec 2008 09:34:52 +0100 From: longhao 48034 Subject: Re:CCAMP drafts for adoption To: Adrian Farrel Cc: ccamp@ops.ietf.org Message-id: MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: quoted-printable Content-disposition: inline Hi=2C I support all of the three drafts to become WG drafts=2E When I read the mailing discussion=2C some experts opposed the two I-Ds r= elated to oam configuration=3A draft-takacs-ccamp-oam-configuration-fwk-01=2Etxt draft-takacs-ccamp-rsvp-te-eth-oam-ext-03=2Etxt My understanding is these two I-Ds are very useful for oam deployment=2E = As you know=2C there are many things are needed to be preconfigured befor= e you activate the oam function=2E This is actually a tough thing for use= rs because the configuration involoves all the nodes on the lsp and so ma= ny parameters=2C e=2Eg=2E MEG level=2C MEP ID=2C MD name =2C MA name =2E=2E= =2E=2E=2E Some experts argues that this will lead to add more TLVs to RSV= P-TE=2E However=2C if looking at the LSP setup=2C it is also a way to simplify the configuration=2E LSP setup= and OAM configuration are similar thing=2E They are both the work of REV= P-TE signaling=2E As this=2C I support the two I-Ds=2E Thanks=2C Hao ----- =D4=AD=D3=CA=BC=FE ----- =B7=A2=BC=FE=C8=CB=3A Adrian Farrel =3Cadrian=40olddog=2Eco=2Euk=3E =C8=D5=C6=DA=3A =D0=C7=C6=DA=B6=FE=2C =CA=AE=B6=FE=D4=C2 2=C8=D5=2C 2008 = =CF=C2=CE=E75=3A03 =D6=F7=CC=E2=3A CCAMP drafts for adoption =CA=D5=BC=FE=C8=CB=3A ccamp=40ops=2Eietf=2Eorg =3E Hi=2C =3E = =3E Can you please express your opinion on the adoption of the = =3E following three = =3E drafts as WG drafts=2E =3E = =3E Thanks=2C =3E Adrian =3E = =3E draft-takacs-ccamp-oam-configuration-fwk-01=2Etxt =3E draft-takacs-ccamp-rsvp-te-eth-oam-ext-03=2Etxt =3E draft-bernstein-ccamp-wson-encode-01=2Etxt (to become -rwa-encode-00)= =3E = =3E Cheers=2C =3E Adrian and Deborah = =3E = =3E = =3E = =3E Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 03 Dec 2008 07:53:09 +0000 From: Anders Gavler To: Adrian Farrel , "ccamp@ops.ietf.org" Date: Wed, 3 Dec 2008 08:52:26 +0100 Subject: RE: CCAMP drafts for adoption Thread-Topic: CCAMP drafts for adoption Thread-Index: AclUmE0cpTY/XL5TQ8SDX7qklx93vQAg7/Ag Message-ID: <73B74934786FBB4F951B5F99724CEB603DD8291E15@acreoexc01.ad.acreo.se> Accept-Language: sv-SE, en-US Content-Language: en-US acceptlanguage: sv-SE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Yes to all three. /Anders > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behal= f > Of Adrian Farrel > Sent: den 2 december 2008 17:02 > To: ccamp@ops.ietf.org > Subject: CCAMP drafts for adoption > > Hi, > > Can you please express your opinion on the adoption of the following thre= e > drafts as WG drafts. > > Thanks, > Adrian > > draft-takacs-ccamp-oam-configuration-fwk-01.txt > draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt > draft-bernstein-ccamp-wson-encode-01.txt (to become -rwa-encode-00) > > Cheers, > Adrian and Deborah > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 03 Dec 2008 07:33:03 +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: CCAMP drafts for adoption Date: Wed, 3 Dec 2008 08:31:18 +0100 Message-ID: Thread-Topic: CCAMP drafts for adoption Thread-Index: AclUl869tPqn4vzaQ4+mNJcTBH2XXgAgUJ7w From: "Daniele Ceccarelli" To: "Adrian Farrel" , I support all of them. Cheers, Daniele -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On = Behalf Of Adrian Farrel Sent: marted=EC 2 dicembre 2008 17.02 To: ccamp@ops.ietf.org Subject: CCAMP drafts for adoption Hi, Can you please express your opinion on the adoption of the following = three=20 drafts as WG drafts. Thanks, Adrian draft-takacs-ccamp-oam-configuration-fwk-01.txt draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt draft-bernstein-ccamp-wson-encode-01.txt (to become -rwa-encode-00) Cheers, Adrian and Deborah=20 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 03 Dec 2008 04:35:00 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: CCAMP drafts for adoption Date: Tue, 2 Dec 2008 23:34:13 -0500 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA417C1D479@zrtphxm2.corp.nortel.com> Thread-Topic: CCAMP drafts for adoption Thread-Index: AclUl6mpWAW2o7P/QfKhDBZKhoe9CgABkY3AAAiyQSAAAP4GoAABt/WgAANvmB4ACXDVkA== From: "Don Fedyk" To: "Thomas D. Nadeau" , "Nitin Bahadur" , "Adrian Farrel" , Hi Tom Please see inline,=20 >On 12/2/08 5:32 PM, "Don Fedyk" wrote: > >> Hi Nitin=20 >>=20 >>> -----Original Message----- >>> From: owner-ccamp@ops.ietf.org >>> [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Nitin Bahadur >>>=20 >>>=20 >>>>> draft-takacs-ccamp-oam-configuration-fwk-01.txt >>>>> draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt >>>=20 >>> Do not support either of these. >>>=20 >>> From the oam-config-fwk draft: >>>> A new useful application of RSVP-TE is OAM configuration >>>> and control for transport networks. >>>=20 >>> LSP-ping was designed as an OAM mechansim for MPLS LSPs. Why >>> do we need >>> another mechanism? What are the limitations of lsp-ping that warrant >>> this new mechanism? >>=20 >> These drafts support configuration of data plane OAM functions when you >> are using RSVP-TE to setup the paths. The alternative is operator >> configuration. It has nothing to do with LSP Ping. >>=20 >>>=20 >>>> When RSVP-TE is used for LSP establishment it is desirable to bind >>>> OAM setup to connection establishment signalling to avoid two >>>> separate management/configuration steps >>>=20 >>> draft-ietf-bfd-mpls specifies how to use LSP-Ping for >>> automatic setup of >>> BFD-based OAM. >>=20 >> So LSP Ping sets up BFD? Interesting. While I can see this might be >> useful in the case of LDP when debugging a problem you do have issues >> with LSP-Ping reaching all path combinations and certain error >> scenarios. I don't think this is a comprehensive mechanism. > > Don, > > LSP ping is used to "bootstrap" BFD for MPLS networks. It is a perfectly >sound method of solving the problem it sought to solve. Please take a look >at this draft-ietf-bfd-mpls-07 for a description of how this works if you >are unfamiliar. =20 Tom, When I read this draft what I read is that an MPLS LSP may take one or=20 more paths and that a BFD session is set up for one or more of these paths.=20 Since the network may change, the MPLS LSP may vary the number of paths=20 it takes from time to time (ECMP may come and go). So if you have a=20 problem you may fined you have not set up the BFD session on a LSP path=20 or there may well be even 2 BFD sessions running on what is now a single LSP path. In a big network I think this may be a bit of an issue.=20 > >> This is clearly different than what we are specifying in the Ethernet >> OAM case.=20 > > While not a comprehensive mechanism for doing Ethernet OAM, don't you >think that defining how Ethernet OAM works (or is configured) should be done >by the IEEE? What you are proposing here by combining these different >things together is what at least smells like what was thrown out in L2VPN a >number of years ago due to a layer violation when it was tried for >Ethernet/VPLS PWs.=20 We absolutely have left OAM for the IEEE. In fact the whole data plane=20 and OAM is specified in the IEEE. All we are proposing is to optionally=20 signal a IEEE OAM profile of the type of MIPs and MEPs on the connection.=20 This is the point of GMPLS. Generalized control of other technologies. RSVP-TE sessions that don't use these objects would use normal RSVP-TE=20 processing. That is why we have extensible protocols. As Attila points=20 out OAM for other technologies such as optical could also use these=20 GMPLS mechanisms.=20 When you setup paths and CCM in this manner there is no doubt it is=20 protecting the traffic path.=20 Regards, Don=20 > > --Tom Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 03 Dec 2008 04:09:38 +0000 Cc: Nitin Bahadur , Adrian Farrel , Message-Id: From: Shane Amante To: Thomas D. Nadeau Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Subject: Re: CCAMP drafts for adoption Date: Tue, 2 Dec 2008 21:07:42 -0700 Do not support. -shane On Dec 2, 2008, at 2:49 PM, Thomas D. Nadeau wrote: > > I agree with Nitin and do not support the adoption of these drafts. > > --Tom > > > > On 12/2/08 4:35 PM, "Nitin Bahadur" wrote: > >>>> draft-takacs-ccamp-oam-configuration-fwk-01.txt >>>> draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt >> >> Do not support either of these. >> >> From the oam-config-fwk draft: >>> A new useful application of RSVP-TE is OAM configuration >>> and control for transport networks. >> >> LSP-ping was designed as an OAM mechansim for MPLS LSPs. Why do we >> need >> another mechanism? What are the limitations of lsp-ping that warrant >> this new mechanism? >> >>> When RSVP-TE is used for LSP establishment it is desirable to bind >>> OAM setup to connection establishment signalling to avoid two >>> separate management/configuration steps >> >> draft-ietf-bfd-mpls specifies how to use LSP-Ping for automatic >> setup of >> BFD-based OAM. >> We should go along the same path for Ethernet OAM. >> >> Thanks >> Nitin >> > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 03 Dec 2008 00:42: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: RE: CCAMP drafts for adoption Date: Tue, 2 Dec 2008 19:40:55 -0500 Message-ID: <87AC5F88F03E6249AEA68D40BD3E00BE168324AF@zcarhxm2.corp.nortel.com> Thread-Topic: CCAMP drafts for adoption Thread-Index: AclUl6mpWAW2o7P/QfKhDBZKhoe9CgABkY3AAAiyQSAAAP4GoAAApjZgAAHEswAAAIicsAAA2bWAAAKAO+A= From: "David Allan" To: "Nitin Bahadur" , Hi Nitin: My reaction is that spreading state over a number of protocols may keep one superficially simple but drives up the total cost of the solution...from the POV of lines of code, amount to test, amount of state, additional race conditions, delayed setup time etc. so is a specious optimization.... If the path is not up until OAM says so, it is useful to get there in as few transactions as possible... My 2 cents. Dave =20 -----Original Message----- From: Nitin Bahadur [mailto:nitinb@juniper.net]=20 Sent: Tuesday, December 02, 2008 6:38 PM To: Allan, David (CAR:NS00); ccamp@ops.ietf.org Subject: RE: CCAMP drafts for adoption Hi David, > > David, all that I am asking is that one can use the basic-bare-bones > definitions in lsp-ping to setup the Ethernet OAM > > params. I am not talking about applicability nor I am > saying that one > needs to use ping and trace based off lsp-ping for > PBB-TE LSPs.=20 >=20 > But this still requires implementing a new protocol where it does not=20 > already exist, I agree. It does require implementing lsp-ping. But the way these 2 drafts are going, they will end up defining a new mini-oam-boot-strapping protocol on top of RSVP path messages. And once we have a precedence, it will just keep growing. I am basically against using RSVP path message as an OAM related PDU transfer agent. The drafts already specify 3-4 sub-TLVs and a bunch of error codes. This list can grow. The framework draft is generic in nature. So tomorrrow I can use BFD or XXX on top of RSVP (why just ethernet-oam) and I can add 10 more TLVs and 5 more error codes. It's all about keeping RSVP clean. Your requirement is to automate OAM on a GMPLS LSP. Why dirty this poor Path msg. If you do not wish to use Lsp-ping (for whatever reason)...I recommend using something other than a RSVP path msg. > which also requires a *new* bare > bones definition... I think that would be easy. You just need to send the lsp-ping msg along the control-plane. The LSP details can be put in the existing defined TLVs. The ethernet OAM details can be directly copied from these new drafts into a lsp-ping based draft. > >=20 > > I am not asking you to use lsp-ping for LB/LT. I agree that ethernet > OAM already has that and indeed once should use > > that. I am just saying that the setup can be done using lsp-ping. >=20 > I think the point was GMPLS applies to a lot of technologies that=20 > cannot do LSP-PING in the first place, which means such a signalling=20 > extension will be required nonetheless... As I said earlier, use LSP-Ping not for OAM, but for signaling the OAM params. Given that you are using RSVP for signaling the GMPLS LSP via the control plane, you can use LSP-Ping (via control plane) to do the OAM signaling. > can I suggest you > withdraw your objections to the Eth-Oam draft and move the TP parts of > this discussion over to the MPLS list? My main objections to the Eth-oam drafts are not TP related.=20 They are related to using RSVP Path as a transmission mechanism for OAM setup. OAM is complex and tomorrow we might need more TLVs to indicate remote failure or some other condition via the control plane.=20 Dave, you are the co-author of draft-ietf-pwe3-oam-msg-map. Look at the amount of stuff that has gone in there. As a side-note, I am just *a person*. It's the ccamp wg mailing list that needs to say *yes*/*no*. It's all rough consensus right? Thanks Nitin Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 02 Dec 2008 23:55:14 +0000 User-Agent: Microsoft-Entourage/12.14.0.081024 Date: Tue, 02 Dec 2008 18:54:27 -0500 Subject: Re: CCAMP drafts for adoption From: "Thomas D. Nadeau" To: Don Fedyk , Nitin Bahadur , Adrian Farrel , Message-ID: Thread-Topic: CCAMP drafts for adoption Thread-Index: AclUl6mpWAW2o7P/QfKhDBZKhoe9CgABkY3AAAiyQSAAAP4GoAABt/WgAANvmB4= Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit On 12/2/08 5:32 PM, "Don Fedyk" wrote: > Hi Nitin > >> -----Original Message----- >> From: owner-ccamp@ops.ietf.org >> [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Nitin Bahadur >> >> >>>> draft-takacs-ccamp-oam-configuration-fwk-01.txt >>>> draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt >> >> Do not support either of these. >> >> From the oam-config-fwk draft: >>> A new useful application of RSVP-TE is OAM configuration >>> and control for transport networks. >> >> LSP-ping was designed as an OAM mechansim for MPLS LSPs. Why >> do we need >> another mechanism? What are the limitations of lsp-ping that warrant >> this new mechanism? > > These drafts support configuration of data plane OAM functions when you > are using RSVP-TE to setup the paths. The alternative is operator > configuration. It has nothing to do with LSP Ping. > >> >>> When RSVP-TE is used for LSP establishment it is desirable to bind >>> OAM setup to connection establishment signalling to avoid two >>> separate management/configuration steps >> >> draft-ietf-bfd-mpls specifies how to use LSP-Ping for >> automatic setup of >> BFD-based OAM. > > So LSP Ping sets up BFD? Interesting. While I can see this might be > useful in the case of LDP when debugging a problem you do have issues > with LSP-Ping reaching all path combinations and certain error > scenarios. I don't think this is a comprehensive mechanism. Don, LSP ping is used to "bootstrap" BFD for MPLS networks. It is a perfectly sound method of solving the problem it sought to solve. Please take a look at this draft-ietf-bfd-mpls-07 for a description of how this works if you are unfamiliar. > This is clearly different than what we are specifying in the Ethernet > OAM case. While not a comprehensive mechanism for doing Ethernet OAM, don't you think that defining how Ethernet OAM works (or is configured) should be done by the IEEE? What you are proposing here by combining these different things together is what at least smells like what was thrown out in L2VPN a number of years ago due to a layer violation when it was tried for Ethernet/VPLS PWs. --Tom > Regards, > Don > > > >> We should go along the same path for Ethernet OAM. >> >> Thanks >> Nitin >> >> > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 02 Dec 2008 23:41:57 +0000 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: CCAMP drafts for adoption Date: Tue, 2 Dec 2008 15:37:46 -0800 Message-ID: <7FA0C743C38E5340BFC2873488FA1E8E025DDF6E@emailcorp3.jnpr.net> Thread-Topic: CCAMP drafts for adoption thread-index: AclUl6mpWAW2o7P/QfKhDBZKhoe9CgABkY3AAAiyQSAAAP4GoAAApjZgAAHEswAAAIicsAAA2bWA From: Nitin Bahadur To: "David Allan" , Hi David, > > David, all that I am asking is that one can use the basic-bare-bones > definitions in lsp-ping to setup the Ethernet OAM=20 > > params. I am not talking about applicability nor I am=20 > saying that one > needs to use ping and trace based off lsp-ping for > PBB-TE LSPs.=20 >=20 > But this still requires implementing a new protocol where it=20 > does not already exist, I agree. It does require implementing lsp-ping. But the way these 2 drafts are going, they will end up defining a new mini-oam-boot-strapping protocol on top of RSVP path messages. And once we have a precedence, it will just keep growing. I am basically against using RSVP path message as an OAM related PDU transfer agent. The drafts already specify 3-4 sub-TLVs and a bunch of error codes. This list can grow. The framework draft is generic in nature. So tomorrrow I can use BFD or XXX on top of RSVP (why just ethernet-oam) and I can add 10 more TLVs and 5 more error codes. It's all about keeping RSVP clean. Your requirement is to automate OAM on a GMPLS LSP. Why dirty this poor Path msg. If you do not wish to use Lsp-ping (for whatever reason)...I recommend using something other than a RSVP path msg. > which also requires a *new* bare=20 > bones definition... I think that would be easy. You just need to send the lsp-ping msg=20 along the control-plane. The LSP details can be put in the existing defined TLVs. The ethernet OAM details can be directly copied from these new drafts into a lsp-ping based draft. > >=20 > > I am not asking you to use lsp-ping for LB/LT. I agree that ethernet > OAM already has that and indeed once should use=20 > > that. I am just saying that the setup can be done using lsp-ping. >=20 > I think the point was GMPLS applies to a lot of technologies=20 > that cannot do LSP-PING in the first place, which means such=20 > a signalling extension will be required nonetheless... As I said earlier, use LSP-Ping not for OAM, but for signaling the OAM params. Given that you are using RSVP for signaling the GMPLS LSP via the control plane, you can use LSP-Ping (via control plane) to do the OAM signaling. > can I suggest you=20 > withdraw your objections to the Eth-Oam draft and move the TP=20 > parts of this discussion over to the MPLS list? My main objections to the Eth-oam drafts are not TP related.=20 They are related to using RSVP Path as a transmission mechanism for=20 OAM setup. OAM is complex and tomorrow we might need more TLVs to indicate remote failure=20 or some other condition via the control plane.=20 Dave, you are the co-author of draft-ietf-pwe3-oam-msg-map. Look at the amount of stuff that has gone in there. As a side-note, I am just *a person*. It's the ccamp wg mailing list that needs to say *yes*/*no*. It's all rough consensus right? Thanks Nitin Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 02 Dec 2008 23:41:49 +0000 User-Agent: Microsoft-Entourage/12.14.0.081024 Date: Tue, 02 Dec 2008 18:41:04 -0500 Subject: Re: CCAMP drafts for adoption From: "Thomas D. Nadeau" To: David Allan , Nitin Bahadur , Message-ID: Thread-Topic: CCAMP drafts for adoption Thread-Index: AclUl6mpWAW2o7P/QfKhDBZKhoe9CgABkY3AAAiyQSAAAP4GoAAApjZgAAHEswAAAIicsAABvGDw Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Dave, As an operator with a very big deployment of MPLS and a lot of money invested in OSS to manage said network, I do not want a different mechanism to the one that has been deployed today to control OAM for any MPLS networks, MPLS-TP included. --Tom On 12/2/08 6:01 PM, "David Allan" wrote: > HI Nitin: > > Thanks for replying.... > > >> David, all that I am asking is that one can use the basic-bare-bones > definitions in lsp-ping to setup the Ethernet OAM >> params. I am not talking about applicability nor I am saying that one > needs to use ping and trace based off lsp-ping for > PBB-TE LSPs. > > But this still requires implementing a new protocol where it does not > already exist, which also requires a *new* bare bones definition... > >> We have a whole bunch of stuff defined in RSVP. Obviously some of them > are not applicable for GMPLS LSPs. But that does > not mean that we go > define G-RSVP (for GMPLS LSPs). > > Isn't that CCAMPs mandate? > > > >> I am not asking you to use lsp-ping for LB/LT. I agree that ethernet > OAM already has that and indeed once should use >> that. I am just saying that the setup can be done using lsp-ping. > > I think the point was GMPLS applies to a lot of technologies that cannot > do LSP-PING in the first place, which means such a signalling extension > will be required nonetheless... > > >> LSP-Ping is already non-IP from a *forwarding* perspective. LSP-Ping > has a reply-mode of *application channel* which can > be used for things > like bi-directional LSPs. So for MPLS-TP LSPs, the lsp-ping replies > would go on the LSP reverse path > (label-switched and not IP > forwarded). > > OK, I can see that such an approach could be made to work and would be > desirable to some. On that basis, can I suggest you withdraw your > objections to the Eth-Oam draft and move the TP parts of this discussion > over to the MPLS list? That would seem appropriate... > > Cheers > Dave > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 02 Dec 2008 23:12:04 +0000 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C954D2.EBBD444E" Subject: RE: CCAMP drafts for adoption Date: Tue, 2 Dec 2008 15:08:43 -0800 Message-ID: <7FA0C743C38E5340BFC2873488FA1E8E025DDF6C@emailcorp3.jnpr.net> Thread-Topic: CCAMP drafts for adoption thread-index: AclUzGKm7SmKujP5QIuH9IiMmVRPCQAA5n1w From: Nitin Bahadur To: "Igor Bryskin" , "Attila Takacs" , ------_=_NextPart_001_01C954D2.EBBD444E Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi Igor, =20 I like your clear explanation (no pun intended). I understand your view-point....my views are as below... =20 > The difference is that GMPLS is a control plane, while OAM is supposed to work in the data plane. In transport =20 > networks control plane and data plane are separated. In fact, OAM should work without and should not depend upon=20 > control plane at all. You can not send Ping messages over lambda layer network connection, can you?=20 =20 Agreed.=20 =20 > On the other hand, you can use GMPLS to consistently configire OAM function on the connection NEs, and that's what =20 > these drafts as I understand are about. =20 I understand the motivation of these drafts and I totally agree with that. =20 > In other words, in MPLS , LSP Ping is OAM, while GMPLS can only automate OAM configuration, it can not relalize =20 > OAM on its own. I agree that LSP-Ping may not be the OAM mechanism for GMPLS LSPs. All I am saying is that LSP-Ping can be used to automate the OAM configuration. There is enough machinery available in lsp-ping to enable that. So why re-invent a new protocol? One could send lsp-ping messages (control-plane routed) containing the information needed to automate OAM. =20 Question: Isn't it simpler to use RSVP path messages to automate this ? Answer: Yes it looks simpler. =20 Question: Then why is Nitin opposed ? Answer: Because as this draft progresses, you will end up adding a whole bunch of TLVs/sub-TLVs and related error codes. And all these have nothing to do with a RSVP path message. The draft already has 3-4 sub-TLVs. In effect, the 2 drafts are defining a mini-OAM-boot-strapping protocol on top of RSVP path message. Nitin=20 =09 =09 =09 ________________________________ From: Nitin Bahadur To: Attila Takacs ; Adrian Farrel ; ccamp@ops.ietf.org Sent: Tuesday, December 2, 2008 5:01:11 PM Subject: RE: CCAMP drafts for adoption =09 =09 Hi Attlia, =09 What is the limitation of lsp-ping that prevents it from being applied to GMPLS? If an existing mechanism can be applied, then why not? If lsp-ping needs extensions to support GMPLS LSPs, feel free to make/specify those extensions. =09 Thanks Nitin =20 =09 > -----Original Message----- > From: Attila Takacs [mailto:Attila.Takacs@ericsson.com]=20 > Sent: Tuesday, December 02, 2008 1:52 PM > To: Nitin Bahadur; Adrian Farrel; ccamp@ops.ietf.org > Subject: RE: CCAMP drafts for adoption >=20 > Hi Nitin, >=20 > Please note that these mechanisms are proposed for GMPLS and=20 > as such to provide support for any data plane technology=20 > specific OAM mechanism. As you noted LSP Ping is for MPLS and=20 > BFD only. =20 >=20 > Best regards, > Attila >=20 > > -----Original Message----- > > From: owner-ccamp@ops.ietf.org > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Nitin Bahadur > > Sent: Tuesday, December 02, 2008 10:35 PM > > To: Adrian Farrel; ccamp@ops.ietf.org > > Subject: RE: CCAMP drafts for adoption > >=20 > >=20 > >=20 > > > > draft-takacs-ccamp-oam-configuration-fwk-01.txt > > > > draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt > >=20 > > Do not support either of these. > >=20 > > From the oam-config-fwk draft: > > > A new useful application of RSVP-TE is OAM configuration > > and control > > > for transport networks. > >=20 > > LSP-ping was designed as an OAM mechansim for MPLS LSPs. Why do we=20 > > need another mechanism? What are the limitations of lsp-ping that=20 > > warrant this new mechanism? > >=20 > > > When RSVP-TE is used for LSP establishment it is desirable > > to bind OAM > > > setup to connection establishment signalling to avoid two=20 > separate=20 > > > management/configuration steps > >=20 > > draft-ietf-bfd-mpls specifies how to use LSP-Ping for=20 > automatic setup=20 > > of BFD-based OAM. > > We should go along the same path for Ethernet OAM. > >=20 > > Thanks > > Nitin > >=20 > >=20 >=20 =09 =09 ------_=_NextPart_001_01C954D2.EBBD444E Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Hi Igor,
 
  I like your clear explanation (no pun = intended). I=20 understand your view-point....my views are as = below...
 
> The=20 difference is that GMPLS is a control plane, while OAM is supposed to = work in=20 the data plane. In transport  
> networks  control plane and data plane are separated. = In fact,=20 OAM should work without and should not depend upon 
>  control plane at all. = You can not=20 send Ping messages over lambda layer network connection, can you? 
 
Agreed. 
 
> =  On the=20 other hand, you can use GMPLS to consistently configire OAM function on = the=20 connection NEs, and that's what  
> these drafts as I = understand are=20 about.
 
I understand the motivation of these drafts and = I totally=20 agree with that.
 
> =  In=20 other words, in MPLS ,  LSP Ping is OAM, = while GMPLS=20 can only automate OAM configuration, it can not relalize  
>  OAM  on its own.
I agree that LSP-Ping may not be the OAM = mechanism for=20 GMPLS LSPs. All = I am saying is=20 that LSP-Ping can be used to automate the OAM configuration. There is = enough=20 machinery available in lsp-ping to enable that. So why re-invent a new = protocol?=20 One could send lsp-ping messages (control-plane routed) containing the=20 information needed to automate OAM.
 
Question: Isn't it simpler to use RSVP path = messages to=20 automate this ?
Answer: Yes it looks = simpler.
 
Question: Then why is Nitin = opposed ?
Answer: Because as this draft progresses, = you will end=20 up adding a whole bunch of TLVs/sub-TLVs and related error codes. And = all=20 these have nothing to do with a RSVP path message. The draft = already=20 has 3-4 sub-TLVs. In effect, the 2 drafts are defining a = mini-OAM-boot-strapping=20 protocol on top of RSVP path message.

Nitin 

From: Nitin Bahadur=20 <nitinb@juniper.net>
To: Attila Takacs=20 <Attila.Takacs@ericsson.com>; Adrian Farrel = <adrian@olddog.co.uk>;=20 ccamp@ops.ietf.org
Sent:=20 Tuesday, December 2, 2008 5:01:11 PM
Subject: RE: CCAMP drafts for=20 adoption


Hi Attlia,

  What is the = limitation of=20 lsp-ping that prevents it from being
applied to GMPLS?
If an = existing=20 mechanism can be applied, then why not? If lsp-ping = needs
extensions to=20 support GMPLS LSPs, feel free to make/specify=20 those
extensions.

Thanks
Nitin 

> = -----Original=20 Message-----
> From: Attila Takacs [mailto:Attila.Takacs@ericsson.com<= /A>]=20
> Sent: Tuesday, December 02, 2008 1:52 PM
> To: Nitin = Bahadur;=20 Adrian Farrel; ccamp@ops.ietf.org
> = Subject:=20 RE: CCAMP drafts for adoption
>
> Hi Nitin,
> =
>=20 Please note that these mechanisms are proposed for GMPLS and
> = as such=20 to provide support for any data plane technology
> specific OAM = mechanism. As you noted LSP Ping is for MPLS and
> BFD = only. =20
>
> Best regards,
> Attila
>
> >=20 -----Original Message-----
> > From: owner-ccamp@ops.ietf.org<= BR>>=20 > [mailto:owner-ccamp@ops.ietf.org]= On=20 Behalf Of Nitin Bahadur
> > Sent: Tuesday, December 02, 2008 = 10:35=20 PM
> > To: Adrian Farrel; ccamp@ops.ietf.org
> = >=20 Subject: RE: CCAMP drafts for adoption
> >
> > =
>=20 >
> > > >=20 draft-takacs-ccamp-oam-configuration-fwk-01.txt
> > > > = draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt
> >
> = > Do=20 not support either of these.
> >
> > From the=20 oam-config-fwk draft:
> > > A new useful application of = RSVP-TE is=20 OAM configuration
> > and control
> > > for = transport=20 networks.
> >
> > LSP-ping was designed as an OAM = mechansim=20 for MPLS LSPs. Why do we
> > need another mechanism? What = are the=20 limitations of lsp-ping that
> > warrant this new = mechanism?
>=20 >
> > > When RSVP-TE is used for LSP establishment it = is=20 desirable
> > to bind OAM
> > > setup to = connection=20 establishment signalling to avoid two
> separate
> > = >=20 management/configuration steps
> >
> > = draft-ietf-bfd-mpls=20 specifies how to use LSP-Ping for
> automatic setup
> = > of=20 BFD-based OAM.
> > We should go along the same path for = Ethernet=20 OAM.
> >
> > Thanks
> > Nitin
> > =
> >
> =


------_=_NextPart_001_01C954D2.EBBD444E-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 02 Dec 2008 23:03:02 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: CCAMP drafts for adoption Date: Tue, 2 Dec 2008 18:01:25 -0500 Message-ID: <87AC5F88F03E6249AEA68D40BD3E00BE168324AD@zcarhxm2.corp.nortel.com> Thread-Topic: CCAMP drafts for adoption Thread-Index: AclUl6mpWAW2o7P/QfKhDBZKhoe9CgABkY3AAAiyQSAAAP4GoAAApjZgAAHEswAAAIicsA== From: "David Allan" To: "Nitin Bahadur" , HI Nitin: Thanks for replying.... > David, all that I am asking is that one can use the basic-bare-bones definitions in lsp-ping to setup the Ethernet OAM=20 > params. I am not talking about applicability nor I am saying that one needs to use ping and trace based off lsp-ping for > PBB-TE LSPs.=20 But this still requires implementing a new protocol where it does not already exist, which also requires a *new* bare bones definition... > We have a whole bunch of stuff defined in RSVP. Obviously some of them are not applicable for GMPLS LSPs. But that does > not mean that we go define G-RSVP (for GMPLS LSPs). Isn't that CCAMPs mandate? =20 > I am not asking you to use lsp-ping for LB/LT. I agree that ethernet OAM already has that and indeed once should use=20 > that. I am just saying that the setup can be done using lsp-ping. I think the point was GMPLS applies to a lot of technologies that cannot do LSP-PING in the first place, which means such a signalling extension will be required nonetheless... > LSP-Ping is already non-IP from a *forwarding* perspective. LSP-Ping has a reply-mode of *application channel* which can > be used for things like bi-directional LSPs. So for MPLS-TP LSPs, the lsp-ping replies would go on the LSP reverse path > (label-switched and not IP forwarded). OK, I can see that such an approach could be made to work and would be desirable to some. On that basis, can I suggest you withdraw your objections to the Eth-Oam draft and move the TP parts of this discussion over to the MPLS list? That would seem appropriate... Cheers Dave Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 02 Dec 2008 22:46:58 +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: CCAMP drafts for adoption Date: Tue, 2 Dec 2008 14:43:21 -0800 Message-ID: <7FA0C743C38E5340BFC2873488FA1E8E025DDF6B@emailcorp3.jnpr.net> Thread-Topic: CCAMP drafts for adoption thread-index: AclUl6mpWAW2o7P/QfKhDBZKhoe9CgABkY3AAAiyQSAAAP4GoAAApjZgAAHEswA= From: Nitin Bahadur To: "David Allan" , > > LSP-ping was designed as an OAM mechansim for MPLS LSPs. Why do we > need another mechanism? What are the limitations of=20 > > lsp-ping that warrant this new mechanism? We=20 > should go along > the same path for Ethernet OAM. >=20 > It is not applicable to either a PBB-TE switched path or, if=20 > you are of that persuasion, an MPLS-TP switched path...as it=20 > stands today. And it only goes downhill from there.... David, all that I am asking is that one can use the basic-bare-bones definitions=20 in lsp-ping to setup the Ethernet OAM params. I am not talking about applicability nor I am saying that one needs to use ping and trace based off lsp-ping for PBB-TE LSPs.=20 We have a whole bunch of stuff defined in RSVP. Obviously some of them are not applicable for GMPLS LSPs. But that does not mean that we go define G-RSVP (for GMPLS LSPs). =20 > I would think the inappropriateness of applying LSP-PING to=20 > Ethernet OAM would be self evident...Ethernet OAM already has=20 > it's own LB/LT functionality so mandating another loopback=20 > exclusively for OAM configuration is gratuitously complex. I am not asking you to use lsp-ping for LB/LT. I agree that ethernet OAM already has that and indeed once should use that. I am just saying that the setup can be done using lsp-ping. =20 > As for MPLS-TP, LSP-PING would need recasting as a "non-IP"=20 > protocol to fit the mandated profile from the joint design=20 > team and likely would benefit from a trip to the fat farm to=20 > shed the other features it did not need within said profile... LSP-Ping is already non-IP from a *forwarding* perspective. LSP-Ping has a reply-mode of *application channel* which can be used for things like bi-directional LSPs. So for MPLS-TP LSPs, the lsp-ping replies would go on the LSP reverse path (label-switched and not IP forwarded). Thanks Nitin Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 02 Dec 2008 22:38:16 +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: CCAMP drafts for adoption Date: Tue, 2 Dec 2008 14:35:44 -0800 Message-ID: <7FA0C743C38E5340BFC2873488FA1E8E025DDF6A@emailcorp3.jnpr.net> Thread-Topic: CCAMP drafts for adoption thread-index: AclUl6mpWAW2o7P/QfKhDBZKhoe9CgABkY3AAAiyQSAAAP4GoAAAuZwwAABaoIAAACzaAAAAe+hQ From: Nitin Bahadur To: "Attila Takacs" , > I would formulate this form the other way around. If we=20 > already have a technology agnostic solution, read GMPLS, it=20 > seems to be straightforward to continue using it. Then why not? :-) >=20 > One key benefit of using RSVP-TE is that OAM configuration is=20 > bound to the actual LSP establishment this simplifies=20 > management and avoids misconfiguration. With LSP Ping we=20 > would need one mechanism to setup the LSPs (read *not* just=20 > MPLS) using GMPLS and then apply another solution say=20 > Generalized-LSP Ping to configure OAM; if I understand your=20 > proposal right. Yes...your understanding of my proposal is correct.=20 But it would solve your issue of manual=20 OAM configuration. Agreed, it's a 2-step control-plane process. =20 > From another perspective, what would be the use of LSP Ping=20 > over, e.g., an optical network or Ethernet using CFM? Just for setup of the OAM parameters. Ethernet OAM provides a bunch of capabilities (like LT/LB) and you would use them as-is. The advantage of using lsp-ping is that only the LSP egress sees the OAM parmeters.=20 If you add a new-TLV to the PATH msg, then you need to send it on every PATH msg... You really need to signal the parameters once during LSP-setup time (and perhaps when the parameters are changed). LSP-Ping has a whole bunch of stuff defined. Most of it is not needed/applicable in various scenarios. But the advantage is that it's all there. As you go ahead with defining a new mechanism, you will gradually see other requirements/needs and you might end up re-inventing lsp-ping in another form. > Best regards, > Attila >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: Nitin Bahadur [mailto:nitinb@juniper.net] > > Sent: Tuesday, December 02, 2008 11:01 PM > > To: Attila Takacs; Adrian Farrel; ccamp@ops.ietf.org > > Subject: RE: CCAMP drafts for adoption > >=20 > >=20 > > Hi Attlia, > >=20 > > What is the limitation of lsp-ping that prevents it from being=20 > > applied to GMPLS? > > If an existing mechanism can be applied, then why not? If lsp-ping=20 > > needs extensions to support GMPLS LSPs, feel free to make/specify=20 > > those extensions. > >=20 > > Thanks > > Nitin > >=20 > > > -----Original Message----- > > > From: Attila Takacs [mailto:Attila.Takacs@ericsson.com] > > > Sent: Tuesday, December 02, 2008 1:52 PM > > > To: Nitin Bahadur; Adrian Farrel; ccamp@ops.ietf.org > > > Subject: RE: CCAMP drafts for adoption > > >=20 > > > Hi Nitin, > > >=20 > > > Please note that these mechanisms are proposed for GMPLS > > and as such > > > to provide support for any data plane technology specific OAM=20 > > > mechanism. As you noted LSP Ping is for MPLS and BFD only. > > >=20 > > > Best regards, > > > Attila > > >=20 > > > > -----Original Message----- > > > > From: owner-ccamp@ops.ietf.org > > > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Nitin Bahadur > > > > Sent: Tuesday, December 02, 2008 10:35 PM > > > > To: Adrian Farrel; ccamp@ops.ietf.org > > > > Subject: RE: CCAMP drafts for adoption > > > >=20 > > > >=20 > > > >=20 > > > > > > draft-takacs-ccamp-oam-configuration-fwk-01.txt > > > > > > draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt > > > >=20 > > > > Do not support either of these. > > > >=20 > > > > From the oam-config-fwk draft: > > > > > A new useful application of RSVP-TE is OAM configuration > > > > and control > > > > > for transport networks. > > > >=20 > > > > LSP-ping was designed as an OAM mechansim for MPLS LSPs.=20 > > Why do we > > > > need another mechanism? What are the limitations of=20 > lsp-ping that=20 > > > > warrant this new mechanism? > > > >=20 > > > > > When RSVP-TE is used for LSP establishment it is desirable > > > > to bind OAM > > > > > setup to connection establishment signalling to avoid two > > > separate > > > > > management/configuration steps > > > >=20 > > > > draft-ietf-bfd-mpls specifies how to use LSP-Ping for > > > automatic setup > > > > of BFD-based OAM. > > > > We should go along the same path for Ethernet OAM. > > > >=20 > > > > Thanks > > > > Nitin > > > >=20 > > > >=20 > > >=20 > >=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 02 Dec 2008 22:33:03 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: CCAMP drafts for adoption Date: Tue, 2 Dec 2008 17:32:18 -0500 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA417C1D2F4@zrtphxm2.corp.nortel.com> Thread-Topic: CCAMP drafts for adoption Thread-Index: AclUl6mpWAW2o7P/QfKhDBZKhoe9CgABkY3AAAiyQSAAAP4GoAABt/Wg From: "Don Fedyk" To: "Nitin Bahadur" , "Adrian Farrel" , Hi Nitin=20 > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Nitin Bahadur >=20 >=20 > > > draft-takacs-ccamp-oam-configuration-fwk-01.txt > > > draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt >=20 > Do not support either of these. >=20 > From the oam-config-fwk draft: > > A new useful application of RSVP-TE is OAM configuration > > and control for transport networks. >=20 > LSP-ping was designed as an OAM mechansim for MPLS LSPs. Why=20 > do we need > another mechanism? What are the limitations of lsp-ping that warrant > this new mechanism? These drafts support configuration of data plane OAM functions when you are using RSVP-TE to setup the paths. The alternative is operator configuration. It has nothing to do with LSP Ping.=20 >=20 > > When RSVP-TE is used for LSP establishment it is desirable to bind > > OAM setup to connection establishment signalling to avoid two > > separate management/configuration steps >=20 > draft-ietf-bfd-mpls specifies how to use LSP-Ping for=20 > automatic setup of > BFD-based OAM. So LSP Ping sets up BFD? Interesting. While I can see this might be useful in the case of LDP when debugging a problem you do have issues with LSP-Ping reaching all path combinations and certain error scenarios. I don't think this is a comprehensive mechanism.=20 This is clearly different than what we are specifying in the Ethernet OAM case.=20 Regards, Don =20 > We should go along the same path for Ethernet OAM. >=20 > Thanks > Nitin >=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 02 Dec 2008 22:22:06 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=v/bPulpuQNgBteS+q2Vgz3jomFVNKBXMvJ+Qz4EvOoekt8VJ58aBbR/j7sdo3WlGG844MD669vGyO1BrOUPFCOl0kl5ik4f2KptKdpFlhLcGvxEJoZiYBEch9NG6ZC/QMSYQlMyuurx4T6xSD+x1RVbuyRDK/9YO9hzvozgh2Q0=; Date: Tue, 2 Dec 2008 14:21:51 -0800 (PST) From: Igor Bryskin Subject: Re: CCAMP drafts for adoption To: Nitin Bahadur , Attila Takacs , Adrian Farrel , ccamp@ops.ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1170914688-1228256511=:95032" Message-ID: <684158.95032.qm@web36805.mail.mud.yahoo.com> --0-1170914688-1228256511=:95032 Content-Type: text/plain; charset=us-ascii Nitin, The difference is that GMPLS is a control plane, while OAM is supposed to work in the data plane. In transport networks control plane and data plane are separated. In fact, OAM should work without and should not depend upon control plane at all. You can not send Ping messages over lambda layer network connection, can you? On the other hand, you can use GMPLS to consistently configire OAM function on the connection NEs, and that's what these drafts as I understand are about. In other words, in MPLS LSP Ping is OAM, while GMPLS can only automate OAM configuration, it can not relalize OAM on its own. Cheers, Igor ________________________________ From: Nitin Bahadur To: Attila Takacs ; Adrian Farrel ; ccamp@ops.ietf.org Sent: Tuesday, December 2, 2008 5:01:11 PM Subject: RE: CCAMP drafts for adoption Hi Attlia, What is the limitation of lsp-ping that prevents it from being applied to GMPLS? If an existing mechanism can be applied, then why not? If lsp-ping needs extensions to support GMPLS LSPs, feel free to make/specify those extensions. Thanks Nitin > -----Original Message----- > From: Attila Takacs [mailto:Attila.Takacs@ericsson.com] > Sent: Tuesday, December 02, 2008 1:52 PM > To: Nitin Bahadur; Adrian Farrel; ccamp@ops.ietf.org > Subject: RE: CCAMP drafts for adoption > > Hi Nitin, > > Please note that these mechanisms are proposed for GMPLS and > as such to provide support for any data plane technology > specific OAM mechanism. As you noted LSP Ping is for MPLS and > BFD only. > > Best regards, > Attila > > > -----Original Message----- > > From: owner-ccamp@ops.ietf.org > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Nitin Bahadur > > Sent: Tuesday, December 02, 2008 10:35 PM > > To: Adrian Farrel; ccamp@ops.ietf.org > > Subject: RE: CCAMP drafts for adoption > > > > > > > > > > draft-takacs-ccamp-oam-configuration-fwk-01.txt > > > > draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt > > > > Do not support either of these. > > > > From the oam-config-fwk draft: > > > A new useful application of RSVP-TE is OAM configuration > > and control > > > for transport networks. > > > > LSP-ping was designed as an OAM mechansim for MPLS LSPs. Why do we > > need another mechanism? What are the limitations of lsp-ping that > > warrant this new mechanism? > > > > > When RSVP-TE is used for LSP establishment it is desirable > > to bind OAM > > > setup to connection establishment signalling to avoid two > separate > > > management/configuration steps > > > > draft-ietf-bfd-mpls specifies how to use LSP-Ping for > automatic setup > > of BFD-based OAM. > > We should go along the same path for Ethernet OAM. > > > > Thanks > > Nitin > > > > > --0-1170914688-1228256511=:95032 Content-Type: text/html; charset=us-ascii
Nitin,

The difference is that GMPLS is a control plane, while OAM is supposed to work in the data plane. In transport networks control plane and data plane are separated. In fact, OAM should work without and should not depend upon control plane at all. You can not send Ping messages over lambda layer network connection, can you?
On the other hand, you can use GMPLS to consistently configire OAM function on the connection NEs, and that's what these drafts as I understand are about.

In other words, in MPLS LSP Ping is OAM, while GMPLS can only automate OAM configuration, it can not relalize OAM on its own.

Cheers,
Igor

From: Nitin Bahadur <nitinb@juniper.net>
To: Attila Takacs <Attila.Takacs@ericsson.com>; Adrian Farrel <adrian@olddog.co.uk>; ccamp@ops.ietf.org
Sent: Tuesday, December 2, 2008 5:01:11 PM
Subject: RE: CCAMP drafts for adoption


Hi Attlia,

  What is the limitation of lsp-ping that prevents it from being
applied to GMPLS?
If an existing mechanism can be applied, then why not? If lsp-ping needs
extensions to support GMPLS LSPs, feel free to make/specify those
extensions.

Thanks
Nitin 

> -----Original Message-----
> From: Attila Takacs [mailto:Attila.Takacs@ericsson.com]
> Sent: Tuesday, December 02, 2008 1:52 PM
> To: Nitin Bahadur; Adrian Farrel; ccamp@ops.ietf.org
> Subject: RE: CCAMP drafts for adoption
>
> Hi Nitin,
>
> Please note that these mechanisms are proposed for GMPLS and
> as such to provide support for any data plane technology
> specific OAM mechanism. As you noted LSP Ping is for MPLS and
> BFD only. 
>
> Best regards,
> Attila
>
> > -----Original Message-----
> > From: owner-ccamp@ops.ietf.org
> > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Nitin Bahadur
> > Sent: Tuesday, December 02, 2008 10:35 PM
> > To: Adrian Farrel; ccamp@ops.ietf.org
> > Subject: RE: CCAMP drafts for adoption
> >
> >
> >
> > > > draft-takacs-ccamp-oam-configuration-fwk-01.txt
> > > > draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt
> >
> > Do not support either of these.
> >
> > From the oam-config-fwk draft:
> > > A new useful application of RSVP-TE is OAM configuration
> > and control
> > > for transport networks.
> >
> > LSP-ping was designed as an OAM mechansim for MPLS LSPs. Why do we
> > need another mechanism? What are the limitations of lsp-ping that
> > warrant this new mechanism?
> >
> > > When RSVP-TE is used for LSP establishment it is desirable
> > to bind OAM
> > > setup to connection establishment signalling to avoid two
> separate
> > > management/configuration steps
> >
> > draft-ietf-bfd-mpls specifies how to use LSP-Ping for
> automatic setup
> > of BFD-based OAM.
> > We should go along the same path for Ethernet OAM.
> >
> > Thanks
> > Nitin
> >
> >
>


--0-1170914688-1228256511=:95032-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 02 Dec 2008 22:21:28 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: CCAMP drafts for adoption Date: Tue, 2 Dec 2008 22:20:52 -0000 Message-ID: <2ECAA42C79676B42AEBAC11229CA7D0C03B2F399@E03MVB2-UKBR.domain1.systemhost.net> Thread-Topic: CCAMP drafts for adoption thread-index: AclUl6mpWAW2o7P/QfKhDBZKhoe9CgABkY3AAAiyQSAAAP4GoAAAuZwwAABaoIAAAIBcIA== From: To: , , , You should not be using one DP OAM (heavyweight) function to activate (deactivate??) another DP OAM (lightweight) function. However, since LDP does not create proper connections there is no concept of LSP (path) set-up/tear-down...ergo LSP ping tries to treat it like a cl-ps mode network case. This is NOT the case for GMPLS...esp when applied to any co-cs mode technology (here proper connections are forced), and it is not the case for the co-ps mode when proper connections are used (eg RSVP-TE in MPLS). Hopwever to be very clear here...it is operationally critical to be able to activate/decativate OAM flows in sync with whatever CP or MP process is responsible for connection set-up/tear-down in both co-cs and co-ps mode layer networks....and LSP ping simply does not fit the bill here. regards, Neil > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Nitin Bahadur > Sent: 02 December 2008 22:01 > To: Attila Takacs; Adrian Farrel; ccamp@ops.ietf.org > Subject: RE: CCAMP drafts for adoption >=20 >=20 > Hi Attlia, >=20 > What is the limitation of lsp-ping that prevents it from=20 > being applied to GMPLS? > If an existing mechanism can be applied, then why not? If=20 > lsp-ping needs extensions to support GMPLS LSPs, feel free to=20 > make/specify those extensions. >=20 > Thanks > Nitin =20 >=20 > > -----Original Message----- > > From: Attila Takacs [mailto:Attila.Takacs@ericsson.com] > > Sent: Tuesday, December 02, 2008 1:52 PM > > To: Nitin Bahadur; Adrian Farrel; ccamp@ops.ietf.org > > Subject: RE: CCAMP drafts for adoption > >=20 > > Hi Nitin, > >=20 > > Please note that these mechanisms are proposed for GMPLS=20 > and as such=20 > > to provide support for any data plane technology specific OAM=20 > > mechanism. As you noted LSP Ping is for MPLS and BFD only. > >=20 > > Best regards, > > Attila > >=20 > > > -----Original Message----- > > > From: owner-ccamp@ops.ietf.org > > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Nitin Bahadur > > > Sent: Tuesday, December 02, 2008 10:35 PM > > > To: Adrian Farrel; ccamp@ops.ietf.org > > > Subject: RE: CCAMP drafts for adoption > > >=20 > > >=20 > > >=20 > > > > > draft-takacs-ccamp-oam-configuration-fwk-01.txt > > > > > draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt > > >=20 > > > Do not support either of these. > > >=20 > > > From the oam-config-fwk draft: > > > > A new useful application of RSVP-TE is OAM configuration > > > and control > > > > for transport networks. > > >=20 > > > LSP-ping was designed as an OAM mechansim for MPLS LSPs.=20 > Why do we=20 > > > need another mechanism? What are the limitations of lsp-ping that=20 > > > warrant this new mechanism? > > >=20 > > > > When RSVP-TE is used for LSP establishment it is desirable > > > to bind OAM > > > > setup to connection establishment signalling to avoid two > > separate > > > > management/configuration steps > > >=20 > > > draft-ietf-bfd-mpls specifies how to use LSP-Ping for > > automatic setup > > > of BFD-based OAM. > > > We should go along the same path for Ethernet OAM. > > >=20 > > > Thanks > > > Nitin > > >=20 > > >=20 > >=20 >=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 02 Dec 2008 22:15:27 +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: CCAMP drafts for adoption Date: Tue, 2 Dec 2008 23:14:01 +0100 Message-ID: <53CCFDD6E346CB43994852666C210E9105B70DA5@esealmw116.eemea.ericsson.se> Thread-Topic: CCAMP drafts for adoption thread-index: AclUl6mpWAW2o7P/QfKhDBZKhoe9CgABkY3AAAiyQSAAAP4GoAAAuZwwAABaoIAAACzaAA== From: "Attila Takacs" To: "Nitin Bahadur" , "Adrian Farrel" , Hi Nitin, I would formulate this form the other way around. If we already have a technology agnostic solution, read GMPLS, it seems to be straightforward to continue using it. Then why not? :-) One key benefit of using RSVP-TE is that OAM configuration is bound to the actual LSP establishment this simplifies management and avoids misconfiguration. With LSP Ping we would need one mechanism to setup the LSPs (read *not* just MPLS) using GMPLS and then apply another solution say Generalized-LSP Ping to configure OAM; if I understand your proposal right. >From another perspective, what would be the use of LSP Ping over, e.g., an optical network or Ethernet using CFM? Best regards, Attila > -----Original Message----- > From: Nitin Bahadur [mailto:nitinb@juniper.net]=20 > Sent: Tuesday, December 02, 2008 11:01 PM > To: Attila Takacs; Adrian Farrel; ccamp@ops.ietf.org > Subject: RE: CCAMP drafts for adoption >=20 >=20 > Hi Attlia, >=20 > What is the limitation of lsp-ping that prevents it from=20 > being applied to GMPLS? > If an existing mechanism can be applied, then why not? If=20 > lsp-ping needs extensions to support GMPLS LSPs, feel free to=20 > make/specify those extensions. >=20 > Thanks > Nitin =20 >=20 > > -----Original Message----- > > From: Attila Takacs [mailto:Attila.Takacs@ericsson.com] > > Sent: Tuesday, December 02, 2008 1:52 PM > > To: Nitin Bahadur; Adrian Farrel; ccamp@ops.ietf.org > > Subject: RE: CCAMP drafts for adoption > >=20 > > Hi Nitin, > >=20 > > Please note that these mechanisms are proposed for GMPLS=20 > and as such=20 > > to provide support for any data plane technology specific OAM=20 > > mechanism. As you noted LSP Ping is for MPLS and BFD only. > >=20 > > Best regards, > > Attila > >=20 > > > -----Original Message----- > > > From: owner-ccamp@ops.ietf.org > > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Nitin Bahadur > > > Sent: Tuesday, December 02, 2008 10:35 PM > > > To: Adrian Farrel; ccamp@ops.ietf.org > > > Subject: RE: CCAMP drafts for adoption > > >=20 > > >=20 > > >=20 > > > > > draft-takacs-ccamp-oam-configuration-fwk-01.txt > > > > > draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt > > >=20 > > > Do not support either of these. > > >=20 > > > From the oam-config-fwk draft: > > > > A new useful application of RSVP-TE is OAM configuration > > > and control > > > > for transport networks. > > >=20 > > > LSP-ping was designed as an OAM mechansim for MPLS LSPs.=20 > Why do we=20 > > > need another mechanism? What are the limitations of lsp-ping that=20 > > > warrant this new mechanism? > > >=20 > > > > When RSVP-TE is used for LSP establishment it is desirable > > > to bind OAM > > > > setup to connection establishment signalling to avoid two > > separate > > > > management/configuration steps > > >=20 > > > draft-ietf-bfd-mpls specifies how to use LSP-Ping for > > automatic setup > > > of BFD-based OAM. > > > We should go along the same path for Ethernet OAM. > > >=20 > > > Thanks > > > Nitin > > >=20 > > >=20 > >=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 02 Dec 2008 22:09:56 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: CCAMP drafts for adoption Date: Tue, 2 Dec 2008 17:08:53 -0500 Message-ID: <87AC5F88F03E6249AEA68D40BD3E00BE168324A4@zcarhxm2.corp.nortel.com> Thread-Topic: CCAMP drafts for adoption Thread-Index: AclUl6mpWAW2o7P/QfKhDBZKhoe9CgABkY3AAAiyQSAAAP4GoAAApjZg From: "David Allan" To: "Nitin Bahadur" , "Adrian Farrel" , Hi Nitin: You wrote: > LSP-ping was designed as an OAM mechansim for MPLS LSPs. Why do we need another mechanism? What are the limitations of=20 > lsp-ping that warrant this new mechanism? We should go along the same path for Ethernet OAM. It is not applicable to either a PBB-TE switched path or, if you are of that persuasion, an MPLS-TP switched path...as it stands today. And it only goes downhill from there.... I would think the inappropriateness of applying LSP-PING to Ethernet OAM would be self evident...Ethernet OAM already has it's own LB/LT functionality so mandating another loopback exclusively for OAM configuration is gratuitously complex. As for MPLS-TP, LSP-PING would need recasting as a "non-IP" protocol to fit the mandated profile from the joint design team and likely would benefit from a trip to the fat farm to shed the other features it did not need within said profile... Dave Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 02 Dec 2008 22:05:25 +0000 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: CCAMP drafts for adoption Date: Tue, 2 Dec 2008 14:01:11 -0800 Message-ID: <7FA0C743C38E5340BFC2873488FA1E8E025DDF68@emailcorp3.jnpr.net> Thread-Topic: CCAMP drafts for adoption thread-index: AclUl6mpWAW2o7P/QfKhDBZKhoe9CgABkY3AAAiyQSAAAP4GoAAAuZwwAABaoIA= From: Nitin Bahadur To: "Attila Takacs" , "Adrian Farrel" , Hi Attlia, What is the limitation of lsp-ping that prevents it from being applied to GMPLS? If an existing mechanism can be applied, then why not? If lsp-ping needs extensions to support GMPLS LSPs, feel free to make/specify those extensions. Thanks Nitin =20 > -----Original Message----- > From: Attila Takacs [mailto:Attila.Takacs@ericsson.com]=20 > Sent: Tuesday, December 02, 2008 1:52 PM > To: Nitin Bahadur; Adrian Farrel; ccamp@ops.ietf.org > Subject: RE: CCAMP drafts for adoption >=20 > Hi Nitin, >=20 > Please note that these mechanisms are proposed for GMPLS and=20 > as such to provide support for any data plane technology=20 > specific OAM mechanism. As you noted LSP Ping is for MPLS and=20 > BFD only. =20 >=20 > Best regards, > Attila >=20 > > -----Original Message----- > > From: owner-ccamp@ops.ietf.org > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Nitin Bahadur > > Sent: Tuesday, December 02, 2008 10:35 PM > > To: Adrian Farrel; ccamp@ops.ietf.org > > Subject: RE: CCAMP drafts for adoption > >=20 > >=20 > >=20 > > > > draft-takacs-ccamp-oam-configuration-fwk-01.txt > > > > draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt > >=20 > > Do not support either of these. > >=20 > > From the oam-config-fwk draft: > > > A new useful application of RSVP-TE is OAM configuration > > and control > > > for transport networks. > >=20 > > LSP-ping was designed as an OAM mechansim for MPLS LSPs. Why do we=20 > > need another mechanism? What are the limitations of lsp-ping that=20 > > warrant this new mechanism? > >=20 > > > When RSVP-TE is used for LSP establishment it is desirable > > to bind OAM > > > setup to connection establishment signalling to avoid two=20 > separate=20 > > > management/configuration steps > >=20 > > draft-ietf-bfd-mpls specifies how to use LSP-Ping for=20 > automatic setup=20 > > of BFD-based OAM. > > We should go along the same path for Ethernet OAM. > >=20 > > Thanks > > Nitin > >=20 > >=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 02 Dec 2008 21:52:58 +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: CCAMP drafts for adoption Date: Tue, 2 Dec 2008 22:51:49 +0100 Message-ID: <53CCFDD6E346CB43994852666C210E9105B70D91@esealmw116.eemea.ericsson.se> Thread-Topic: CCAMP drafts for adoption thread-index: AclUl6mpWAW2o7P/QfKhDBZKhoe9CgABkY3AAAiyQSAAAP4GoAAAuZww From: "Attila Takacs" To: "Nitin Bahadur" , "Adrian Farrel" , Hi Nitin, Please note that these mechanisms are proposed for GMPLS and as such to provide support for any data plane technology specific OAM mechanism. As you noted LSP Ping is for MPLS and BFD only. =20 Best regards, Attila > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Nitin Bahadur > Sent: Tuesday, December 02, 2008 10:35 PM > To: Adrian Farrel; ccamp@ops.ietf.org > Subject: RE: CCAMP drafts for adoption >=20 >=20 >=20 > > > draft-takacs-ccamp-oam-configuration-fwk-01.txt > > > draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt >=20 > Do not support either of these. >=20 > From the oam-config-fwk draft: > > A new useful application of RSVP-TE is OAM configuration=20 > and control=20 > > for transport networks. >=20 > LSP-ping was designed as an OAM mechansim for MPLS LSPs. Why=20 > do we need another mechanism? What are the limitations of=20 > lsp-ping that warrant this new mechanism? >=20 > > When RSVP-TE is used for LSP establishment it is desirable=20 > to bind OAM=20 > > setup to connection establishment signalling to avoid two separate=20 > > management/configuration steps >=20 > draft-ietf-bfd-mpls specifies how to use LSP-Ping for=20 > automatic setup of BFD-based OAM. > We should go along the same path for Ethernet OAM. >=20 > Thanks > Nitin >=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 02 Dec 2008 21:49:40 +0000 User-Agent: Microsoft-Entourage/12.14.0.081024 Date: Tue, 02 Dec 2008 16:49:15 -0500 Subject: Re: CCAMP drafts for adoption From: "Thomas D. Nadeau" To: Nitin Bahadur , Adrian Farrel , Message-ID: Thread-Topic: CCAMP drafts for adoption Thread-Index: AclUl6mpWAW2o7P/QfKhDBZKhoe9CgABkY3AAAiyQSAAAP4GoAAAyC2E Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit I agree with Nitin and do not support the adoption of these drafts. --Tom On 12/2/08 4:35 PM, "Nitin Bahadur" wrote: >>> draft-takacs-ccamp-oam-configuration-fwk-01.txt >>> draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt > > Do not support either of these. > > From the oam-config-fwk draft: >> A new useful application of RSVP-TE is OAM configuration >> and control for transport networks. > > LSP-ping was designed as an OAM mechansim for MPLS LSPs. Why do we need > another mechanism? What are the limitations of lsp-ping that warrant > this new mechanism? > >> When RSVP-TE is used for LSP establishment it is desirable to bind >> OAM setup to connection establishment signalling to avoid two >> separate management/configuration steps > > draft-ietf-bfd-mpls specifies how to use LSP-Ping for automatic setup of > BFD-based OAM. > We should go along the same path for Ethernet OAM. > > Thanks > Nitin > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 02 Dec 2008 21:49:29 +0000 Message-ID: <200812022145.mB2LjpM29157@magenta.juniper.net> To: "Adrian Farrel" CC: ccamp@ops.ietf.org Subject: Re: CCAMP drafts for adoption MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <67307.1228254351.1@juniper.net> Date: Tue, 2 Dec 2008 13:45:51 -0800 From: Yakov Rekhter Adrian, > Hi, > > Can you please express your opinion on the adoption of the following > three drafts as WG drafts. > > Thanks, > Adrian > > draft-takacs-ccamp-oam-configuration-fwk-01.txt > draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt I am opposed accepting these drafts as WG drafts. Yakov. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 02 Dec 2008 21:38: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: RE: CCAMP drafts for adoption Date: Tue, 2 Dec 2008 13:35:19 -0800 Message-ID: <7FA0C743C38E5340BFC2873488FA1E8E025DDF5E@emailcorp3.jnpr.net> Thread-Topic: CCAMP drafts for adoption thread-index: AclUl6mpWAW2o7P/QfKhDBZKhoe9CgABkY3AAAiyQSAAAP4GoA== From: Nitin Bahadur To: "Adrian Farrel" , > > draft-takacs-ccamp-oam-configuration-fwk-01.txt > > draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt Do not support either of these. >From the oam-config-fwk draft: > A new useful application of RSVP-TE is OAM configuration > and control for transport networks. LSP-ping was designed as an OAM mechansim for MPLS LSPs. Why do we need another mechanism? What are the limitations of lsp-ping that warrant this new mechanism? > When RSVP-TE is used for LSP establishment it is desirable to bind > OAM setup to connection establishment signalling to avoid two > separate management/configuration steps draft-ietf-bfd-mpls specifies how to use LSP-Ping for automatic setup of BFD-based OAM. We should go along the same path for Ethernet OAM. Thanks Nitin Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 02 Dec 2008 21:00:32 +0000 Date: Tue, 02 Dec 2008 14:59:07 -0600 From: Lucy Yong Subject: RE: CCAMP drafts for adoption To: ccamp@ops.ietf.org Message-id: <001601c954c0$d165bf10$470c7c0a@china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AclUl6mpWAW2o7P/QfKhDBZKhoe9CgABkY3AAAiyQSA= Support all to become WG documents. Cheer, Lucy > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf > Of Young Lee > Sent: Tuesday, December 02, 2008 10:58 AM > To: 'Adrian Farrel'; ccamp@ops.ietf.org > Subject: RE: CCAMP drafts for adoption > > Support for all. > > Young (I'm co-author of wson-encode) > > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf > Of Adrian Farrel > Sent: Tuesday, December 02, 2008 10:02 AM > To: ccamp@ops.ietf.org > Subject: CCAMP drafts for adoption > > Hi, > > Can you please express your opinion on the adoption of the following three > drafts as WG drafts. > > Thanks, > Adrian > > draft-takacs-ccamp-oam-configuration-fwk-01.txt > draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt > draft-bernstein-ccamp-wson-encode-01.txt (to become -rwa-encode-00) > > Cheers, > Adrian and Deborah > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 02 Dec 2008 18:41:42 +0000 Message-ID: <4935814F.4060705@grotto-networking.com> Date: Tue, 02 Dec 2008 10:41:19 -0800 From: Greg Bernstein User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: hhelvoort@chello.nl CC: Jishnu A , "'ccamp'" Subject: Re: [BULK] VCAT/LCAS draft update... Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi folks, the differential delay compensation capability is a property of VCAT (not LCAS) hence independent of whether LCAS is implemented or not. In SDH the MFI is used with VCAT (part of the H4 byte). This issue has come up before. And at the time it seemed to belong with some the MLN work that kept track of "adaptation" properties. Right now it seems that differential delay compensation limits would need to be handled by network planning rather than the control plane. Regards Greg Huub van Helvoort wrote: > Hi Jishnu, > > you replied: > >> Adding to Hubb's reply below >> The MFI field in LCAS allows support upto a maximum of 256ms >> differential >> delay compensation for HO VC. But the exact value is completely >> depending on >> the vendor implementation and can be anything between 125us to 256ms. > > This is information that is well known. > > Reading your initial email again I am confused by the > additional reponse. > > Can you please inform us of what the issue is that you > would like to resolve. > And make a distinction between the two modes: > == VCAT without LCAS > == VCAT with LCAS. > > Thank you, Huub. > >> -----Original Message----- >> From: Huub van Helvoort [mailto:hhelvoort@chello.nl] Sent: Tuesday, >> December 02, 2008 9:34 PM >> To: BRUNGARD, DEBORAH A, ATTLABS >> Cc: Jishnu A; Greg Bernstein; ccamp >> Subject: Re: [BULK] VCAT/LCAS draft update... >> Importance: Low >> >> Hi Deborah, >> >> You replied: >> >>> Shouldn't be a problem if the data plane is based on ITU - so it would >>> need to support (at minimum) ITU's G.707 minimum differential delay >>> requirements for VCAT. >> >> Minimum delay in G.707 is 125 usec (micro-seconds)... >> >> Maximum differential delay depends on implementation. >> Differential is the difference between the largest >> propagation delay of one of the members and the >> smallest propagation delay of one of the members. >> The sink VCAT/LCAS function is capable of detecting >> and reporting whether one or more members does not fit >> the differential delay capability. >> >> Cheers, Huub. >> >>> -----Original Message----- >>> From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On >>> Behalf Of Jishnu A >>> Sent: Tuesday, December 02, 2008 10:03 AM >>> To: 'Greg Bernstein' >>> Cc: 'ccamp' >>> Subject: RE: [BULK] VCAT/LCAS draft update... >>> >>> Dear Greg, >>> One additional problem with VCAT/LCAS is the amount of differential >>> delay >>> supported at the destination node. Can it be mentioned as a note that >>> co-routing or diversely routing is also based on the availability of >>> enough >>> sufficient differential delay buffer size at the destination node? >>> Regards, >>> Jishnu A >>> >>> -----Original Message----- >>> From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On >>> Behalf >>> Of Greg Bernstein >>> Sent: Wednesday, November 19, 2008 12:07 AM >>> To: ccamp >>> Subject: [BULK] VCAT/LCAS draft update... >>> Importance: Low >>> >>> Hi folks, I edited the VCAT/LCAS draft to use the CALL_ATTRIBUTES >>> object >>> >>> from the MLN extensions draft. >>> We define a new VCAT TLV for use in the aforementioned object. All >>> procedures and encodings otherwise are the same as the previous >>> draft. Note that the draft will now be contingent on the MLN >>> extensions draft moving forward. >>> >>> A URL for the Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-vcat-lcas-06. >>> >>> txt >>> >>> >>> Regards >>> >>> Greg >>> >> > -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 02 Dec 2008 18:38:43 +0000 From: "Jishnu A" To: Cc: "'Greg Bernstein'" , "'ccamp'" Subject: RE: [BULK] VCAT/LCAS draft update... Date: Wed, 3 Dec 2008 00:06:48 +0530 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-index: AclUo+XiR/6yjP3UQMm+L1afQAP0JQAB0LKg Dear Hubb, As there is a note on Fixed co-routed about this being needed to minimize the differential delay, same could be added for Dynamic, co-routed also. "Dynamic, co-routed: A dynamic VCG (bandwidth can be increased or decreased via the addition or removal of member signals), transported over a co-routed set of members. The intent here is dynamic resizing and resilience of bandwidth at the same time minimizing the differential delay." Is it left out as it is obvious? Also the document does not mention why one needs to minimize the differential delay. Again, is it assumed that this is well known and left out? Regards, Jishnu A -----Original Message----- From: Huub van Helvoort [mailto:hhelvoort@chello.nl] Sent: Tuesday, December 02, 2008 11:02 PM To: Jishnu A Cc: 'Greg Bernstein'; 'ccamp' Subject: Re: [BULK] VCAT/LCAS draft update... Importance: Low Hi Jishnu, you replied: > Adding to Hubb's reply below > The MFI field in LCAS allows support upto a maximum of 256ms differential > delay compensation for HO VC. But the exact value is completely depending on > the vendor implementation and can be anything between 125us to 256ms. This is information that is well known. Reading your initial email again I am confused by the additional reponse. Can you please inform us of what the issue is that you would like to resolve. And make a distinction between the two modes: == VCAT without LCAS == VCAT with LCAS. Thank you, Huub. > -----Original Message----- > From: Huub van Helvoort [mailto:hhelvoort@chello.nl] > Sent: Tuesday, December 02, 2008 9:34 PM > To: BRUNGARD, DEBORAH A, ATTLABS > Cc: Jishnu A; Greg Bernstein; ccamp > Subject: Re: [BULK] VCAT/LCAS draft update... > Importance: Low > > Hi Deborah, > > You replied: > >> Shouldn't be a problem if the data plane is based on ITU - so it would >> need to support (at minimum) ITU's G.707 minimum differential delay >> requirements for VCAT. > > Minimum delay in G.707 is 125 usec (micro-seconds)... > > Maximum differential delay depends on implementation. > Differential is the difference between the largest > propagation delay of one of the members and the > smallest propagation delay of one of the members. > The sink VCAT/LCAS function is capable of detecting > and reporting whether one or more members does not fit > the differential delay capability. > > Cheers, Huub. > >> -----Original Message----- >> From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On >> Behalf Of Jishnu A >> Sent: Tuesday, December 02, 2008 10:03 AM >> To: 'Greg Bernstein' >> Cc: 'ccamp' >> Subject: RE: [BULK] VCAT/LCAS draft update... >> >> Dear Greg, >> One additional problem with VCAT/LCAS is the amount of differential >> delay >> supported at the destination node. Can it be mentioned as a note that >> co-routing or diversely routing is also based on the availability of >> enough >> sufficient differential delay buffer size at the destination node? >> >> Regards, >> Jishnu A >> >> -----Original Message----- >> From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On >> Behalf >> Of Greg Bernstein >> Sent: Wednesday, November 19, 2008 12:07 AM >> To: ccamp >> Subject: [BULK] VCAT/LCAS draft update... >> Importance: Low >> >> Hi folks, I edited the VCAT/LCAS draft to use the CALL_ATTRIBUTES object >> >> from the MLN extensions draft. >> We define a new VCAT TLV for use in the aforementioned object. All >> procedures and encodings otherwise are the same as the previous draft. >> Note that the draft will now be contingent on the MLN extensions draft >> moving forward. >> >> A URL for the Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-vcat-lcas-06. >> txt >> >> >> Regards >> >> Greg >> > -- ================================================================ http://www.van-helvoort.eu/ ================================================================ Always remember that you are unique...just like everyone else... __________ Information from ESET NOD32 Antivirus, version of virus signature database 3658 (20081202) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __________ Information from ESET NOD32 Antivirus, version of virus signature database 3658 (20081202) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 02 Dec 2008 17:33:28 +0000 Message-ID: <49357118.7020709@chello.nl> Date: Tue, 02 Dec 2008 18:32:08 +0100 From: Huub van Helvoort Reply-To: hhelvoort@chello.nl User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: Jishnu A CC: "'Greg Bernstein'" , "'ccamp'" Subject: Re: [BULK] VCAT/LCAS draft update... Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Jishnu, you replied: > Adding to Hubb's reply below > The MFI field in LCAS allows support upto a maximum of 256ms differential > delay compensation for HO VC. But the exact value is completely depending on > the vendor implementation and can be anything between 125us to 256ms. This is information that is well known. Reading your initial email again I am confused by the additional reponse. Can you please inform us of what the issue is that you would like to resolve. And make a distinction between the two modes: == VCAT without LCAS == VCAT with LCAS. Thank you, Huub. > -----Original Message----- > From: Huub van Helvoort [mailto:hhelvoort@chello.nl] > Sent: Tuesday, December 02, 2008 9:34 PM > To: BRUNGARD, DEBORAH A, ATTLABS > Cc: Jishnu A; Greg Bernstein; ccamp > Subject: Re: [BULK] VCAT/LCAS draft update... > Importance: Low > > Hi Deborah, > > You replied: > >> Shouldn't be a problem if the data plane is based on ITU - so it would >> need to support (at minimum) ITU's G.707 minimum differential delay >> requirements for VCAT. > > Minimum delay in G.707 is 125 usec (micro-seconds)... > > Maximum differential delay depends on implementation. > Differential is the difference between the largest > propagation delay of one of the members and the > smallest propagation delay of one of the members. > The sink VCAT/LCAS function is capable of detecting > and reporting whether one or more members does not fit > the differential delay capability. > > Cheers, Huub. > >> -----Original Message----- >> From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On >> Behalf Of Jishnu A >> Sent: Tuesday, December 02, 2008 10:03 AM >> To: 'Greg Bernstein' >> Cc: 'ccamp' >> Subject: RE: [BULK] VCAT/LCAS draft update... >> >> Dear Greg, >> One additional problem with VCAT/LCAS is the amount of differential >> delay >> supported at the destination node. Can it be mentioned as a note that >> co-routing or diversely routing is also based on the availability of >> enough >> sufficient differential delay buffer size at the destination node? >> >> Regards, >> Jishnu A >> >> -----Original Message----- >> From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On >> Behalf >> Of Greg Bernstein >> Sent: Wednesday, November 19, 2008 12:07 AM >> To: ccamp >> Subject: [BULK] VCAT/LCAS draft update... >> Importance: Low >> >> Hi folks, I edited the VCAT/LCAS draft to use the CALL_ATTRIBUTES object >> >> from the MLN extensions draft. >> We define a new VCAT TLV for use in the aforementioned object. All >> procedures and encodings otherwise are the same as the previous draft. >> Note that the draft will now be contingent on the MLN extensions draft >> moving forward. >> >> A URL for the Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-vcat-lcas-06. >> txt >> >> >> Regards >> >> Greg >> > -- ================================================================ http://www.van-helvoort.eu/ ================================================================ Always remember that you are unique...just like everyone else... Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 02 Dec 2008 16:58:55 +0000 Date: Tue, 02 Dec 2008 10:58:15 -0600 From: Young Lee Subject: RE: CCAMP drafts for adoption To: 'Adrian Farrel' , ccamp@ops.ietf.org Message-id: <001201c9549f$2dac4e50$d626fea9@china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Thread-index: AclUl6mpWAW2o7P/QfKhDBZKhoe9CgABkY3A Support for all. Young (I'm co-author of wson-encode) -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel Sent: Tuesday, December 02, 2008 10:02 AM To: ccamp@ops.ietf.org Subject: CCAMP drafts for adoption Hi, Can you please express your opinion on the adoption of the following three drafts as WG drafts. Thanks, Adrian draft-takacs-ccamp-oam-configuration-fwk-01.txt draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt draft-bernstein-ccamp-wson-encode-01.txt (to become -rwa-encode-00) Cheers, Adrian and Deborah Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 02 Dec 2008 16:52:52 +0000 Message-ID: <4935679C.1030201@grotto-networking.com> Date: Tue, 02 Dec 2008 08:51:40 -0800 From: Greg Bernstein User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Adrian Farrel CC: ccamp@ops.ietf.org Subject: Re: CCAMP drafts for adoption Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Support wson-encode. Yes, I'm a co-author... Greg Adrian Farrel wrote: > Hi, > > Can you please express your opinion on the adoption of the following > three drafts as WG drafts. > > Thanks, > Adrian > > draft-takacs-ccamp-oam-configuration-fwk-01.txt > draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt > draft-bernstein-ccamp-wson-encode-01.txt (to become -rwa-encode-00) > > Cheers, > Adrian and Deborah > > > -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 02 Dec 2008 16:48:03 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: CCAMP drafts for adoption Date: Tue, 2 Dec 2008 10:47:41 -0600 Message-ID: Thread-Topic: CCAMP drafts for adoption Thread-Index: AclUl9x1bFCf9+tlQ5yJ7vl0/FoH+wABXFFA From: "Howard Green" To: "Adrian Farrel" , Yes to all three. Howard -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel Sent: Tuesday, December 02, 2008 8:02 AM To: ccamp@ops.ietf.org Subject: CCAMP drafts for adoption Hi, Can you please express your opinion on the adoption of the following three drafts as WG drafts. Thanks, Adrian draft-takacs-ccamp-oam-configuration-fwk-01.txt draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt draft-bernstein-ccamp-wson-encode-01.txt (to become -rwa-encode-00) Cheers, Adrian and Deborah=20 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 02 Dec 2008 16:46:04 +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: CCAMP drafts for adoption Date: Tue, 2 Dec 2008 17:44:17 +0100 Message-ID: <0428AC48A879ED46A94F39D5665DF684021E0C2E@esealmw110.eemea.ericsson.se> Thread-Topic: CCAMP drafts for adoption Thread-Index: AclUl89qKcq7JtMySGqkaJgwx7j8RwABWK5w From: "Diego Caviglia" To: "Adrian Farrel" , Yes to all. BR Diego > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On = Behalf > Of Adrian Farrel > Sent: marted=EC 2 dicembre 2008 17.02 > To: ccamp@ops.ietf.org > Subject: CCAMP drafts for adoption >=20 > Hi, >=20 > Can you please express your opinion on the adoption of the following = three > drafts as WG drafts. >=20 > Thanks, > Adrian >=20 > draft-takacs-ccamp-oam-configuration-fwk-01.txt > draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt > draft-bernstein-ccamp-wson-encode-01.txt (to become -rwa-encode-00) >=20 > Cheers, > Adrian and Deborah >=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 02 Dec 2008 16:39:52 +0000 From: =?iso-8859-1?Q?Jonas_M=E5rtensson?= To: Adrian Farrel , "ccamp@ops.ietf.org" Date: Tue, 2 Dec 2008 17:39:17 +0100 Subject: RE: CCAMP drafts for adoption Thread-Topic: CCAMP drafts for adoption Thread-Index: AclUmEwhRI0kNFCISLuCBtlvS1LnPgABAVmw Message-ID: <1EC35EEAF3A9FA439C7D6AE45BF43787DB083005A8@acreoexc01.ad.acreo.se> Accept-Language: en-US Content-Language: en-US acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Hi, I support wson-encode. Regards, Jonas > -----Original Message----- > From: owner-ccamp@ops.ietf.org > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel > Sent: den 2 december 2008 17:02 > To: ccamp@ops.ietf.org > Subject: CCAMP drafts for adoption > > Hi, > > Can you please express your opinion on the adoption of the > following three drafts as WG drafts. > > Thanks, > Adrian > > draft-takacs-ccamp-oam-configuration-fwk-01.txt > draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt > draft-bernstein-ccamp-wson-encode-01.txt (to become -rwa-encode-00) > > Cheers, > Adrian and Deborah > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 02 Dec 2008 16:36:01 +0000 Message-ID: <4E1CBFB4740C4D4FA530A1F84FE537D6@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "'ccamp'" Subject: Re: VCAT/LCAS draft update... Date: Tue, 2 Dec 2008 16:35:30 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Questions: Is this something that anyone would ever do without LCAS? Are there information elements we need to exchange before LSPs are set up (i.e. on the Call)? How much of this is dependent on measurements once LSPs are set up, rather than before they are set up? Thanks, Adrian ----- Original Message ----- From: "Jishnu A" To: ; "'BRUNGARD, DEBORAH A, ATTLABS'" Cc: "'Greg Bernstein'" ; "'ccamp'" Sent: Tuesday, December 02, 2008 4:28 PM Subject: RE: [BULK] VCAT/LCAS draft update... > Adding to Hubb's reply below > The MFI field in LCAS allows support upto a maximum of 256ms differential > delay compensation for HO VC. But the exact value is completely depending > on > the vendor implementation and can be anything between 125us to 256ms. > Regards, > Jishnu A > > -----Original Message----- > From: Huub van Helvoort [mailto:hhelvoort@chello.nl] > Sent: Tuesday, December 02, 2008 9:34 PM > To: BRUNGARD, DEBORAH A, ATTLABS > Cc: Jishnu A; Greg Bernstein; ccamp > Subject: Re: [BULK] VCAT/LCAS draft update... > Importance: Low > > Hi Deborah, > > You replied: > >> Shouldn't be a problem if the data plane is based on ITU - so it would >> need to support (at minimum) ITU's G.707 minimum differential delay >> requirements for VCAT. > > Minimum delay in G.707 is 125 usec (micro-seconds)... > > Maximum differential delay depends on implementation. > Differential is the difference between the largest > propagation delay of one of the members and the > smallest propagation delay of one of the members. > The sink VCAT/LCAS function is capable of detecting > and reporting whether one or more members does not fit > the differential delay capability. > > Cheers, Huub. > >> -----Original Message----- >> From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On >> Behalf Of Jishnu A >> Sent: Tuesday, December 02, 2008 10:03 AM >> To: 'Greg Bernstein' >> Cc: 'ccamp' >> Subject: RE: [BULK] VCAT/LCAS draft update... >> >> Dear Greg, >> One additional problem with VCAT/LCAS is the amount of differential >> delay >> supported at the destination node. Can it be mentioned as a note that >> co-routing or diversely routing is also based on the availability of >> enough >> sufficient differential delay buffer size at the destination node? >> >> Regards, >> Jishnu A >> >> -----Original Message----- >> From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On >> Behalf >> Of Greg Bernstein >> Sent: Wednesday, November 19, 2008 12:07 AM >> To: ccamp >> Subject: [BULK] VCAT/LCAS draft update... >> Importance: Low >> >> Hi folks, I edited the VCAT/LCAS draft to use the CALL_ATTRIBUTES object >> >> from the MLN extensions draft. >> We define a new VCAT TLV for use in the aforementioned object. All >> procedures and encodings otherwise are the same as the previous draft. >> Note that the draft will now be contingent on the MLN extensions draft >> moving forward. >> >> A URL for the Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-vcat-lcas-06. >> txt >> >> >> Regards >> >> Greg >> > > -- > ================================================================ > http://www.van-helvoort.eu/ > ================================================================ > Always remember that you are unique...just like everyone else... > > > __________ Information from ESET NOD32 Antivirus, version of virus > signature > database 3658 (20081202) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > > > > __________ Information from ESET NOD32 Antivirus, version of virus > signature > database 3658 (20081202) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 02 Dec 2008 16:29:28 +0000 From: "Jishnu A" To: , "'BRUNGARD, DEBORAH A, ATTLABS'" Cc: "'Greg Bernstein'" , "'ccamp'" Subject: RE: [BULK] VCAT/LCAS draft update... Date: Tue, 2 Dec 2008 21:58:34 +0530 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AclUl5mR37OxKWhbQ0KerxW797yJpgAAwJYg Adding to Hubb's reply below The MFI field in LCAS allows support upto a maximum of 256ms differential delay compensation for HO VC. But the exact value is completely depending on the vendor implementation and can be anything between 125us to 256ms. Regards, Jishnu A -----Original Message----- From: Huub van Helvoort [mailto:hhelvoort@chello.nl] Sent: Tuesday, December 02, 2008 9:34 PM To: BRUNGARD, DEBORAH A, ATTLABS Cc: Jishnu A; Greg Bernstein; ccamp Subject: Re: [BULK] VCAT/LCAS draft update... Importance: Low Hi Deborah, You replied: > Shouldn't be a problem if the data plane is based on ITU - so it would > need to support (at minimum) ITU's G.707 minimum differential delay > requirements for VCAT. Minimum delay in G.707 is 125 usec (micro-seconds)... Maximum differential delay depends on implementation. Differential is the difference between the largest propagation delay of one of the members and the smallest propagation delay of one of the members. The sink VCAT/LCAS function is capable of detecting and reporting whether one or more members does not fit the differential delay capability. Cheers, Huub. > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On > Behalf Of Jishnu A > Sent: Tuesday, December 02, 2008 10:03 AM > To: 'Greg Bernstein' > Cc: 'ccamp' > Subject: RE: [BULK] VCAT/LCAS draft update... > > Dear Greg, > One additional problem with VCAT/LCAS is the amount of differential > delay > supported at the destination node. Can it be mentioned as a note that > co-routing or diversely routing is also based on the availability of > enough > sufficient differential delay buffer size at the destination node? > > Regards, > Jishnu A > > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On > Behalf > Of Greg Bernstein > Sent: Wednesday, November 19, 2008 12:07 AM > To: ccamp > Subject: [BULK] VCAT/LCAS draft update... > Importance: Low > > Hi folks, I edited the VCAT/LCAS draft to use the CALL_ATTRIBUTES object > > from the MLN extensions draft. > We define a new VCAT TLV for use in the aforementioned object. All > procedures and encodings otherwise are the same as the previous draft. > Note that the draft will now be contingent on the MLN extensions draft > moving forward. > > A URL for the Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-vcat-lcas-06. > txt > > > Regards > > Greg > -- ================================================================ http://www.van-helvoort.eu/ ================================================================ Always remember that you are unique...just like everyone else... __________ Information from ESET NOD32 Antivirus, version of virus signature database 3658 (20081202) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __________ Information from ESET NOD32 Antivirus, version of virus signature database 3658 (20081202) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 02 Dec 2008 16:23:05 +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: CCAMP drafts for adoption Date: Tue, 2 Dec 2008 11:22:20 -0500 Message-ID: <87AC5F88F03E6249AEA68D40BD3E00BE1683249C@zcarhxm2.corp.nortel.com> Thread-Topic: CCAMP drafts for adoption Thread-Index: AclUmA/eD/0mh5J7SOi83MWHhH1JMwAAerzA From: "David Allan" To: "Adrian Farrel" , Hi Adrian: Support oam-conf Support oam-ext Abstain wson-encode Cheers Dave=20 -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel Sent: Tuesday, December 02, 2008 11:02 AM To: ccamp@ops.ietf.org Subject: CCAMP drafts for adoption Hi, Can you please express your opinion on the adoption of the following three drafts as WG drafts. Thanks, Adrian draft-takacs-ccamp-oam-configuration-fwk-01.txt draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt draft-bernstein-ccamp-wson-encode-01.txt (to become -rwa-encode-00) Cheers, Adrian and Deborah=20 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 02 Dec 2008 16:16:34 +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: [BULK] VCAT/LCAS draft update... Date: Tue, 2 Dec 2008 17:15:28 +0100 Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB026060DE939@ftrdmel2> Thread-Topic: [BULK] VCAT/LCAS draft update... Thread-index: AclUmEaWvfWTGkpbTNGTjpussHebnQAAD9Jw From: To: , Cc: , , Hi all. I would even add that the diversely routing scenario is not different in = GMPLS from configuration-based provisioning: from the data plane point = of view, nothing is new. Regards, Julien -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On = Behalf Of Huub van Helvoort Hi Deborah, You replied: > Shouldn't be a problem if the data plane is based on ITU - so it would > need to support (at minimum) ITU's G.707 minimum differential delay > requirements for VCAT. Minimum delay in G.707 is 125 usec (micro-seconds)... Maximum differential delay depends on implementation. Differential is the difference between the largest propagation delay of one of the members and the smallest propagation delay of one of the members. The sink VCAT/LCAS function is capable of detecting and reporting whether one or more members does not fit the differential delay capability. Cheers, Huub. > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On >=20 > Dear Greg, > One additional problem with VCAT/LCAS is the amount of differential > delay > supported at the destination node. Can it be mentioned as a note that > co-routing or diversely routing is also based on the availability of > enough > sufficient differential delay buffer size at the destination node?=20 >=20 > Regards, > Jishnu A >=20 > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On > Behalf > Of Greg Bernstein > Sent: Wednesday, November 19, 2008 12:07 AM > To: ccamp > Subject: [BULK] VCAT/LCAS draft update... > Importance: Low >=20 > Hi folks, I edited the VCAT/LCAS draft to use the CALL_ATTRIBUTES = object >=20 > from the MLN extensions draft. > We define a new VCAT TLV for use in the aforementioned object. All=20 > procedures and encodings otherwise are the same as the previous draft. = > Note that the draft will now be contingent on the MLN extensions draft = > moving forward. >=20 > A URL for the Internet-Draft is: > = http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-vcat-lcas-06. > txt >=20 >=20 > Regards >=20 > Greg >=20 --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D http://www.van-helvoort.eu/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Always remember that you are unique...just like everyone else... Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 02 Dec 2008 16:04:52 +0000 Message-ID: <49355C72.2070407@chello.nl> Date: Tue, 02 Dec 2008 17:04:02 +0100 From: Huub van Helvoort Reply-To: hhelvoort@chello.nl User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: "BRUNGARD, DEBORAH A, ATTLABS" CC: Jishnu A , Greg Bernstein , ccamp Subject: Re: [BULK] VCAT/LCAS draft update... Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Deborah, You replied: > Shouldn't be a problem if the data plane is based on ITU - so it would > need to support (at minimum) ITU's G.707 minimum differential delay > requirements for VCAT. Minimum delay in G.707 is 125 usec (micro-seconds)... Maximum differential delay depends on implementation. Differential is the difference between the largest propagation delay of one of the members and the smallest propagation delay of one of the members. The sink VCAT/LCAS function is capable of detecting and reporting whether one or more members does not fit the differential delay capability. Cheers, Huub. > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On > Behalf Of Jishnu A > Sent: Tuesday, December 02, 2008 10:03 AM > To: 'Greg Bernstein' > Cc: 'ccamp' > Subject: RE: [BULK] VCAT/LCAS draft update... > > Dear Greg, > One additional problem with VCAT/LCAS is the amount of differential > delay > supported at the destination node. Can it be mentioned as a note that > co-routing or diversely routing is also based on the availability of > enough > sufficient differential delay buffer size at the destination node? > > Regards, > Jishnu A > > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On > Behalf > Of Greg Bernstein > Sent: Wednesday, November 19, 2008 12:07 AM > To: ccamp > Subject: [BULK] VCAT/LCAS draft update... > Importance: Low > > Hi folks, I edited the VCAT/LCAS draft to use the CALL_ATTRIBUTES object > > from the MLN extensions draft. > We define a new VCAT TLV for use in the aforementioned object. All > procedures and encodings otherwise are the same as the previous draft. > Note that the draft will now be contingent on the MLN extensions draft > moving forward. > > A URL for the Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-vcat-lcas-06. > txt > > > Regards > > Greg > -- ================================================================ http://www.van-helvoort.eu/ ================================================================ Always remember that you are unique...just like everyone else... Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 02 Dec 2008 16:02:30 +0000 Message-ID: <2089B64D43144AEEA390F5C4C7232087@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: CCAMP drafts for adoption Date: Tue, 2 Dec 2008 16:01:48 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Hi, Can you please express your opinion on the adoption of the following three drafts as WG drafts. Thanks, Adrian draft-takacs-ccamp-oam-configuration-fwk-01.txt draft-takacs-ccamp-rsvp-te-eth-oam-ext-03.txt draft-bernstein-ccamp-wson-encode-01.txt (to become -rwa-encode-00) Cheers, Adrian and Deborah Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 02 Dec 2008 15:49:41 +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: [BULK] VCAT/LCAS draft update... Date: Tue, 2 Dec 2008 10:48:50 -0500 Message-ID: Thread-Topic: [BULK] VCAT/LCAS draft update... Thread-Index: AclJrPDNcWgth2kzTzadPlFRiy1ovgK4KNJQAAGrAUA= From: "BRUNGARD, DEBORAH A, ATTLABS" To: "Jishnu A" , "Greg Bernstein" Cc: "ccamp" Shouldn't be a problem if the data plane is based on ITU - so it would need to support (at minimum) ITU's G.707 minimum differential delay requirements for VCAT. Deborah -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Jishnu A Sent: Tuesday, December 02, 2008 10:03 AM To: 'Greg Bernstein' Cc: 'ccamp' Subject: RE: [BULK] VCAT/LCAS draft update... Dear Greg, One additional problem with VCAT/LCAS is the amount of differential delay supported at the destination node. Can it be mentioned as a note that co-routing or diversely routing is also based on the availability of enough sufficient differential delay buffer size at the destination node?=20 Regards, Jishnu A -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Greg Bernstein Sent: Wednesday, November 19, 2008 12:07 AM To: ccamp Subject: [BULK] VCAT/LCAS draft update... Importance: Low Hi folks, I edited the VCAT/LCAS draft to use the CALL_ATTRIBUTES object from the MLN extensions draft. We define a new VCAT TLV for use in the aforementioned object. All=20 procedures and encodings otherwise are the same as the previous draft.=20 Note that the draft will now be contingent on the MLN extensions draft=20 moving forward. A URL for the Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-vcat-lcas-06. txt Regards Greg --=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 __________ Information from ESET NOD32 Antivirus, version of virus signature database 3623 (20081118) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com =20 =20 __________ Information from ESET NOD32 Antivirus, version of virus signature database 3658 (20081202) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com =20 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 02 Dec 2008 15:05:52 +0000 From: "Jishnu A" To: "'Greg Bernstein'" Cc: "'ccamp'" Subject: RE: [BULK] VCAT/LCAS draft update... Date: Tue, 2 Dec 2008 20:33:11 +0530 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AclJrPDNcWgth2kzTzadPlFRiy1ovgK4KNJQ Dear Greg, One additional problem with VCAT/LCAS is the amount of differential delay supported at the destination node. Can it be mentioned as a note that co-routing or diversely routing is also based on the availability of enough sufficient differential delay buffer size at the destination node? Regards, Jishnu A -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Greg Bernstein Sent: Wednesday, November 19, 2008 12:07 AM To: ccamp Subject: [BULK] VCAT/LCAS draft update... Importance: Low Hi folks, I edited the VCAT/LCAS draft to use the CALL_ATTRIBUTES object from the MLN extensions draft. We define a new VCAT TLV for use in the aforementioned object. All procedures and encodings otherwise are the same as the previous draft. Note that the draft will now be contingent on the MLN extensions draft moving forward. A URL for the Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-vcat-lcas-06.txt Regards Greg -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 __________ Information from ESET NOD32 Antivirus, version of virus signature database 3623 (20081118) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __________ Information from ESET NOD32 Antivirus, version of virus signature database 3658 (20081202) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com