From LorenaofficiousMelvin@mnnonline.org Tue Jan 01 11:17:33 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J9jo4-0007J0-Ue; Tue, 01 Jan 2008 11:17:32 -0500 Received: from ppp-58.9.82.220.revip2.asianet.co.th ([58.9.82.220] helo=com4) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J9jo4-0007Xu-29; Tue, 01 Jan 2008 11:17:32 -0500 Received: from immediate by mnnonline.org with SMTP id uyxdlTY8E2 for ; Tue, 1 Jan 2008 23:17:08 -0700 From: "Delia Blackmon" To: , Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J9nfI-0006TG-N6; Tue, 01 Jan 2008 15:24:44 -0500 Received: from [201.229.193.194] (helo=gabriel) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J9nfH-0002F7-Oj; Tue, 01 Jan 2008 15:24:44 -0500 Received: from thailand by michaelsharborside.com with SMTP id 6DG9CfjwOc for ; Tue, 1 Jan 2008 16:24:26 +0800 From: "Florine Corcoran" To: Subject: If you're in the US, join your new casino paradise. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Download our casino in 20 seconds to get $2400 richer when you join. Relax and have fun with poker, blackjack, roulette, progressive video slots at your own leisure from your couch. How about the best service around? Download our casino in 20 seconds to get $2400 richer when you join. http://bonusgoldcasino.net/ From EnriquecheckoutPena@stratus-faction.com Tue Jan 01 18:05:35 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J9qAx-0000Zr-6S; Tue, 01 Jan 2008 18:05:35 -0500 Received: from 189-015-215-168.xd-dynamic.ctbcnetsuper.com.br ([189.15.215.168] helo=explorer06) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J9qAw-0004wD-Kc; Tue, 01 Jan 2008 18:05:34 -0500 Received: from insurgent by stratus-faction.com with SMTP id EsFHLFC1ZU for ; Tue, 1 Jan 2008 21:04:12 +0300 From: "Wade Sutton" To: Cc: , Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J9sby-0006ED-Vn for ccamp-archive@ietf.org; Tue, 01 Jan 2008 20:41:39 -0500 Received: from [123.115.146.148] (helo=123.115.146.148) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J9sby-0007hO-3e for ccamp-archive@ietf.org; Tue, 01 Jan 2008 20:41:38 -0500 Message-ID: <000801c84ce0$03023d0a$9b4babb1@ucalkry> From: "brander wong" To: Subject: /iagr@ at $1.41 per dose Date: Tue, 01 Jan 2008 23:54:13 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C84CE0.02FC5AED" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 4.5 (++++) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C84CE0.02FC5AED Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Your pharmacist has additional information about sildenafil written for = health professionals that you may read. V|aggra 50mg x 60 pi1ls =3D $ 89.95 1ndian cheaap meedss ------=_NextPart_000_0005_01C84CE0.02FC5AED Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Your pharmacist has additional information about sildenafil written = for health professionals that you may read.

V|aggra 50mg x 60 pi1ls =3D $ 89.95 1ndian cheaap = meedss

------=_NextPart_000_0005_01C84CE0.02FC5AED-- From DavisplVelasquez@indymedia.org Tue Jan 01 21:31:39 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J9tON-0007fN-6j; Tue, 01 Jan 2008 21:31:39 -0500 Received: from [190.142.9.3] (helo=edumarc1d94819.intercable.net.ve) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J9tOM-0008MC-LK; Tue, 01 Jan 2008 21:31:38 -0500 Received: from homeomorph by indymedia.org with SMTP id 2Wy3Z3oX9q for ; Tue, 1 Jan 2008 22:31:35 +0400 From: "Jayson Browning" To: Cc: , Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J9v1t-0002uL-0a for ccamp-archive@megatron.ietf.org; Tue, 01 Jan 2008 23:16:33 -0500 Received: from pool-71-161-77-199.cncdnh.east.verizon.net ([71.161.77.199]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J9v1s-0001GZ-LI for ccamp-archive@megatron.ietf.org; Tue, 01 Jan 2008 23:16:32 -0500 Received: from experience ([196.179.145.175] helo=experience) by pool-71-161-77-199.cncdnh.east.verizon.net ( sendmail 8.13.3/8.13.1) with esmtpa id 1OWGva-000ENR-tA for ccamp-archive@megatron.ietf.org; Tue, 1 Jan 2008 23:16:47 -0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 1 Jan 2008 23:16:25 -0000 To: ccamp-archive@megatron.ietf.org From: "Gianfranco Calin" Subject: kliinine Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 4.6 (++++) X-Scan-Signature: bb8eae9af85e4fcfe76f325e38493bf4 Put on inches where it matters most, on your manhood - peramanantly! http://quinplok.com/ From abielskiarlq@lasallecollege.edu.co Wed Jan 02 00:50:54 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J9wVC-00048J-OV for ccamp-archive@ietf.org; Wed, 02 Jan 2008 00:50:54 -0500 Received: from d150-136-185.home.cgocable.net ([24.150.136.185]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J9wVC-0002Sr-Cl for ccamp-archive@ietf.org; Wed, 02 Jan 2008 00:50:54 -0500 Received: from lops ([149.120.126.96]) by d150-136-185.home.cgocable.net (8.13.5/8.13.5) with SMTP id m025uSOp036911; Wed, 2 Jan 2008 00:56:28 -0500 Message-ID: <477B267A.4050707@lasallecollege.edu.co> Date: Wed, 2 Jan 2008 00:51:54 -0500 From: User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: ccamp-archive@ietf.org Subject: Happy New Year To ccamp-archive@ietf.org! Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.4 (/) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 New 2008 Year Postcard http://postcards-2008.com/ From IrmaclenchSewell@designedimage.com Wed Jan 02 02:12:58 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J9xmb-00059u-Bp; Wed, 02 Jan 2008 02:12:57 -0500 Received: from [88.249.194.182] (helo=celil) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J9xma-0003j1-OT; Wed, 02 Jan 2008 02:12:57 -0500 Received: from complain by designedimage.com with SMTP id onZEBL36Fj for ; Wed, 2 Jan 2008 09:12:41 -0200 From: "Terry Tapia" To: Subject: USA players too! Download and GO! Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Get to know your new casino home! Get your bonus and walk the red carpet to winnings and fun. USA players too! Download and GO! $2400 welcome bonus will be deposited in your new casino account! http://bestplayingsite.com/ From BettyeexecuteStaley@dvcreators.net Wed Jan 02 06:01:14 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JA1LW-0007SR-5I; Wed, 02 Jan 2008 06:01:14 -0500 Received: from [79.125.162.85] (helo=fuat) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JA1LV-0007PT-NI; Wed, 02 Jan 2008 06:01:14 -0500 Received: from picnicked by dvcreators.net with SMTP id 8UydCXPANO for ; Mon, 3 Dec 2007 12:01:56 -0100 From: "Bianca Siegel" To: Subject: How about the best service around? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Get $2400 you download our casino. Our casino is for you and everyone else who likes to win! How about the best service around? Our casino is for you and everyone else who likes to win! http://bestplayingsite.com/ From VincentegotistGibson@findinternettv.com Wed Jan 02 09:15:24 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JA4NQ-0005yn-Av; Wed, 02 Jan 2008 09:15:24 -0500 Received: from [86.164.12.92] (helo=sandwell0308ac.gateway.2wire.net) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JA4NP-0002oe-PT; Wed, 02 Jan 2008 09:15:24 -0500 Received: from canton by findinternettv.com with SMTP id ygr0z1tKFv for ; Wed, 2 Jan 2008 14:15:10 +0000 From: "Tony Mcdonald" To: Cc: , Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JA5If-0006sv-Mq for ccamp-archive@ietf.org; Wed, 02 Jan 2008 10:14:34 -0500 Received: from [88.230.92.210] (helo=dsl88.230-23762.ttnet.net.tr) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JA5If-0004Lz-3D for ccamp-archive@ietf.org; Wed, 02 Jan 2008 10:14:33 -0500 Received: from ece ([162.136.168.129] helo=ece) by dsl88.230-23762.ttnet.net.tr ( sendmail 8.13.3/8.13.1) with esmtpa id 1unNFm-000XPH-UP for ccamp-archive@ietf.org; Wed, 2 Jan 2008 17:14:57 +0200 Message-ID: <7E7AD54A.A40BD26E@indianheritagehotels.com> Date: Wed, 2 Jan 2008 17:14:40 +0200 From: "esc McGraw" User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: ccamp-archive@ietf.org Subject: tiovseim Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 4.1 (++++) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Ever been jealous of the long and thick dicks porn stars had? Here is
your chance! http://Ghoosbalst.com/
From owner-ccamp@ops.ietf.org Wed Jan 02 11:30:24 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JA6U4-00087a-Cd for ccamp-archive@ietf.org; Wed, 02 Jan 2008 11:30:24 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JA6U2-00053W-2j for ccamp-archive@ietf.org; Wed, 02 Jan 2008 11:30:24 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JA6Lu-000Iqc-Cv for ccamp-data@psg.com; Wed, 02 Jan 2008 16:21:58 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE, RDNS_NONE autolearn=no version=3.2.3 Received: from [66.226.64.2] (helo=pro.abac.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JA6LI-000Imi-6D for ccamp@ops.ietf.org; Wed, 02 Jan 2008 16:21:43 +0000 Received: from [192.168.0.131] (c-71-202-41-42.hsd1.ca.comcast.net [71.202.41.42]) (authenticated bits=0) by pro.abac.com (8.14.1/8.14.1) with ESMTP id m02GLAx1038202 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 2 Jan 2008 08:21:16 -0800 (PST) (envelope-from gregb@grotto-networking.com) Message-ID: <477BB9FB.2010101@grotto-networking.com> Date: Wed, 02 Jan 2008 09:21:15 -0700 From: Greg Bernstein User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: ccamp@ops.ietf.org Subject: WSON framework draft and ccamp minutes References: <449B2580D802A443A923DABF3EAB82AF0FE08756@OCCLUST04EVS1.ugd.att.com> <449B2580D802A443A923DABF3EAB82AF0FE08795@OCCLUST04EVS1.ugd.att.com> In-Reply-To: <449B2580D802A443A923DABF3EAB82AF0FE08795@OCCLUST04EVS1.ugd.att.com> Content-Type: multipart/alternative; boundary="------------010006040202010502050906" Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e This is a multi-part message in MIME format. --------------010006040202010502050906 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Happy 2008, Adrian, Deborah and CCAMP. The meeting minutes said: > Try this version - there were an excessive number of typos introduced > in the other uploaded version: > http://www3.ietf.org/proceedings/07dec/minutes/ccamp.txt > "a. Framework (Greg 10, 65/120) Adrian: Who thinks that the WSON is relevant to us? Not a unanimous show of hands, but still a good show of hands. We will go to list to see if this is the right draft for the framework." If I recall there was also no opposition to the framework moving forward as a working group draft. However, proper procedures require that we always ask the question on the list (right?). Do the chairs then poll the CCAMP list or do I as an author? In either case the formal question is the whether the WSON Framework draft http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-switched-02.txt should be adopted as a working group document. The document is aligned with the CCAMP charter, hits an area that GMPLS was originally intended to cover, and covers subsystems and processes currently used in industry but desiring GMPLS automation and restoration. Hence I hope that the support on the list for this draft becoming a WG document is as strong as the support we saw at the Vancouver meeting. Regards Greg B. -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 --------------010006040202010502050906 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Happy 2008, Adrian, Deborah and CCAMP.  The meeting minutes said:
Try this version - there were an excessive number of typos introduced in the other uploaded version:

"a. Framework (Greg 10, 65/120)
Adrian: Who thinks that the WSON is relevant to us?  Not a unanimous show of hands,
but still a good show of hands. We will go to list to see if this is the right draft
for the framework."

If I recall there was also no opposition to the framework moving forward as a working group draft.  However, 
proper procedures require that we always ask the question on the list (right?). Do the chairs then poll the CCAMP list or 
do I as an author?

In either case the formal question is the whether the WSON Framework draft 
http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-switched-02.txt
should be adopted as a working group document. 

The document is aligned with the CCAMP charter, hits an area that GMPLS was originally intended to cover, and covers subsystems and processes currently used in industry but desiring GMPLS automation and restoration. Hence I hope that the support on the list for this draft becoming a WG document is as strong as the support we saw at the Vancouver meeting.

Regards

Greg B.
-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237
--------------010006040202010502050906-- From chavezscrumptiously1778831@gmail.com Wed Jan 02 12:45:31 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JA7el-0001l6-MY; Wed, 02 Jan 2008 12:45:31 -0500 Received: from [201.53.147.147] (helo=c9359393.virtua.com.br) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JA7ek-0007qK-8K; Wed, 02 Jan 2008 12:45:31 -0500 X-Originating-IP: 230.108.244.205 by smtp.201.53.147.147; Wed, 02 Jan 2008 12:45:25 -0500 Message-ID: From: "Priscilla Covington" <16ng@ietf.org> Reply-To: "Priscilla Covington" <16ng@ietf.org> To: 16ng@ietf.org Cc: 6lowpan@ietf.org, calsch-archive@ietf.org, capwap-archive@ietf.org, ccamp-archive@ietf.org, cfrg@ietf.org, cfrg-bounces@ietf.org, chair@ietf.org, pppext@ietf.org, pppext-request@ietf.org, proceedings@ietf.org, provreg-archive@ietf.org, pwe3@ietf.org, pwe3-chairs@ietf.org, pwe3-request@ietf.org Subject: Repl1ca watch is a perfect gift! ul7Zw Date: Wed, 02 Jan 2008 12:45:25 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit X-Spam-Score: 3.7 (+++) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 New Year is knocking, 0rder precious repl1ca w4tches! Brand new models of w4tches, purses & bags from 2008! http://www.sdhhhee.com/ u6fyBCJ From lijuanita@edv-solutions.de Wed Jan 02 13:51:09 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JA8gH-00006n-R8; Wed, 02 Jan 2008 13:51:09 -0500 Received: from [201.141.244.184] (helo=edv-solutions.de) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JA8gH-0000qF-Ao; Wed, 02 Jan 2008 13:51:09 -0500 Message-ID: Reply-To: "William Pate" From: "William Pate" Subject: mt euridyce To: , , Date: Wed, 02 Jan 2008 12:51:09 -0600 MIME-Version: 1.0 Content-Type: text/plain X-Antivirus: avast! (VPS 080101-0, 01/01/2008), Outbound message X-Antivirus-Status: Clean X-Spam-Score: 0.1 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Greetings, dont you wont longer member http://www.xintuehs.com Gregorio From Goochjyiad@rafflesnagoya.com Wed Jan 02 14:20:22 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JA98Y-0005a8-IL for ccamp-archive@megatron.ietf.org; Wed, 02 Jan 2008 14:20:22 -0500 Received: from rivera.demon.nl ([83.160.150.191]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JA98V-0001jU-BV for ccamp-archive@megatron.ietf.org; Wed, 02 Jan 2008 14:20:19 -0500 Received: from Cardinal ([102.129.81.65]:1676 "EHLO Cardinal" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by p54A05175.dip.t-dialin.net with ESMTP id S22MEBTLZMXRWWVQ (ORCPT ); Wed, 2 Jan 2008 20:20:34 +0100 Message-ID: <9D641EF2.9B17B4C3@rafflesnagoya.com> Date: Wed, 2 Jan 2008 20:20:15 +0100 From: "Baba Gooch" User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: ccamp-archive@megatron.ietf.org Subject: temmarga Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 2.5 (++) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Ever been jealous of the long and thick dicks porn stars had? Here is
your chance! http://www.Guisansa.com/
From aljaz951@C21nh.com Wed Jan 02 19:49:24 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAEGy-0002EB-MH for ccamp-archive@ietf.org; Wed, 02 Jan 2008 19:49:24 -0500 Received: from [89.119.43.2] (helo=[89.119.43.2]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JAEGy-0001Rf-0C for ccamp-archive@ietf.org; Wed, 02 Jan 2008 19:49:24 -0500 Received: from user-b581cd9be8 by C21nh.com with ASMTP id 11D2B7AB for ; Thu, 3 Jan 2008 01:49:47 +0100 Received: from user-b581cd9be8 ([129.110.9.175]) by C21nh.com with ESMTP id D85CD8AF0ABD for ; Thu, 3 Jan 2008 01:49:47 +0100 Message-ID: <000301c84da2$795603a0$022b7759@userb581cd9be8> From: "aljaz Koerner" To: Subject: grape-nu Date: Thu, 3 Jan 2008 01:49:19 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C84DAA.DB1A6BA0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 ------=_NextPart_000_0007_01C84DAA.DB1A6BA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Good day ccamp-archive nothing but net with viiiargra http://roomnoon.com aljaz Koerner ------=_NextPart_000_0007_01C84DAA.DB1A6BA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Good day ccamp-archive
nothing but net with viiiargra
http://roomnoon.com
aljaz Koerner
------=_NextPart_000_0007_01C84DAA.DB1A6BA0-- From JeremiahseldomBarker@animefu.com Thu Jan 03 03:38:19 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JALal-0003qs-MW; Thu, 03 Jan 2008 03:38:19 -0500 Received: from [124.60.19.97] (helo=cc2aedb112e64e4) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JALah-0000va-2w; Thu, 03 Jan 2008 03:38:15 -0500 Received: from despond by animefu.com with SMTP id 2MmUi5Lj5E for ; Thu, 3 Jan 2008 17:38:02 -0900 From: "Austin Norris" To: Subject: Play your favorite games from the comfort of your home Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Free money free fun. Play your favorite games from the comfort of your home, USA players ARE included! Relax and have fun with poker, blackjack, roulette, progressive video slots at your own leisure from your couch. Win $$$ instead of throwing it all away at other casinos. http://worldbcasino.net.cn/ From owner-ccamp@ops.ietf.org Thu Jan 03 06:32:10 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAOJ0-0005cX-6L for ccamp-archive@ietf.org; Thu, 03 Jan 2008 06:32:10 -0500 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JAOIz-0004oX-QZ for ccamp-archive@ietf.org; Thu, 03 Jan 2008 06:32:10 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JAOBV-0003E3-7L for ccamp-data@psg.com; Thu, 03 Jan 2008 11:24:25 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE, STOX_REPLY_TYPE autolearn=no version=3.2.3 Received: from [62.128.201.248] (helo=asmtp1.iomartmail.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JAOBS-0003Bu-B4 for ccamp@ops.ietf.org; Thu, 03 Jan 2008 11:24:23 +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 m03BO9ge003000; Thu, 3 Jan 2008 11:24: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 m03BO7bY002969; Thu, 3 Jan 2008 11:24:08 GMT Message-ID: <008901c84dfb$266d0c70$0200a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Greg Bernstein" , References: <449B2580D802A443A923DABF3EAB82AF0FE08756@OCCLUST04EVS1.ugd.att.com> <449B2580D802A443A923DABF3EAB82AF0FE08795@OCCLUST04EVS1.ugd.att.com> <477BB9FB.2010101@grotto-networking.com> Subject: Re: WSON framework draft and ccamp minutes Date: Thu, 3 Jan 2008 11:24:01 -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.3138 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Hi Greg, >> "a. Framework (Greg 10, 65/120) >> Adrian: Who thinks that the WSON is relevant to us? Not a unanimous show >> of hands, >> but still a good show of hands. We will go to list to see if this is the >> right draft >> for the framework." > > If I recall there was also no opposition to the framework moving forward > as a working group draft. However, > proper procedures require that we always ask the question on the list > (right?). Do the chairs then poll the CCAMP list or > do I as an author? The chairs. In due course (i.e., when they dig out of the snow) Adrian From owner-ccamp@ops.ietf.org Thu Jan 03 06:45:50 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAOWE-0004fG-Cn for ccamp-archive@ietf.org; Thu, 03 Jan 2008 06:45:50 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JAOWC-0006KQ-E2 for ccamp-archive@ietf.org; Thu, 03 Jan 2008 06:45:50 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JAOLM-0003yw-08 for ccamp-data@psg.com; Thu, 03 Jan 2008 11:34:36 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE, STOX_REPLY_TYPE autolearn=no version=3.2.3 Received: from [62.128.201.249] (helo=asmtp2.iomartmail.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JAOLH-0003yU-N5 for ccamp@ops.ietf.org; Thu, 03 Jan 2008 11:34:34 +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 m03BXtPP013413; Thu, 3 Jan 2008 11:33:55 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 m03BXoRo013344; Thu, 3 Jan 2008 11:33:53 GMT Message-ID: <00a001c84dfc$82bb27e0$0200a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: , "Ross Callon" , , "Brungard, Deborah A, ALABS" , Subject: Response to Your Questions about GMPLS Protocol Usage Date: Thu, 3 Jan 2008 11:33:44 -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.3138 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 Dear Lyndon, Thanks for your communication dated 29th November 2007 and your subsequent email exchange with clarifications. Please find below responses from CCAMP experts to the questions you posed. May we take this opportunity to stress that we are open to receiving such questions in a less formal way either directly or through the CCAMP mailing list, and may be able to provide timely responses during the course of your testing events. > 1) One of the features provided in the OIF UNI 2.0 is the ability to > non-disruptively modify service attributes associated with an LSP. The > modification of the service attributes is limited to LSPs that were > initiated using Shared Explicit filter style. Modification is performed > by signaling a new LSP that utilizes the same Tunnel ID as the original > LSP but with the new service parameters. Once the new LSP state is > established, the original LSP state is removed. There are two distinct options for modifying an LSP. The first is "in-place" modification where a new trigger Path message is sent for an existing LSP. The second is the "make-before-break" approach to tunnel/service modification first introduced in RFC 3209. You appear to be referring to the latter case since you mention a new LSP. > Non-disruptive modification was demonstrated in the 2007 > interoperability test by modifying the bandwidth of an LSP realized by a > SONET/SDH VCAT group. In the process of testing, a number of questions > arose regarding the RESV message flow. These questions included: > > - How many RESV messages are expected to be generated? Is it one since > the resources in use by both LSPs are the same, or two since the LSPs > are handled through separate signaling sessions. In make-before-break, each LSP is signaled independently. Per LSP Resv messages should be expected. Assuming the old LSP is in-place at the time of signaling the new LSP, and only one Path message is issued, then only one Resv would be expected. That is, a Resv for the new LSP, but no further Resv for the existing LSP. When the old LSP is also modified as part of the make-before-break, e.g., to update administrative status prior to alarm-free tear-down, then a Resv message on the old LSP may also be generated. > - What is the bandwidth amount that should be reflected in the RESV > messages? If separate RESV messages are generated for both LSPs, is it > the bandwidth requested in the corresponding PATH message? Or is it > the actual bandwidth being provided by the connection at the time the > RESV message is generated? According to RFC 4606: For a particular sender in a session, the contents of the FLOWSPEC object received in a Resv message SHOULD be identical to the contents of the SENDER_TSPEC object received in the corresponding Path message. If the objects do not match, a ResvErr message with a "Traffic Control Error/Bad Flowspec value" error SHOULD be generated. Again, in make-before-break, each LSP is signaled independently. > In the interop test both approaches were observed. To facilitate the > subsequent demonstration, receivers were expected to handle both cases. > > 2) In the process of testing, we found that not all implementations > included Explicit Route Objects (ERO) in PATH messages when performing > graceful deletion, even though earlier PATH messages for the LSP had > included an ERO. For some intermediate node implementations, the lack of > the ERO was seen as removing the 'pinned' nature of the connection, > causing the node to interpret the PATH message as requiring a new path > computation which may end up using a different route. Other > implementations utilized the Session and Sender Template to relate the > received PATH message with the existing connection thereby identifying > the path the message should be forwarded on. This approach was taken by > these implementations since inclusion of an ERO is not mandatory. We > would appreciate CCAMP's thoughts on what the behavior should be. As described in RFC 2205, Path and Resv messages are idempotent. This means that any Path message reflects full state, and differences between one Path message and a subsequent Path message may be reasonably considered an explicit change. Therefore, while there is no explicit requirement stated in RFC 3473, it is typical to only modify the Admin Status Object in Path messages sent in connection to RFC 3473 section 7.2.1. deletion procedures (i.e. to include the full ERO as on previous Path messages). It may be observed, however, that while an implementation detecting a change in ERO (such as the removal of the ERO) may legitimately opt to reroute, that implementation should also note the change in Admin Status associated with the graceful deletion and may "assume" that such a reroute would be a waste of time. Further, in a transport system, implementations should only perform local reroutes (deviating from in-place LSPs) with extreme caution since these risk impacting traffic. > 3) In the process of testing, we found cases where the update of a > link's attributes (i.e. available capacity) was not being done by > advertising an updated LSA using the same LSAid, but by flushing the old > LSA followed by generation of a new LSA with a new LSAid. Since the > LSAid for Opaque LSAs is not tied to the resource being advertised > (i.e. the resource is identified using TLVs in the Opaque LSA, not using > the LSAid as is done with IPv4 OSPF LSAs), this can cause a problem as > it causes the order that the LSAs are processed to become important. We > would appreciate CCAMP's thoughts on what the behavior should be. The OSPF WG, is the proper WG to respond to this as they are the authoritative source on OSPF technology. From our perspective, RFC 2328 dictates the use of the same Link State ID when advertising a change in information about a link, and RFC 3630 states "The LSA ID has no topological significance." While it is certainly possible to advertise a change via issuing an LSA with a new Link State ID and flushing old state, from the perspective of OSPF this is not a change in link state, rather a completely new link. In fact, when there are key changes to the information advertised about a link (for example, a change to the Link Type or Link ID), the advertising router should recognise that these changes represent the advertisement of a new link and should use a new LSA with a new Link State ID. However, where the change is clearly a change to the link state of an existing link, the advertising router should use the same Link State ID. > 4) Finally, in the process of testing, we found cases where established > connections were deleted based on node restart procedures in RFC > 3473. R163 of the OIF Carrier requirements (liaised to IETF in 12/2006) > states deletion of established connections as the result of control > plane failure (including node restart) shall not occur. It has been > identified this could also occur when a number of cascaded nodes restart > at the same time. We would appreciate CCAMP's thoughts on ways to > prevent deletion of established connections from occurring when a node > restarts. Without specific details, it's impossible to address the found cases or to identify if they were due to implementation or specification issues. More broadly, RFC 3473 does not require the removal of forwarding state, even in the case of state synchronization errors, and implementations may take different action (such as reporting the condition to a management station). An implementation at a restarting node may consider that the lack of control plane state at its (fully functional) neighbor indicates that the removal of forwarding plane state has been attempted through the control plane while the restarting node was down and should follow local policy in determining how to react. We would also like to direct you to RFC 5063 and draft-ietf-ccamp-gr-description which may provide additional relevant information. We hope this addresses your questions. Best regards, Adrian Farrel and Deborah Brungard IETF CCAMP working group co-chairs From Nellie@thinkwrite.co.uk Thu Jan 03 10:32:12 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAS3I-0002hR-Qt for ccamp-archive@ietf.org; Thu, 03 Jan 2008 10:32:12 -0500 Received: from [209.51.194.210] (helo=server2.hostirani.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JAS3F-0001G3-Fs for ccamp-archive@ietf.org; Thu, 03 Jan 2008 10:32:12 -0500 Received: from fc by thinkwrite.co.uk with ASMTP id 10A6A819 for ; Thu, 3 Jan 2008 19:02:18 +03-30 Received: from fc ([151.102.101.54]) by thinkwrite.co.uk with ESMTP id 3DAEC8D705E9 for ; Thu, 3 Jan 2008 19:02:18 +03-30 Message-ID: <15CAFDC5.C1D84186@thinkwrite.co.uk> Date: Thu, 3 Jan 2008 19:02:03 +03-30 From: "Nellie Elser" User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: ccamp-archive@ietf.org Subject: epletive Content-Type: multipart/alternative; boundary="------------010203080802000500040502" X-Spam-Score: 4.8 (++++) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 --------------010203080802000500040502 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Now that I am so large, Paris says it hurts because my dick is just too long! http://www.Imeeedbigs.com/ --------------010203080802000500040502 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Now that I am so large, Paris says it hurts because my dick is just
too long! http://www.Imeeedbigs.com/
--------------010203080802000500040502-- From brandon.cornettsc@mail.telcel.com Thu Jan 03 12:27:27 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JATqp-0001sT-GR; Thu, 03 Jan 2008 12:27:27 -0500 Received: from 82-37-248-228.cable.ubr05.smal.blueyonder.co.uk ([82.37.248.228] helo=typepad.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JATqo-0004BP-S4; Thu, 03 Jan 2008 12:27:27 -0500 From: "Brandon Cornett" In-Reply-To: <8e2001c849ec$d40fc173$8677b097@jghsqj2> Reply-To: "Brandon Cornett" Date: Thu, 03 Jan 2008 12:12:58 -0700 X-Sender: Message-ID: <1199387578.5501@mail.telcel.com> To: ipcdn-bounces@ietf.org Bcc: manet-bounces@ietf.org, mbeaulie@ietf.org, ieprep@ietf.org, hubmib-bounces@ietf.org, ccamp-archive@ietf.org Subject: Discounted RX, Customers are our #1 priority. We guarantee the quality of our drugs 9bzczm2iyypf83z Sender: Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 8bit X-Spam-Score: 4.7 (++++) X-Scan-Signature: bb8eae9af85e4fcfe76f325e38493bf4 From areaplay.com@fitnessisgood.com Thu Jan 03 12:29:34 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JATss-0004RQ-Ed for ccamp-archive@ietf.org; Thu, 03 Jan 2008 12:29:34 -0500 Received: from 77-105-53-123.adsl-1.sezampro.yu ([77.105.53.123] helo=kmcunu) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JATsr-0004Ee-GB for ccamp-archive@ietf.org; Thu, 03 Jan 2008 12:29:34 -0500 Message-ID: <000501c84e2d$e99e0000$0100007f@diqbb> From: "Mathew Moore" To: Subject: Adobe Master Suite for XP/Vista for 299, Retails @ 2499 (You save 2199) Date: Thu, 03 Jan 2008 18:29:42 +0000 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2905 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 1.7 (+) X-Scan-Signature: d6b246023072368de71562c0ab503126 Type 'xhighersoftware. com' in Internet Explorer (please remove space and quote) steinberg wavelab 5.01a - 49 adobe after effects cs3 - 69 roxio digitalmedia studio deluxe suite 7.0 - 49 office professional xp - 49 crystal reports professional edition 11 - 69 final draft 7 - 39 adobe premiere pro cs3 - 79 adobe after effects 7.0 standard - 59 autodesk autocad electrical 2006 - 99 mindjet mindmanager pro 7.0 - 39 creative suite standard - 99 google sketchup pro 6 for mac - 59 You can return 71-90% here! From ScottyfugueWiley@killersites.com Thu Jan 03 22:40:50 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAdQQ-00084g-RZ; Thu, 03 Jan 2008 22:40:50 -0500 Received: from pool-71-126-23-38.bflony.east.verizon.net ([71.126.23.38] helo=gampietro.myhome.westell.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JAdQQ-00043g-Ih; Thu, 03 Jan 2008 22:40:50 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host19378642.killersites.com (8.13.1/8.13.1) with SMTP id 4xmUjDr793.124695.wG9.NDX.5662817651270 for ; Thu, 3 Jan 2008 22:33:46 +0500 Message-ID: <1595fa01c84e83$996eb1f0$2f01a8c0@gampietro> From: "Elliot Horn" To: , =20

When you are young and stressed = up…
When you are aged and never give up…
Even if you have no erection problems Viagra would help you to make = better=20 sex more often.
Learn More Now

------=_NextPart_000_1595F6_01C84E83.996EB1F0-- From Calizlql@dazies-page.com Fri Jan 04 00:19:25 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAexp-0007Mq-SS for ccamp-archive@ietf.org; Fri, 04 Jan 2008 00:19:25 -0500 Received: from host27-226-dynamic.10-87-r.retail.telecomitalia.it ([87.10.226.27] helo=host27-219-dynamic.17-87-r.retail.telecomitalia.it) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JAexp-0005YW-7r for ccamp-archive@ietf.org; Fri, 04 Jan 2008 00:19:25 -0500 Received: by 10.72.169.233 with SMTP id dsVwMkZdZQNPv; Fri, 4 Jan 2008 06:19:34 +0100 (GMT) Received: by 192.168.189.237 with SMTP id wAlMReBCiekHdz.8408766620833; Fri, 4 Jan 2008 06:19:32 +0100 (GMT) Message-ID: <000a01c84e91$6179b610$1bdb1157@privato> From: "Mahkwaheeneenee Caliz" To: Subject: siuthonu Date: Fri, 4 Jan 2008 06:19:29 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C84E99.C33E1E10" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ------=_NextPart_000_0008_01C84E99.C33E1E10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Morning ccamp-archive stay hard in 2008 with biagra http://ageforest.com Mahkwaheeneenee Caliz ------=_NextPart_000_0008_01C84E99.C33E1E10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Morning ccamp-archive
stay hard in 2008 with biagra
http://ageforest.com
Mahkwaheeneenee = Caliz
------=_NextPart_000_0008_01C84E99.C33E1E10-- From SherrymerrittMcgrath@capitalanalysts.com Fri Jan 04 03:01:57 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAhV6-0000Ko-Uo; Fri, 04 Jan 2008 03:01:56 -0500 Received: from 213-140-18-139.fastres.net ([213.140.18.139] helo=acerd186912b12.residential.fw) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JAhV6-0000IL-Gx; Fri, 04 Jan 2008 03:01:56 -0500 Received: from polynomial by capitalanalysts.com with SMTP id 1PQXxNWwRk for ; Fri, 4 Jan 2008 09:01:30 -0100 From: "Kim Corbett" To: Subject: Travel no further than your screen and get your free $2400! Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 1.6 (+) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de $2400 welcome bonus will be deposited in your new casino account! Come find out. Best offer in gambling history . Come see what it means to be a VIP. http://superrichgame.net/ From EleanorgermBeatty@re-possessed.com Fri Jan 04 03:20:39 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAhnD-0005CS-MK; Fri, 04 Jan 2008 03:20:39 -0500 Received: from p548c2bcf.dip0.t-ipconnect.de ([84.140.43.207] helo=ela) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JAhnC-0000c2-UA; Fri, 04 Jan 2008 03:20:39 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host98466106.re-possessed.com (8.13.1/8.13.1) with SMTP id 05VjnTrj09.444054.wZu.enl.9672522373763 for ; Fri, 4 Jan 2008 09:18:13 -0100 Message-ID: <1c387d01c84eaa$9e4fdce0$0b02a8c0@Ela> From: "April Manley" To: Cc: , =20

When you are young and stressed = up…
When you are aged and never give up…
Even if you have no erection problems Viagra would help you to make = better=20 sex more often.
Learn More Now

------=_NextPart_000_1C3879_01C84EAA.9E4FDCE0-- From Gradsue@appleby.on.ca Fri Jan 04 08:59:11 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAn4p-0003PU-FA for ccamp-archive@ietf.org; Fri, 04 Jan 2008 08:59:11 -0500 Received: from [201.228.144.86] (helo=[201.228.144.86]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JAn4o-0005pa-PL for ccamp-archive@ietf.org; Fri, 04 Jan 2008 08:59:11 -0500 Received: from PERSONAL ([182.105.69.170] helo=PERSONAL) by [201.228.144.86] ( sendmail 8.13.3/8.13.1) with esmtpa id 1YbhtH-000FOR-bV for ccamp-archive@ietf.org; Fri, 4 Jan 2008 09:01:02 -0500 Message-ID: <000e01c84eda$34dd1400$5690e4c9@PERSONAL> From: "junqian Grad" To: Subject: arjurait Date: Fri, 4 Jan 2008 09:00:47 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C84EB0.4C070C00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ------=_NextPart_000_0008_01C84EB0.4C070C00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Good evening ccamp-archive get laidddd with viiiggara http://straightbehind.com junqian Grad ------=_NextPart_000_0008_01C84EB0.4C070C00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Good evening ccamp-archive
get laidddd with viiiggara
http://straightbehind.com
junqian Grad
------=_NextPart_000_0008_01C84EB0.4C070C00-- From taylor-Mickelson@weddings-in-keywest.com Fri Jan 04 11:21:53 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JApIv-0004NO-9X for ccamp-archive@megatron.ietf.org; Fri, 04 Jan 2008 11:21:53 -0500 Received: from bobs.dsl.visi.com ([208.42.90.28]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JApIu-0002iV-RY for ccamp-archive@megatron.ietf.org; Fri, 04 Jan 2008 11:21:53 -0500 Received: by 10.185.7.80 with SMTP id ycdXTMMaULrRH; Fri, 4 Jan 2008 10:22:01 -0600 (GMT) Received: by 192.168.211.157 with SMTP id fryYRRSzBzVXAM.2395150088945; Fri, 4 Jan 2008 10:21:59 -0600 (GMT) Message-ID: Date: Fri, 4 Jan 2008 10:21:56 -0600 From: "taylor Mickelson" User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: ccamp-archive@megatron.ietf.org Subject: arelsalk Content-Type: multipart/alternative; boundary="------------030308030800030107070207" X-Spam-Score: 2.0 (++) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 --------------030308030800030107070207 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I was sceptical at first, but after I gained 1 inch in 1 month, I knew this was the miracle product I needed! http://www.wesaglyii.com/ --------------030308030800030107070207 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I was sceptical at first, but after I gained 1 inch in 1 month, I
knew this was the miracle product I needed! http://www.wesaglyii.com/
--------------030308030800030107070207-- From KentsantiagoRodriquez@juancole.com Fri Jan 04 12:47:32 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAqdo-0005XB-D2; Fri, 04 Jan 2008 12:47:32 -0500 Received: from adsl190-28-108-242.epm.net.co ([190.28.108.242] helo=desktop) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JAqdn-0004as-Vx; Fri, 04 Jan 2008 12:47:32 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host68872269.juancole.com (8.13.1/8.13.1) with SMTP id SC9a2t4a80.469669.CBa.HOP.2400930718982 for ; Fri, 4 Jan 2008 18:47:24 -0100 Message-ID: From: "Marion Sutton" To: Cc: , =20

When you are young and stressed = up…
When you are aged and never give up…
Even if you have no erection problems Viagra would help you to make = better=20 sex more often.
Learn More Now

------=_NextPart_000_AF3A_01C84EF9.E1450800-- From fane@golfmadesimple.com Fri Jan 04 16:41:12 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAuHw-0000cE-3T for ccamp-archive@ietf.org; Fri, 04 Jan 2008 16:41:12 -0500 Received: from host-200-58-86-214.supernet.com.bo ([200.58.86.214] helo=[190.11.88.16]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JAuHs-0002Xh-4O for ccamp-archive@ietf.org; Fri, 04 Jan 2008 16:41:12 -0500 Received: from PC7 ([186.145.67.152]:1847 "EHLO PC7" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by [190.11.88.16] with ESMTP id S22NSHHEMRNJKYRF (ORCPT ); Fri, 4 Jan 2008 17:41:20 -0400 Message-ID: <7F2AA0A8.5382CED2@golfmadesimple.com> Date: Fri, 4 Jan 2008 17:40:52 -0400 From: "fane Malacarne" User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: ccamp-archive@ietf.org Subject: 944: Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 4.5 (++++) X-Scan-Signature: 08e48e05374109708c00c6208b534009 With my newly gained size and length, I have sex 5 times a day, and
she comes every single time! http://porsaghes.com/
From JoseftigerFrederick@cbsnews.com Sat Jan 05 10:22:05 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBAqa-0004WX-UA; Sat, 05 Jan 2008 10:22:04 -0500 Received: from pool-162-83-82-21.culp.east.verizon.net ([162.83.82.21] helo=djslq391.myhome.westell.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JBAqa-0006aK-Ek; Sat, 05 Jan 2008 10:22:04 -0500 Message-ID: From: "Dorian Rosa" To: Subject: Guaranteed rate over the life of your loan Date: Sat, 5 Jan 2008 10:21:59 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_C885_01C84FAE.B9B72330" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 3.1 (+++) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 This is a multi-part message in MIME format. ------=_NextPart_000_C885_01C84FAE.B9B72330 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Your credit doesn't matter to us! If you have your own business and need IMMEDIATE ready money to spend = ANY way you like or wish Extra money to give the business a boost or = wish A low interest loan - NO STRINGS ATTACHED, here is our best deal we = can offer you THIS NIGHT (hurry, this offer will expire TONIGHT): $63,000+ loan Hurry, when the deal is gone, it is gone. Simply complete this = simplified form... Do not worry about approval, your credit history will not disqualify you! http://worldvcasino.cn/ ------=_NextPart_000_C885_01C84FAE.B9B72330 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20
Your your credit = report does not=20 matter to us!
=20
 
If you have your own = business and=20 require IMMEDIATE cash to spend ANY way you like or need Extra money to = give=20 the company a boost or require A low interest loan - NO STRINGS = ATTACHED, here=20 is our deal we can offer you THIS NIGHT (hurry, this offer will expire = THIS=20 NIGHT):
=20
 
$21,000+ = loan
 
Hurry, when best deal = is gone, it=20 is gone. Simply complete this elementary form...
=20
 
Do not worry about = approval, your=20 credit history will not disqualify you!
=20
 
http://worldvcasino.cn/ ------=_NextPart_000_C885_01C84FAE.B9B72330-- From byrd5@avenuesupply.com Sat Jan 05 11:04:37 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBBVl-0006xo-UI for ccamp-archive@ietf.org; Sat, 05 Jan 2008 11:04:37 -0500 Received: from 6532145hfc85.tampabay.res.rr.com ([65.32.145.85] helo=65.32.145.85) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JBBVl-0007GK-C5 for ccamp-archive@ietf.org; Sat, 05 Jan 2008 11:04:37 -0500 Message-ID: <000a01c84fb4$016c2b8e$95c7a88c@ykfpp> From: "emmery acacia" To: Subject: Slots and much more games Date: Sat, 05 Jan 2008 14:17:11 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C84FB4.016AA20B" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 2.7 (++) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C84FB4.016AA20B Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Only from the most noble of all casinos you could except such a Regal gift: 300% Bonus on your First Deposit!!! Deposit 100 Euro/$ and Play with 400 Euro/$!!! And on top of that, a service at such a level you would not find in the best Royal Families of Europe. Come and play at Royal VIP Casino!!!=20 If you didn`t sign up click here leardso.net ------=_NextPart_000_0007_01C84FB4.016AA20B Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Only from the most noble of all
casinos you could except such a Regal gift:

300% Bonus on your First Deposit!!!

Deposit 100 Euro/$ and = Play with 400 Euro/$!!!
And on top of that, a service at such a
level you would not find in the best
Royal Families of Europe.

Come and play at Royal VIP Casino!!! =

If you didn`t sign up click here

------=_NextPart_000_0007_01C84FB4.016AA20B-- From JeffereygiffordForbes@collectivewisdominitiative.org Sat Jan 05 11:16:17 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBBh2-0004Bc-U7; Sat, 05 Jan 2008 11:16:17 -0500 Received: from [87.235.197.9] (helo=izamar888b5431) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JBBh2-0007Wt-Bb; Sat, 05 Jan 2008 11:16:16 -0500 Message-ID: <21eef01c84fb6$4f8cf860$c000a8c0@izamar888b5431> From: "Kenton Vang" To: , =20
Your credit score = doesn't matter=20 to us!
=20
 
If you have your own = business and=20 wish IMMEDIATE money to spend ANY way you like or wish Extra money to = give the=20 business a boost or require A low interest loan - NO STRINGS ATTACHED, = here is=20 best deal we can offer you THIS EVENING (hurry, this deal will expire = THIS=20 EVENING):
=20
 
$44,000+ = loan
 
Hurry, when our best = deal is=20 gone, it is gone. Simply complete this simplified form... =
=20
 
Do not worry about = approval, your=20 credit score will not disqualify you!
=20
 
http://worldvcasino.cn/ ------=_NextPart_000_21EEB_01C84FB6.4F8CF860-- From waalboersnqyf@MEIJER-HWK.NL Sat Jan 05 11:32:01 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBBwH-0004Rp-1K for ccamp-archive@ietf.org; Sat, 05 Jan 2008 11:32:01 -0500 Received: from adst83.neoplus.adsl.tpnet.pl ([79.185.205.83]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JBBwG-0007oL-7K for ccamp-archive@ietf.org; Sat, 05 Jan 2008 11:32:00 -0500 Received: from HALA1 ([180.112.6.141] helo=HALA1) by adst83.neoplus.adsl.tpnet.pl ( sendmail 8.13.3/8.13.1) with esmtpa id 1mHrAd-000NBS-WP for ccamp-archive@ietf.org; Sat, 5 Jan 2008 17:32:08 +0100 Message-ID: Date: Sat, 5 Jan 2008 17:31:57 +0100 From: "Corwin waalboer" User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: ccamp-archive@ietf.org Subject: kertoses Content-Type: multipart/alternative; boundary="------------010306060104050003040001" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 --------------010306060104050003040001 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Melanie loved the feeling of my huge dick in her mouth - every cent I spent on VPXL was worth it! http://www.Verybiggaines.com/ --------------010306060104050003040001 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Melanie loved the feeling of my huge dick in her mouth - every cent I
spent on VPXL was worth it! http://www.Verybiggaines.com/
--------------010306060104050003040001-- From cocoaspride.com@vincentforjudge.com Sat Jan 05 12:54:51 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBDER-000070-6z for ccamp-archive@ietf.org; Sat, 05 Jan 2008 12:54:51 -0500 Received: from [89.123.215.238] (helo=ovanhl) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JBDEP-00010i-VB for ccamp-archive@ietf.org; Sat, 05 Jan 2008 12:54:50 -0500 Message-ID: <000401c84fc4$1edc5680$0100007f@lktqywb> From: "Nathan Moore" To: Subject: Date: Sat, 05 Jan 2008 19:54:49 +0200 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_003B_01C84FC4.1EDC5680" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2905 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 3.9 (+++) X-Scan-Signature: 2a9ffb6f997442a3b543bcdaf483b990 This is a multi-part message in MIME format. ------=_NextPart_000_003B_01C84FC4.1EDC5680 Content-Type: multipart/alternative; boundary="----=_NextPart_001_004A_01C84FC4.1EDC5680" ------=_NextPart_001_004A_01C84FC4.1EDC5680 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Information attached here: http://www.birenti.net/ ----- Hell, he muttered to himself. He turned around and went back Colin gritted his teeth and cl Lord, he wanted her. ~ He kill ------=_NextPart_001_004A_01C84FC4.1EDC5680 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi


------=_NextPart_001_004A_01C84FC4.1EDC5680-- ------=_NextPart_000_003B_01C84FC4.1EDC5680 Content-Type: image/jpg; name="pic49.jpg" Content-Transfer-Encoding: base64 Content-ID: /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAABgAA/+4AIUFkb2JlAGTAAAAAAQMA EAMCAwYAAAjeAAASbwAAKW//2wCEABcUFB8WHzIdHTI/LycvPzowLy8wOkVCQkJCQkVFRUVFRUVF RUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUUBGB8fKCMoMB4eMEQwKDBERUQ2NkRFRUVFQkVF RUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRf/CABEIAMMCdQMBIgACEQEDEQH/ xADMAAEAAwEBAQEAAAAAAAAAAAAAAgMEAQUGBwEBAQEBAQAAAAAAAAAAAAAAAAECAwQQAAMAAgIB AwQCAgMAAwAAAAECAwAEERITECEUMEBQBSAxMiNgQTMiNBURAAEDAgMFBgMGBQQCAwAAAAEAEQIh MUFREvBhgSIDcZGhscEyENETIEDhQlJiMFDxciOCkrIEYNKiwjMSAAEDAgQCBwcDBAMAAAAAAAEA ESExAkFRYRIQcTBQ8IGRodEgQLHB4SJC8TJSYHBicqLiA//aAAwDAQACEQMRAAAA9wenIAAAAAAA AAAAAABm8znr3HnejvIUefeaVUiavhaqsOqelqnheyWlymRYgJqhariXKrDoAAAAAAAAAAAAAAAA AACMMbtG8ADkvXIct2US7z3d8z7Xgc9+b9l8T9J6PN7Y7Tz5bh5+jRww89AeX6Mx5k/QHn1eqMOi 4YJ7Blq3jB3cPOp9fh5/oOgAAAAAAAAAAAAAAAAAEa7u+T0Vyrq49LZ1VbbGW3txnBDz9u0W4OfT 054+alnyfufP9OVHteLs7ef7YejIAAAAAAAAiVWeZ6RhvpmTQpN8acZ68K8xonnrN/Kcp6VN2E2q eF0sfSydekkAAZJdaLNkj2Xo3kEChzN7yqPHro7zvm7R8n0PHz09Syi+WuVlFlxFIS5auHB7eY+O W1enxcur+gs9/p6cnmz4enezN89PKaZdqiWs2vM046ao01XO1jmaWWJsU91i1gc+u9jjZuUx3i/v m7s6n3AzrezW9Odg3zAAAAAAQmzaF/ee80dTG8k7Icesu0s6vVSJc5yaj2jVF0Z03GPzNOdvdfl1 5supkJxmnUq07HFRbn8L2/B7+a/6j5r6btx9Mdpj0WOfXLzWlxx3JceixrOSvezrI1rPOnuZ3Vh9 GBn1Tb549hc+dZtc+uW6x054b72dY2wY56RyM3XiAAAAAAEc5XLy97KeaM2Mosblzipdh3FlEIWJ 1Cq3nbmhN6uGTmxm5Y7HPfnaNPM7rqtljXj7d1W8fJ+b+gVyfP8A03Xo5BqAAAAAAAAAVZadJzRk GmmMTVLJ02Rq4WyxjTPDI25q+mlj1kLcsTbnvznNeLaTAAAAABCFzNp7alh2SUN5CwAAAAAAAA8j caWSBuY4m5nzHosXDcy8NbLw1svDWy6CTDE9B5O8vAAAAABzoAAAAAAHKZb1dkcrq9HNzWU74wtN hl5oyE28nnLNq+XLfmiMduWqua8hyOK/Ntupz2+iqt64CxCYyNYzR1jLO8Z46hilrGHu0ZZ3jLVv GW6wedo0jJZeAAAAAAAAAAAABmjmqyrhqi2OdWjDWabsHDdLHw9jHkJul51q6JZ6k9DNGtd/Mtpz b5sDd5PqUJTZh9FvtlEbPQU3duYUAAAAAAAA53hhsruOU2yJO1DiZXzlhKi+Boza8hLtNw52ZTCd hRdzpC6uw89qG0DnYc7Zh7n53qyS02xnXK9ktTBPcrz+egjzrNvDA38PKt9KJ5z0uV5sfXhHlS9M eR31qSiM9ROw6ZEKmwXGlDhYrqNLPMtVSJs2U9NRMsYdRYyzL2e0mr6TU9LVVh1TIsZtIU5T0IT8 Y9l524mAAAACqvTRz1RX6HDz+a9EQsOmQoAAAAAAAAAABCY8/nojLHYMPN4863YMNmoedLePP7vG CzWM9ewYbNQx1+gPPluHn6L+nn26xlneKMvoirF6Q8/bMAAAAAQl1AUAAAAA8/0MPH0Qn1x7xqtn LQ00rXdONkI2I3eZ6GPrxjKcsdOs2rWbaVNzdnnzHW/Pdy40Q7l6c75Z+43qghvm7RbjpLP2edy7 nus7bms1mzPorTNdzvPttqVd/LXZXzj6NFmTR04xjDmOnLYcmrtFdno8gbwAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAB//9oACAECAAEFAPr91wHn8D3X1JAAqpLU5zjgqff796c4cWpX BYY79jnOJ/Y9j9uTxndc7qT6kgY1Rx/IYPUV9/IudxnYECgIL55F48i4GBJpwTVQC4xHDA04IcE/ zI5HjXDEYZkYOy52b6Pvic8J/eBAB4xgmBgQAeMceMc+IcOhYqgBC8HxLgXgrMLhmCQgDfQYlh78 Ath7HPb04ya8nCinDJThiMETjSOcMCBx97wM6rnjXAOPwXPGdhnfO+djnY52OdznY53ztnJwMcB5 +6OE8/VHt90/qATnTOmdM6Z1zrnXOudTnU4FP3TDnOvsF/G0DZ1fjq5PV+Ar89W4qHOAU7A1OOz9 2NTjeQ4WcDtTgl+vNMJoc7V4BpjBu4DjGLcA0GKX6dq4O4xPZfxv/9oACAEDAAEFAPr9T+C6n1A5 wzICpxhPK/gFTjBzy0wcMjiJ1GcZT+vuepzqePUAnFmecA/icI4PoY+3ibPGeOhDNEgiZzxPyIuc KMAI8qIsSJsRSZQiXKmbAfzB4Pc4KnA4zgNnUZxh/of3/AZ7ZTjn0NCT5ThsTjULMKkHynjztzOi qGoWDPyPO3JfkPUsBUgGhK/QACn25IGDjPfPfCTjtwM7EYKtgqcNRiuM4B++5OdjndsJ5/B8ZxnG cZx6cZxnHpxnXn77n6XOEe33I9OM5Gc5znOc5znOc5z6c5z90M5zn8bIrnafPaYHefJeZHZOYmYB MuhWIxEQzURGJ4hiqhbrHkBO3WPAElBWILLLEZRMshxVXkiRDLPv1jhEzjkFvxv/2gAIAQEAAQUA /wCW7Fazw/t6SfX/AG0bn1V71fWuXE7zqaVWQWyMZ3nUjYmUVgwG1JsW82VNmbkbkTg2x5tm3hSe wrznZKilFmEqjqt5svyJ4bIGXakxbYmhVgw/Ia9jclfb9qoLK/B0reePoqXk66jGevr0FNua0ScD WWvr0FBr3WclKp8SqH4beCUKeX4b+I67jY2ZGszrO8NWDq+3FqZPUczaFKQtKrr46gz13sm1IF0U Iv4Vm6idu5/iTx6B/wD5CqnLchNS4pL9rXrQNn6C3M/4siuPsCAQqhR0UH8I7hAdgDJ1SuMMDdMD g+rNxgGNyMhxZ0QofKox3nIb9/Pb/r9FTrf7Q7kRlaCSDZdpjbHm19sVeOwFmmxNyu3Ji7rNU2J0 bXszOu3Jj5kD/In3oSEnsKqTslQ9kmaXnImqA0o9Bq1as/sx74MtHvh2O6/5Y3K52xKE4z8Zzjt3 VUKsuywyl1bHeTDa8ff/AL/X18Wz9nRe6tq26WTujar+A67jYjrvO3xa+Eax8sU5fd/8Za7uw1nb F169pReVvhuuVUsnxnK60Wm+zF3fY1nNDBml438E+ev2Tf0PRjxm1Xo0X5De+Fc1/wCqJ2wL1A9m pMNjOEzbvREJ75xn/eupeinkfyV1cfxFFY/TJACurjGUMAAB9hfYYOvK4zAZ2wMDnOcjOf4lgMpR gIs74MOUbKt3fX/w5GcDPeZD84z4gxvfCgOWl3XYl4XxFLt+t0TqV9As12YuEcbPuNhjSNzU61pr KdmfNhQ05CRi9Tr4Ngik/wD7XzCUts+NPlhWpttNDY94WFl3VUUbqbfMJTcq3jpfxKLkU06Mko0F U3VUUIU2psmTzdnP1nHsC1EiXm/LrhcN6AjO2B87ZyfTjKngQ/oY54zZp0WY95tQKr9sDEZzznhB wTUZ14z2wkDAQR+0gGReCS65+lAbV9ERxe8/KkZcBJuNjXR0eEqzlHXKUuCUgHnKiWcvNzsJNxsH Xo6XjR42oERVaCGXak16jZR3cHkHXo6Wg9IXm9QruchGiR1UZJ7KO70k6Pab7GavlVWHIVSp+tx6 cc4YrniYY3ZcR1zyDOzHOWwuRlKcmS8LlGytg7MOp17gHkHBwc9hhpin0fK7Spifs4Kd/wDZyZC3 OaRUU/SKV1PsHRaD48/vvZskFADgmRZsAIz3zqxwy7HoRnBzrhXDFSQuMeMVeTxjSRsb9fFsXR6Y sXXOXOO1FxG5BYDC/Y00PFS+nG67X6W8D42B0P0z1xVCj7T5E+77f+3W2TVp3nU02UUDaNIrsKo8 8wk6LQPecy+zNA90TPmR4pdJjyp0Gz3sNqTZsW8KQ2AJ+eZSdkrj3M3+WXhJiyehxKBWuSzqp5aQ mO2djnJztxnkzuc753zuMHvlPfAOPoFQ2NENiTVPSsFrnQhRPk/bfDdcXX5vLUbw68HV5azoqa9P BbWoRXUbx6kjM1gXvfVbyHWYg6jcU1qZ8VmjKFPLKANNqZpOuqxQatBKExNG12as41WMwQn02kjY dZM+OueLjOmAMPy6oqD8Yb/7bbPic7gE6bC2idkSXSPZ77PiOtUIV3SS+8VNNwKV3QZz2wwTc7CO 35GXb7SbbANG6Ku/lCvlX/FNkUp96SFA2JMS6g9TjVVMBc4AxxiVK9jjkoDQDPICGqyidfICeMFF bPNPHsoWbFwWLFKtwlVcfxqhonwZdX0+601VdBpgTpqdhDXETfW8pTTVQukQTqci+tyJ6f8ApTVK hdcCUdTxt8AgU1BQWBM46ZdW1uXGpwBrDy/ckhQNkPgGwxWFANSK3w6ysJa66txFBm2vMJU7zfbj M7Z5HpvgqMT+9b/Pxrm5BAiL5F3tVyJbXTJ2LLZRQtTgK/B5/Jk8A1HBO6TQ3pnw9ZAI64r4dVcp HXW3w9UZTV1ukm1UwWUDclEgSYg6kjlNCRWUw6Cd8aK+f4EVwwsABSBlASG3ri4IpFo9Xbs7ESgq orIftWYKDvkCu4Zu24BPXcvsbGwI4b8VO3wDukJ8ryiewsY12jPLbHmlD/z+evam2Uf5ieKe2GCb nYLuknUu7U17pGM9vsE3uxTZFKeJ/B67bnrHVCGmz3ZqgqX649VLnZ9mqCWZiTTkNYdRsgYNtVKb IXBtq2LsAEN0Vdgk1r3M9lgPkMMpYu6Os2G6hFzG+A9hCjulCSFl481nLp9oyhgdAkNrcudMGcdb xPePmFNPsRpcLaHaUNRhh0wZ11TTBpcLNei/AXs0Hpf4aeJNUqF1wJLpEFNbpRdICc9TqBqcAaw8 vwf9frqy713LcAMq4bk4Nar4YTIDrxUq7eZVK7BXGsCxqcLgjycoEk+CcMMZk+KBKxlwUkuJJSGi AfGq54kOeBOKSSYRuGfYajd+TFOi/hGqin6ZPA1XMtQnjCvkKdhn+4N/kZ6hYLrSXPDPPGmdFzxJ niQZ4kwwmc8E+BryGCSDPjy5EJjPjzwTUYdeZPxp58eefHnlNFCp0W5nrhR61YqkNp3nG4EZ0Wgp ZJA3QLfaWaptIZ/In1S86GlFmK7SrM7hCnYnNXuiYd5fIbIra1Wd9qxjPWsWSdUplLJIeVOibM3I 2JnF2JuXcIE2ZuUsjm+wZvlpvTNKjl82lmjSZpa0mLJ9HYBM70Aj1eodPGWoWE5mjzksx91VSyHU YxOrQy1ItPNqDs6xdY/GfxPr0aGzrdhrRolduDVz4zGb6pObGs/dtVgL6zeR4v54I6veFL0nrvJ9 STyXag7P8VmjKFPLHXZM1Zf7NuJskoU8urF5NsyZ3WzNXZ8vWArrCDu6um3xPVpOUwQn0tZ3EQoG UktMXVAwKFH5MgEKoUfaU5KqoUfVhRvB5T8W70Cm5fVk7o89h0saP1rait5i908m3l3dI4dhvLtb PFNbbNKfMn2puJJq0Elnuzo1N2c2tvcF9pEDbPhvOgoq7Ktny06U2FnkqrVX2FV6bs5tXbSRG3Mz XZ81/nS703Eky702Zbq77KuU16vsOaWQksuxhuodLrMz3Z0yWytDWqyWe2lFTem7SuULbSuNNi0v u7aZei6ZFX0zZ/huqz1Wk89UgppOqLrMKJpmdvjVkRqUSdQzJ/8AnL1TXp5Ja7zr8BlKRZb7v/jH Xd8fVoGOo/Suu5ZtZjTXmZTbVqGOmzSvqGma0jJWgwtTTct8Yiq6TeFNenk+C+NrMaDUcBdYi2xN qqmsZU+EzLXXszxWiq+sXsdWoyWm4WGq032YedE1XwajgeATGvElYIyJ/wAZ/9oACAECAgY/AOsa 8XKZbR1EwpwbBSGWnFz70zpvYlNbXo5GJFcseXATBfyW4LcaRrXuQbNinfVVpzTYohqEYzKJEtKb tKGZDo2tQgVzTCvQMtVBUSslU9FPE25v5oaISYfzRtGK2uW7sO5PruRkyGTju7MfknRuzRrIZO9a oNgGROJnkt7l+hdFQ6+5/YfAcKcPtKlPamI9+oqKiYf2bnq0G2ahuabGLfCp76K0nBn8Vj+XwK03 D5Iwd0uX+EobMJW6W3U0bn2qpifVbbdPiiO1RrkuRDeB+atLTj4eqpgPqrc8UYx+forXGT+M4qkv 668kHGI+HyQIfbD9tMU7Gobk9OaBtGMjRAARPxOqJI+7BCPLXyhCzm+dT9GQfIdXf//aAAgBAwIG PwDrF24sE6co9QvjwfFQteEqPenT+xCnoJ4uDgDTPCtVTWo5IuJDZY9oQtu9VttkudKY1R3YW7h4 smaSWwqqVpI5rc0eqFz1BNIDZl0LTDlk7RPlVH+ILOhc9QTSA2ZdbjTu6B+FFMLNUHRRxtuobWbu V3+QbH1RgTt/40xQvNQjdtDkk44vrqmYft291UCwguK+qY4mewI1zTZK23+KBYQXCFrCKIggSXQD BgCMZfOVsYNhp+vQsgpUN7DYnhXhKhNcntPv9VXq+Oqa/wBYm2+KF+WHeneJupiaDuqrgCJJIHO2 mkrD8O+QT83WD7T4l4+DIHdbtcbbW8XLeron/wBMY9f1WyHFtdX5dqJwXDecfVG++rkeQ09Faa8/ 9TWM+eanG0vzcaZK8EsPxPf6L92N3/VXB/tnahLwcdOUTzV7GfuA8IwVXDZ6jTnCO04FubxhiiC2 6WjtXBM9tCDH5NXkiLzDFiM0SbpjwYPDIAH7MUZ8/wDHlMwjfkzZUt+rq4ijnq7/2gAIAQEBBj8A /wDLf8cQe0o/UiCMhcLSXid/z+xMQkAIlq8dyI6lJQ9xTQLkJ5lhZSAPt925NAuQj1AeUUJqgRY1 QY3LChvsUZg8ouUIxLkr3XR6ZbTYXvs61C9g6+oTb3dqeBdlqmWC1xNM0Zg8ouVEv7qRujF6xDns QAlU2RBNY1N9sUCLGv8AMZEUiC3weN06jO5Pp8ZmEQRIvXjvUhI886nzQnMCIiGpimkRGtCc1OVj 1C473G2SE5gREQ1MVLpABiXd+y1fNRBuAAuViIHVHfb5LR+Z9Tem2KjOUREAH28U2nn1brMtcYgx LXw/FGIvgtBAEgXYY0au9HqTAi4bSFGUGJifacVMSaJnhkxQgQIyiaDPbzXTlGIEo/l2woup1OoA HgbdgUQBER/XjjfbJHQQZTaJjlYv2MEIiwDfyaxPYiGIIzH26rSeC1CosniyEgSzmJBwPyWj4T6R /KXHH7TSAI3/AHFjZMAw3LUwc4/yVz4KsZdyOgu1xiOHwb7DC/xkSax9q3ZJiEZRoEZC3wlH9Q+6 +6yMzgjLWAXFNNr0sXR6ZbTYXvs6MC1+S9brV1ZA1ZwDl2BERkKXQAlUlhdapUAWmMnK6gmaRNN1 0AJVJYXX035slo1c1kSCxANVE9SQJk9ePYngXZASIBKaZYlAE+7270/QkAA+qR3bfitUhW3bv+7a o8vUj7Zeh3FRlYktIZH45fCqcIgXTihXMHGaoERKYExhIo/SLjNBRk9Hbv8AuhjmCFo0xobi5v4f gpRZyQWUYiPO7m29a4xBiWvh+KkdI0kuD8st60NzanuLMpsGhKOkNwwUBEiTFywsKXJAUuHmFCRE Yxi0tQxtff8AiuqDTUXieJKgTAARIdmfCpzUiwMZV1ZbfJGBBkHcNIAdxxUgLkELpAj2k6rZqZIY E8vioy6dCPzP6bb0ZxciQYtLT54KPSEWD1JL6a+v4I9MxDigGBrfBBwxYUH3dhcl/sN9lgCUZMy1 Sr8YiNyUCafbeJBG77WkEEjB/wCI5sniQRu+DEON6YW+4jo9IPI33JpnmXyV1T+DytxXOz7vsFux D47vi/wfFEYFEYYfARjclhxUZ9QxlqeMdNWlvpl8ZCQiItR2bBTnGnRZxk+5+OzKOoMJ+2vc/b2l HpCLkYvtnv4qUWaUS16bcFKYjpiDZ3yUTpGmWILt204KTh2BPgoxlFzI6XbM/qbayh021O0XfhtV DpSizhxXz7t6n/b/AOqPUjHlBaprhuOeaj1AHEt7XrvUozDaQ+exqN29CZiGl+78F9OIeTOa0Hr4 LUOK6ZIFTzeF1E/9fCk9Nm8s0epGPKC1TXDcc81GUKAsXetjtdPMcxpGMS7+AQ6UgxIcEF/QZKRA diTdsB214NvQmKOumSBU83hdR+g1Pfps3lnxQhIAA/mf8Ns0acuEnv4bYOK/xyYs7M+KMCNJj7ZH 1XNlgqhP/Cf4k44fDli6yPwqqLf9kzAsVWgTdMNi5v8Agok3eXn8T1DE6ZBsN2/cjDNRB6YEgzyL YdlX27ZdQjlIZ6bt+5dSUolpFxbfv3qUG5icWZqPt3LVEGMGrE1fxKIiHJBGzoQMCSN8Wu4xXTlK NYkmTNn25BR6gHKAz03796l1COUhnpu37lITBlN6SemFq0dslCAjUM9sA2aJkwcfm8qeiEp9N9OO vM5V2qh1hHXGcbFqd+11YRfAbX23qBjEkRLm27eslITBlN6SemFq0dslGAHNFqdgZRnENKBcCTV7 n8wnMWzt3CviW+U4GNS7WxDZoRkGIdQMYkiJc23b0Or0o1PvjTbbtRjIGMQHj7anv8PFaOpFmsaJ gW3hVkT2t6Afcslmqj4WVlZV+Az+JyCcJin+NPsMSE0pMj0+nzEqqeftAk6i+JkfH7i0g4QBDgWB JI7iW+/GNbX35KgbN0wR1AAPQ5q5PxcsT9l2r8X+HNEHgvax3ErlnLixVWKbSVSBPYsu1VTC6BNd ZqV9KYAyR+mNcd10xBfJCfW5YH8uJ+QQADAW+66NXNZadWmMb0d925SMpMP0tYUq6aBchSAPNEbe KMgRGYvQsK8VETPMY6rbr2X1H5TitUC4WmRYs6BkbhwhqLarJ9SBkaGy+o/LmoxgXgRXx4oMblhQ 32KMsbBa+pN65Nw3r6j8oxR0F2bxU3kGjFxFsabvVGYLTDOw379yiTcgH7AqC5yRZ2KD2VCTXH7N /tMP4NVchUv8AJYF00TUWdCUoDV93MCDIO4aQA7jipSlEaCKWvT8VKEgBIm/d8lGU4mgZzIHDJT6 RAIIpLy2wUoGIBLNmavX0UJQDyEdBHD8SoCNTDfnkVIyBBLXkC98lGRDwAYvxRlAExIZonTsF0hp pEnUCQcfFdTlDkjRbPwooSi7iIiQCx70YAaTq1MSC9Mwo9SUYxFXEeKEYl4xOvUODDtp3IxiHNGU NAGqN452fyU6DVMjlGDFAMAWDrqEjllFgTnRSjpGqjWrXHDsQBuwf+JUBYjiVc/7ivcVdVP83aIA G7+W/XdwJMB+2uG1StDPymV8n+SjNuaVo8VLUCCG1R45t6KEYxMpGILbm7F1DZzjxQjEGUjgF1ep JwHffcqIMCNR2wqpDQTpLO/4UURGJlqGrgj1CGrpAUnDSiNTO/iEZSiREB34swWiUTEkPHej1dNi zP2fNQiA5kAbjH1RlkCUDKBET+ba66tC+g47hg3quh/cf+QR6YFrmnll9+c0CYTiT/cFpepwx7lb vog9yWHblkqR8f8A11L2lMQXwG3Yd9F7SE7P3epCq4JwuadjpwCatl/yYJyIndGYfg+kHv7HTgUI cVHk794CqqEHivcO9OC65ahr+nzPq6AfTTUCTQhtss09JAXwbtw+S1Cxt9oxBZ6Ombmb3VvmzqI1 c0Q2psMtvVRjE6TH2nbZ1KD80ry4qOmRjKI06gpEEnU10JRJjIYhTiSSJte/eokzJ0nbGimNXvL2 tV1BomZiGPNpttgvpzuTq7D67dqkDIVBjSAF+xfSkXGfF1rlIyIDR3IxEzpOHzrVRiTSIaw2CkBd j5KJmSBjA8e5Tm/vjpsoDV7C9r1dfVJc4W2P3pzQBP0oy6gzgKd5YeKYdMAfumPTUn6s4gftHqT/ APVPOL9WJaf1SZaT+2ORwtxTSAbIRDeLr6UB/jnGUwMiCHr+kvYvVe0dym1xEmO6QrE8CyjM01AH vC0znEHIyCn1Y1MB0+pA9hl5ih3H49Pqi8Jx7pHSfPv+Eu30C6vTNRGbh/3c/mS25e0dyPWiGnAG UZClg7HcbHcozBkHD3zQ6kSZGObP/pp7snfJAg8ubf8AIYKEpNKMbRwLUetNVKPTzQLSjIkNrIiK OxObV5ceBIMHjQMHPNKMXAbi4zuiGLCRiCMTc/zRyo/9jqRMoEgdHpgc0pG0qs1H07jqNWAcDpAZ EyPoEfrEDpx930TK/wC40OkC4iXzZMenE5yIrtxRjLpjRpjopyh3d63J7U30of7AoGUI/TkNLANz 3c8KDI96/wDzAbt+akYQAkIy0nex3odMwjGdiJRDuMzvvGtQgHbdZGel5yMRLR7iAXIpc6QTw7ED 0+vPQaj2mn9xD99U8zOf93Ul6MiOlHTP8pMpNd61xs+F1Hq9Hq9QRkNQciQ7OZz43RbqgPjoDmgr dt1lp60pzEoDmfSH1Gh0sw/SDQksnhqgc4TkPUhafrExZmlCJLbzio9GfX0wbkLRBOlqEl615Wdw 9mRaUpPjOWr8O5CUTp6kbSbwOcUYOARuBFcnrpwrUGiJHJpYs7AS/V3OGN3JUTETchzPSJasmBIi AP1ebpjCQ0/lm5OAoHlnu7FUN+2mNcMfuxJsKrVoLPQ7BSgIk6Q9NqKMwCTK0VKRBBMbH/ShRybY eKj0m9wfz+WamdPsLXvVlrMCBRnxdThKJDRJOduxR0gkl9MeObeijHSTMh9IXUDNpa/ao/2jyXtO h217f1ZHpiBkRlw3L6vBt+22Ck4aURqZ38QjKUSIgO/FmCiDAjUdsKqQILE4/lv/AEwRkAfczO9W 7ApaomMojVpKiDEgSo+10emBa5p5ZLTpL63Zt32B0oAGfUOkA5Yk/tAvkh1OpIz6gDajQD+2IoPP etMJCMY3LjmbCL4YSlgaBiCRohyhm9tOzIvtmhUksxD4NvPlU1Uy4Zogg44nYYstMS7cWHZ8+K5g ZOGiCDb82QviK708oyIGMoyf5UzxxcogiQcN7TjwRehpqBFC2dC13BvwQGpv238anxTghs8cMMBh XFHTIAOSQ4auWAO6xuz1VC/EIHUgYS0mmrfwtk8hUh6qpFP0yceO3eqsYMIz/cLhv7TXVxBxQ1SJ JpK1DnS8ZZ4N2ptXioGTS9wqxu3yR+m8SK5xkKHTWga1GIWW40KwEsJZfMbimY6nHL49/on+qADc 6QW3DC2bnwbVMGcg2mnL2yIYGVeUBwM3K0m7XqeFceylck5/VMd0iB91INjRadZZ6DYqc398dNlG D80bS4rXqMiQxdCJLB602ZRMZGJiNO1lOOr3tUjIvxQg2oxZmLWUiRpBjpAd+KjB+aNpcVGWoiYD agpx1e9qkZF+KEcgAvcdDvo2/qykQTEMGkOC+lxffttipAyFQY0gBfsX0pFxnxdRJmTpO2NEeoJF jXSj0yXrqBUtUjKUhp1FQGr2F7Xq6+qS5wtsV9PV+bU7bmz+xLrlqf44cPd/8qcEYR7ZnKPbme9q 3ZMKUFsBgN2xqhpcywAG1s1zERfifl4qZIJINDLufeCXC+nE3xGEfDmwQlMgAUETkcd27dfJMCZZ F7D9Mji2DVa9UIkSIDMaebinBag8ZEAA0MTuYO/cCGTREhFsIh/+QpjVGMoyL+7liCR26jluZGJ6 bhm1Bn3OAfLJ089JB/SAB25nd5KIMYuLnVfLG+bs29GbBjZ5GLcajNhhTmOHuoLkPv8AGztTEIVf +0k17Mj8qCq5pkBmvb8Dtu06jhl4XdPGVRfjl6uQnnIxxqQ3+m695I3etF76LXqc/mBu2Y3hAYSu I47d/ZdO8gBkxvjuVNTnA/1TDMnvL+v8lYyAO8/xHQmaSOqQfOUiR5rU7yPNqOJs+7hbBVkIwP5z jmIj8xzy7V/ijHpg4zLyO5r+I7ExmBEXMY54cz9pPYm6ZlqAa4PmnnI+AKpEca+a9o7lYdysF7R3 L2juXtHcqxj3BNpDZMvaO5UA7k+kP2KkR3L2x7grLURVWVl7Qmhy97efkqGnaVzVN3+xIi4BKlq9 wiZROfpQodTqm+PFaoFwnmWdCZPKaAqWkgyBA28UJyLYGhuyM9VAWfetMS5Z1qmWC+pAvgO1ACby J5pafbbDFR1yqQ9r72wQ1FtVkACNDVLHbLBCBI1HBdQSLiJYeKcXNAjrPNEkSsjoLtdPMs6+o/Lm hGJclFpA6Q5QANZVF9sEZSLAIRiXJRjEgkKEAPcRXbH4ARlpGKlCR1AY38d/wkHJm74NWvajIGr0 xayiTcgH+FIC+k+S6JPs0+OmnrxWsPpNBVn7KUGcm3AG45q9gLNkMvUuUwYHO/4JgKYyN+9MPvcg LkEIC3Ui/dWihQaoE8pxcqUpsDI+0YIdSDlgzAse9HpxjWR/MQW37dql0mFC8ZZ/jghDSBIGw7Gc 71E9MDlL6c7fJGcoiII/LbBRlC8Ta3cVMaTqLEapA48F0miKNrtu78UZdOIkJBmywp6LpRbUInm4 kKMunGLMxBtxCHUhQfmL33NsOKmZAAE8tt+Xqv0xiKHf5/0RHvjMcxNK+J/qiJ2/KHdkOpBywZgW PejADSdWpiQXpmFGcoiIAPt4qYly9Mg0d+O3FO7jphgRi7nyNU0bguozlERAB9vFSekDaLvx2rmu mYhxEufBGAHLG8i/htZN0hU3L2R1QGmpJx3Y+lFqmGJNBu3oxdwezHtqpChlLTSnrRAG7B/4f0gK AyGo5OWbs3+Ke5zNT3qqqXoyYW/mjGyYBhu+6tG5omFh/GnqkdQe5qKU8Vq1c1nevu+XgodKJacm etdt+5GQJEgwJ4jzUGnr1e6N2tv2ZS1F4atJfC7bZcF1uY0IatuZQMSfYJEZ3d1DSTplF2/3IzEz GILAD+qDT1HU2qOTbu/4fUJ/xiWm9Ma78+5aCSIi+m6MZOxPLal01WdtX5X7du5GEncIzNhktIcE 5+S0lyRl5KBg4iayoLO3oVE1JlURF6qWsnSwYdyE42KnQ8l/G3chOvN7Q1bsgGJJtECvctUbIdOp kcsO1aC+8jBAF6h3C+phbe6joJ0sXHetD/6sEYSdwhEPXd4Iwi5IuWp2J+mWkK9u5a3aERbMtt4I /wDXd5E8stx24V3KENRI0133r8Pp1MsWFu1dSUpEgFmPabV+Vkbhg5JWliCQ41Y9i1SsjIPyhyMU Ih3K6spkkRPqVKMXBENXh+KiSXNb9p++GUSBGTau/Cm7vWpxoB1Ab9vJSl1TT8unLiNqqfTgRpkz PnTdtRRnFraZj12bxXU1s0z81ODjmZuBUJuGjHSe4r6kSNNadqP0JAROB/oVohJjqd6ijIiFJFXO puD91lDqTIOkMb71KbjTIu23aiAIyGGrU/gpdWjEN5fJS4eYUJTk8YgGIxwUvpyAjO78VARIEoE+ b7UUepAjXEMXsVObhpR0juCEDcPbtU9EgIzd1HplnBqeOHyUSCCQNJ1PXfSqIIAq/K/qvqwIrSQP opaJARmXk+3yUJg8sY6d+KPTkQ76g3Yo9TqSBIcHxWjV/jfVv2/qynNw0o6R3BdMOOQknvdHquAM hj27VWmJZzXsQlA8rNIcNtiiZS/yEvq7NvLJR6kSBIRYnfjgv8pBL4bBDqAgAZXO4/PgpmEgNUn4 V3diMJkaSMLu7jD1QkRGmIMnt3LS7G4U5TIM5Ax3eS6YcchJPe66h6p5JF6dqlMXI0wNqAMDxohG ZeWf/jX/2Q== ------=_NextPart_000_003B_01C84FC4.1EDC5680-- From Wojciech@comedianet.de Sat Jan 05 15:48:16 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBFwG-00025t-2b for ccamp-archive@ietf.org; Sat, 05 Jan 2008 15:48:16 -0500 Received: from [80.50.235.174] (helo=[80.50.235.174]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JBFwF-0005Yv-4F for ccamp-archive@ietf.org; Sat, 05 Jan 2008 15:48:15 -0500 Received: by 10.92.7.100 with SMTP id aLUSWIuEvMNPy; Sat, 5 Jan 2008 21:48:52 +0100 (GMT) Received: by 192.168.112.239 with SMTP id mpltemLoYuvcWo.0085633950075; Sat, 5 Jan 2008 21:48:50 +0100 (GMT) Message-ID: <958FF898.6D44243B@comedianet.de> Date: Sat, 5 Jan 2008 21:48:47 +0100 From: "Wojciech Kikala" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: ccamp-archive@ietf.org Subject: pressoch Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 080105-0, 2008-01-05), Outbound message X-Antivirus-Status: Clean X-Spam-Score: 0.1 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Hi ccamp-archive Special Man medicine. Try it now. Special winter offers http://superpongbob.com Wojciech Kikala From GoldiemartDahl@xenu.net Sat Jan 05 16:10:16 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBGHY-0005Ki-Fo; Sat, 05 Jan 2008 16:10:16 -0500 Received: from [89.242.145.169] (helo=350e5539fc5d470) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JBGHX-00068u-32; Sat, 05 Jan 2008 16:10:15 -0500 Message-ID: <50c501c84fdf$596ff570$0301a8c0@350e5539fc5d470> From: "Dena Redmond" To: Subject: Re: Simple Application Date: Sat, 5 Jan 2008 21:09:55 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_50C1_01C84FDF.596FF570" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 2.3 (++) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 This is a multi-part message in MIME format. ------=_NextPart_000_50C1_01C84FDF.596FF570 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Your credit history does not matter to us! If you have your own business and wish IMMEDIATE ready money to spend = ANY way you like or require Extra money to give your business a boost or = need A low interest loan - NO STRINGS ATTACHED, here is best deal we can = offer you TODAY (hurry, this offer will expire TONIGHT): $41,000+ loan Hurry, when best deal is gone, it is gone. Simply fill out this = user-friendly form... Don't worry about approval, your credit will not disqualify you! http://worldvcasino.cn/ ------=_NextPart_000_50C1_01C84FDF.596FF570 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20
Your credit score does = not matter=20 to us!
=20
 
If you have your own = business and=20 want IMMEDIATE money to spend ANY way you like or wish Extra money to = give the=20 business a boost or require A low interest loan - NO STRINGS ATTACHED, = here is=20 best deal we can offer you THIS EVENING (hurry, this lot will expire=20 TODAY):
=20
 
$26,000+ = loan
 
Hurry, when best deal = is gone, it=20 is gone. Simply fill this plain form...
=20
 
Don't worry about = approval, your=20 credit score will not disqualify you!
=20
 
http://worldvcasino.cn/ ------=_NextPart_000_50C1_01C84FDF.596FF570-- From oocxuqjx@brandcomms.com Sat Jan 05 16:15:40 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBGMm-0008Cl-18; Sat, 05 Jan 2008 16:15:40 -0500 Received: from bzq-84-108-117-60.cablep.bezeqint.net ([84.108.117.60] helo=Eli) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JBGMj-0006Js-K0; Sat, 05 Jan 2008 16:15:39 -0500 Received: from [84.108.117.60] by mailhost.brandcomms.com; Sat, 4 Jan 2008 23:15:26 +0200 From: "Art Morse" To: Subject: Thermometer Date: Sat, 4 Jan 2008 23:15:26 +0200 Message-ID: <01c84f27$b049bb00$3c756c54@oocxuqjx> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Importance: Normal X-Spam-Score: 1.7 (+) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Improve your sex. woman, enjoy more time with you a longer last you. http://www.hapburge.com your complaint because you have. You know own thing," factors is that no compensation the same software feel why not," From piggery@multimavens.com Sat Jan 05 18:55:25 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBIrN-0007nY-Q9 for ccamp-archive@ietf.org; Sat, 05 Jan 2008 18:55:25 -0500 Received: from host86-141-230-169.range86-141.btcentralplus.com ([86.141.230.169] helo=dxuctme) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JBIrN-0001DT-7L for ccamp-archive@ietf.org; Sat, 05 Jan 2008 18:55:25 -0500 Message-ID: <000501c84ff6$1ef54a00$0100007f@nqwdx> From: "Santa Fischer" To: Subject: Adobe Fotoshop CS3 Extended for MAC\XP\Vista 89, Retails @ 999 (u save 909) Date: Sat, 05 Jan 2008 23:55:24 +0000 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 12.0.4210 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Score: 0.5 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 adobe dreamweaver cs3 - 59 realize voice 3.51 - 29 autodesk aliasstudio 2008 - 109 graphisoft archicad 9.0 r1 international - 69 adobe font folio 11 - 189 type xprimesoft . com in Internet Exp|orer avid newscutter xp 6.7.2 - 69 microsoft exchange server enterprise 2003 - 59 adobe audition 2.0 - 49 ms windows 2003 enterprise server - 69 stuffit deluxe 11 for mac - 29 roxio digitalmedia studio deluxe suite 7.0 - 49 autodesk autocad 2008 - 129 masterwriter 1.0 - 49 corel wordperfect office x3 standard - 49 From alycia448@esamuse.com Sat Jan 05 22:43:49 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBMQP-0001Ku-Py for ccamp-archive@megatron.ietf.org; Sat, 05 Jan 2008 22:43:49 -0500 Received: from [189.71.91.93] (helo=18971117185.user.veloxzone.com.br) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JBMQO-0004vz-MM for ccamp-archive@megatron.ietf.org; Sat, 05 Jan 2008 22:43:49 -0500 Received: from S100 ([153.138.163.44] helo=S100) by 18971117185.user.veloxzone.com.br ( sendmail 8.13.3/8.13.1) with esmtpa id 1sMQis-000PHA-XP for ccamp-archive@megatron.ietf.org; Sun, 6 Jan 2008 00:43:59 -0300 Message-ID: <67489F81.DCF9DF6D@esamuse.com> Date: Sun, 6 Jan 2008 00:43:45 -0300 From: "alycia Cardoso" User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: ccamp-archive@megatron.ietf.org Subject: verlagen Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 4.7 (++++) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Amanda told me my small penis didn't matter to her, but since I've
put on 2 inches, she has orgasms everytime we have sex! http://Plirabloons.com/
From woodrow20diana75@ml.com Sun Jan 06 00:13:17 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBNoz-0004Y8-19 for ccamp-archive@ietf.org; Sun, 06 Jan 2008 00:13:17 -0500 Received: from va-76-6-211-1.dhcp.embarqhsd.net ([76.6.211.1] helo=76.6.211.1) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JBNoy-00062F-NC for ccamp-archive@ietf.org; Sun, 06 Jan 2008 00:13:16 -0500 Message-ID: <000901c85022$02c10f85$6ffc3185@ybntpiu> From: "gearalt takashi" To: "Gail Sargent" Subject: exclusive watches, brand name quality rolex Date: Sun, 06 Jan 2008 03:26:03 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 4.4 (++++) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 Perfectly crafted luxury timepieces...the finest of products at the LOWEST prices!! http://daphnonyeaar.net/ From hart46ryohei9@searchhound.com Sun Jan 06 00:15:26 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBNr4-0005UP-Ca for ccamp-archive@ietf.org; Sun, 06 Jan 2008 00:15:26 -0500 Received: from [59.6.241.101] (helo=59.6.241.101) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JBNr3-00063O-Df for ccamp-archive@ietf.org; Sun, 06 Jan 2008 00:15:26 -0500 Message-ID: <000501c85023$04846477$4e065a94@fguyhrk> From: "jecho tove" To: "Matthew Villanueva" Subject: exclusive watches, lowest prices possible rolex Date: Sun, 06 Jan 2008 03:28:01 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 4.4 (++++) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 Perfectly crafted luxury timepieces...the finest of products at the LOWEST prices!! http://daphnonyeaar.net/ From TyreeoceanWooten@theeffort.org Sun Jan 06 03:56:39 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBRJ9-0002fD-Fw; Sun, 06 Jan 2008 03:56:39 -0500 Received: from [209.173.94.14] (helo=hp27988168272) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JBRJ9-0000Yw-5i; Sun, 06 Jan 2008 03:56:39 -0500 Received: from polyhedral by theeffort.org with SMTP id CmiVqe7yvP for ; Sun, 6 Jan 2008 02:56:50 +0600 From: "Fredric Knowles" To: Subject: If you're in the US, join your new casino paradise. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de How about the best service around? We know how to treat our players - how about a $2400 welcome bonmus when you join? After thatit's only fun and winning. How about the best service around? http://goldtowercasino.net/ From CathycollardJohn@wbztv.com Sun Jan 06 05:29:29 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBSkz-0003m7-40; Sun, 06 Jan 2008 05:29:29 -0500 Received: from 82-34-73-151.cable.ubr03.gill.blueyonder.co.uk ([82.34.73.151] helo=melpc) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JBSky-0007fz-El; Sun, 06 Jan 2008 05:29:28 -0500 Message-ID: From: "Marion Blue" To: Cc: , =20
Your credit score = doesn't matter=20 to us!
=20
 
If you have your own = business and=20 need IMMEDIATE ready money to spend ANY way you like or want Extra money = to=20 give the company a boost or require A low interest loan - NO STRINGS = ATTACHED,=20 here is our best deal we can offer you TONIGHT (hurry, this tender will = expire=20 TODAY):
=20
 
$31,000+ = loan
 
Hurry, when our deal = is gone, it=20 is gone. Simply fill this easy form...
=20
 
Don't worry about = approval, your=20 credit history will not disqualify you!
=20
 
http://worlducasino.cn/ ------=_NextPart_000_A681_01C8504F.0322F440-- From Cristin246@fag.dismay.net Sun Jan 06 07:09:44 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBUK0-00031n-If for ccamp-archive@megatron.ietf.org; Sun, 06 Jan 2008 07:09:44 -0500 Received: from host200-201-static.24-87-b.business.telecomitalia.it ([87.24.201.200]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JBUJz-0000yj-Vt for ccamp-archive@megatron.ietf.org; Sun, 06 Jan 2008 07:09:44 -0500 Received: from pc by fag.dismay.net with ASMTP id E7DA9D17 for ; Sun, 6 Jan 2008 13:10:20 +0100 Received: from pc ([183.182.84.144]) by fag.dismay.net with ESMTP id 2E69AF253E61 for ; Sun, 6 Jan 2008 13:10:20 +0100 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 6 Jan 2008 13:09:50 +0100 To: ccamp-archive@megatron.ietf.org From: "Cristin gunay" Subject: kirjavaa Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 3.3 (+++) X-Scan-Signature: bb8eae9af85e4fcfe76f325e38493bf4 VPXL has been proven to be the ONLY guaranteed product that adds inches to your dick http://www.Gheslabones.com/ From tequilla55@hotmail.com Sun Jan 06 07:39:40 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBUmy-0000o1-DL; Sun, 06 Jan 2008 07:39:40 -0500 Received: from cpc2-mapp7-0-0-cust139.nott.cable.ntl.com ([86.21.204.140] helo=mr-536feaccdba9) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JBUmx-0001cE-Ek; Sun, 06 Jan 2008 07:39:40 -0500 Received: from [86.21.204.140] by mx4.hotmail.com; , 5 Jan 2008 12:39:29 +0000 From: "Gregory Samuel" To: Subject: Navy Date: , 5 Jan 2008 12:39:29 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Aca6QQWN9MB6D3576WX84NO7P9IWCM== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Message-ID: <01c84f98$035b5680$8ccc1556@tequilla55> X-Spam-Score: 4.5 (++++) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea U won't believe! http://www.zergtoss.com reference report forever! sounds, how the Factory Gervasio said her should be pleased to But you don't just at the beach From lambros.Grout@rightstand.cside.tv Sun Jan 06 07:54:47 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBV1b-0004Aa-0f for ccamp-archive@ietf.org; Sun, 06 Jan 2008 07:54:47 -0500 Received: from host132-47-dynamic.116-80-r.retail.telecomitalia.it ([80.116.47.132]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JBV1Z-0001qt-Rv for ccamp-archive@ietf.org; Sun, 06 Jan 2008 07:54:46 -0500 Received: by 10.202.0.161 with SMTP id COXOthFYOjsVJ; Sun, 6 Jan 2008 13:54:52 +0100 (GMT) Received: by 192.168.84.82 with SMTP id eobpzDUqDZEHms.3090694293706; Sun, 6 Jan 2008 13:54:50 +0100 (GMT) Message-ID: <000e01c85063$51131a90$842f7450@sandro4f1128b8> From: "lambros Grout" To: Subject: dvhsdarh Date: Sun, 6 Jan 2008 13:54:47 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C8506B.B2D78290" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 ------=_NextPart_000_0006_01C8506B.B2D78290 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello ccamp-archive Strong man power. Prepare for winter! http://patpongshopping.com lambros Grout ------=_NextPart_000_0006_01C8506B.B2D78290 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello ccamp-archive
Strong man power. Prepare for = winter!
http://patpongshopping.com=
lambros Grout
------=_NextPart_000_0006_01C8506B.B2D78290-- From RandyapeBarnes@myjones.com Sun Jan 06 12:58:50 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBZlq-00063Y-N4; Sun, 06 Jan 2008 12:58:50 -0500 Received: from pool-71-122-120-78.tampfl.dsl-w.verizon.net ([71.122.120.78] helo=susan.home) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JBZlq-0001cC-89; Sun, 06 Jan 2008 12:58:50 -0500 Received: from diction by myjones.com with SMTP id mzn7GJLYxJ for ; Sun, 6 Jan 2008 13:00:02 +0500 From: "Billy Howard" To: , Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBdjO-0003vI-F9; Sun, 06 Jan 2008 17:12:34 -0500 Received: from [200.83.202.60] (helo=olidata623cb38) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JBdjO-0007EE-2I; Sun, 06 Jan 2008 17:12:34 -0500 Received: from melodic by sourcewatch.org with SMTP id YHVBT9YDRS for ; Sun, 6 Jan 2008 19:12:22 +0400 From: "Brady Glenn" To: , Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBep1-0003ad-M2; Sun, 06 Jan 2008 18:22:27 -0500 Received: from xdsl-87-78-107-88.netcologne.de ([87.78.107.88] helo=ml501c36c4e651) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JBep1-0008OJ-4o; Sun, 06 Jan 2008 18:22:27 -0500 Message-ID: <487dd01c850ba$fdacab70$0b00a8c0@ml501c36c4e651> From: "Isidro Sheppard" To: Cc: , =20
Your credit score = doesn't matter=20 to us!
=20
 
If you have your own = business and=20 want IMMEDIATE cash to spend ANY way you like or want Extra money to = give the=20 business a boost or need A low interest loan - NO STRINGS ATTACHED, = here is=20 best deal we can offer you TODAY (hurry, this offer will expire THIS=20 NIGHT):
=20
 
$62,000+ = loan
 
Hurry, when our deal = is gone, it=20 is gone. Simply fill out this elementary form...
=20
 
Do not worry about = approval, your=20 credit score will not disqualify you!
=20
 
http://worldvcasino.cn/ ------=_NextPart_000_487D9_01C850BA.FDACAB70-- From DemierHalvar@transparenttouches.com Sun Jan 06 19:35:52 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBfy4-0002xH-I1 for ccamp-archive@ietf.org; Sun, 06 Jan 2008 19:35:52 -0500 Received: from host34-59-dynamic.26-79-r.retail.telecomitalia.it ([79.26.59.34] helo=host51-88-dynamic.17-79-r.retail.telecomitalia.it) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JBfy3-0000z6-Jb for ccamp-archive@ietf.org; Sun, 06 Jan 2008 19:35:52 -0500 Received: from pippouno by transparenttouches.com with ASMTP id 2B7C6ACA for ; Mon, 7 Jan 2008 01:36:05 +0100 Received: from pippouno ([112.149.153.133]) by transparenttouches.com with ESMTP id 5EA767FA8426 for ; Mon, 7 Jan 2008 01:36:05 +0100 Message-ID: <6F95B061.4C474858@transparenttouches.com> Date: Mon, 7 Jan 2008 01:35:44 +0100 From: "Demier Halvar" User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: ccamp-archive@ietf.org Subject: eataekaw Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 3.3 (+++) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Sex has never felt this good after my dick got thicker and longer http://trumaniac.com/
From EstellealtitudeFountain@freedomcenter.org Mon Jan 07 00:11:38 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBkGw-0004p2-7s; Mon, 07 Jan 2008 00:11:38 -0500 Received: from [200.21.115.251] (helo=hogar) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JBkGv-0005Br-1a; Mon, 07 Jan 2008 00:11:37 -0500 Message-ID: <7ef401c850eb$cd9eeb60$8702a8c0@hogar> From: "Nadine Ricks" To: , =20
Your credit doesn't = matter to=20 us!
=20
 
If you have your own = business and=20 want IMMEDIATE cash to spend ANY way you like or need Extra money to = give your=20 business a boost or need A low interest loan - NO STRINGS ATTACHED, = here is=20 best deal we can offer you THIS EVENING (hurry, this deal will expire = THIS=20 NIGHT):
=20
 
$55,000+ = loan
 
Hurry, when our best = deal is=20 gone, it is gone. Simply fill out this short form...
= =20
 
Do not worry about = approval, your=20 your credit report will not disqualify you!
=20
 
http://worldvcasino.com.cn/
------=_NextPart_000_7EF0_01C850EB.CD9EEB60-- From inna@one2one.net Mon Jan 07 01:40:42 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBlf8-0007y0-BT for ccamp-archive@ietf.org; Mon, 07 Jan 2008 01:40:42 -0500 Received: from [210.18.176.228] (helo=210.18.176.228) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JBlf4-000726-2G for ccamp-archive@ietf.org; Mon, 07 Jan 2008 01:40:42 -0500 Message-ID: <000801c850f8$0468d901$285c71aa@rhbvhdje> From: "brucie hanley" To: Subject: Rolex Date: Mon, 07 Jan 2008 04:53:07 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C850F8.0463850D" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C850F8.0463850D Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Prestige replicas =20 Most popular watches Rolex Datejusts•Cartier•Hublot•Panerai =20 =20 Most popular TIFFANY & CO. JEWERLY Tiffany & CO Necklace =20 Most popular PENS Louis Vuitton Ballpoint•St Dupont Roller =20 Click here =09 =20 ------=_NextPart_000_0005_01C850F8.0463850D Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Prestige
replicas

Most popular = watches

Rolex = Datejusts•Cartier•Hublot•Panerai

=20

Most popular TIFFANY & CO. = JEWERLY

Tiffany & CO Necklace

Most popular PENS

Louis Vuitton = Ballpoint•St Dupont Roller
Click here =09
------=_NextPart_000_0005_01C850F8.0463850D-- From RenemarriedSamuel@anandtech.com Mon Jan 07 02:20:09 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBmHJ-0005TD-Pi; Mon, 07 Jan 2008 02:20:09 -0500 Received: from 81.202.156.4.dyn.user.ono.com ([81.202.156.4] helo=user05d4252f91) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JBmHJ-0007i8-EX; Mon, 07 Jan 2008 02:20:09 -0500 Received: from vermeil by anandtech.com with SMTP id qFwWsF8BzR for ; Mon, 7 Jan 2008 08:20:00 -0100 From: "Bobbi Aldrich" To: , Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBnZ2-0006z3-0t for ccamp-archive@ietf.org; Mon, 07 Jan 2008 03:42:32 -0500 Received: from avas-mr08.fibertel.com.ar ([24.232.0.221]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JBnYz-0000vZ-Mf for ccamp-archive@ietf.org; Mon, 07 Jan 2008 03:42:32 -0500 Received: from 200-127-234-16.cab.prima.net.ar ([200.127.234.16]:1841 "EHLO coloso" smtp-auth: "zoolander" rhost-flags-OK-OK-OK-FAIL) by avas-mr08.fibertel.com.ar with ESMTPA id S683553AbYAGImS; Mon, 7 Jan 2008 06:42:18 -0200 Message-ID: <3813-2200811784243619@coloso> To: "TIERRA DIGITAL" Reply-To: "Tierra Digital" From: "Tierra Digital" Subject: COMPUTADORAS COMPLETAS 2008 Date: Mon, 7 Jan 2008 05:42:43 -0300 MIME-Version: 1.0 Content-type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Fib-Al-Info: Al X-Fib-Al-MRId: 5065dbabee7368f05c277aabcf3efb67 X-Fib-Al-SA: analyzed X-Fib-Al-From: marcelo-digital_@datafull.com X-Spam-Score: 4.0 (++++) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 TIERRA DIGITAL=09 TE: 011-15-6971-7166=09 marcelo-digital@datafull=2Ecom Monitor Samsung CRT 794V Black $399 Monitor Samsung 17" LCD 732NW $725 Portaretrato Digital 7" TITAN $329 =09 Precios Finales con Factura C, entrega en local de Computacion en la zona = de Caballito,=20=0D Capital Federal=2E Argentina Las computadoras no incluyen MONITOR Aceptamos pago con Tarjetas de Credito VISA, Mastercard, American Express,= Cabal y Carta=20=0D Franca Creditos en el acto con DNI, recibo de Sueldo y un Servicio a nombre del t= itula =09 Modelo=09ATHLON FIRE Procesador=09AMD ATHLON 64 DUAL CORE 4000+ Socket AM2 BOX Motherboard=09MSI K9N6GM-V / ASUS M2N-MX, chipset nVidia nForce 430 Memoria=091GB DDR2 667 Placa de Video=09VGA nVidia GeForce 6100GS 256MB Disco R=EDgido=09Western Digital 80GB SATA2 Optico=09ReGrabadora de DVD DVDRW PHILIPS 20X Placa Red=0910/100 Sonido=098 canales Puertos=092 USB frontales + 4USB traseros KIT=09Circuit Planet 9034 NEGRO / Teclado Multimedia / Mouse Optico Garantia=0912 meses Precio Efectivo=09$ 999 CUOTAS=0912 cuotas de $105,72 Con sistema operativo Windows XP instalado y funcionando FULL, todos los p= rogramas y=20=0D utilidades=09 =09 Modelo=09CELERON SKY Procesador=09CPU INTEL CELERON D 331 2=2E66GHZ 533 Socket 775 BOX Motherboard=09ASUS P5S-MX BOX Memoria=09MEM DDR2 512MB 667MHZ Placa de Video=09VGA VIA Unichrome 256MB onboard Disco R=EDgido=09Western Digital 80GB SATA2 Optico=09ReGrabadora de DVD DVDRW PHILIPS 20X Placa Red=0910/100 Sonido=096 canales Puertos=092 USB frontales + 4USB traseros KIT=09Circuit Planet 9034 NEGRO / Teclado Multimedia / Mouse Optico Garantia=0912 meses Precio=09$ 869 CUOTAS=0912 cuotas de $92,00 Con sistema operativo Windows XP instalado y funcionando FULL, todos los p= rogramas y=20=0D utilidades=09 =09 Modelo=09PENTIUM 4 LIGHT Procesador=09CPU INTEL PENTIUM 4 3=2E0 GHz 800MHz Socket 775 (631) Motherboard=09ASUS P5S-MX BOX Memoria=09MEM DDR2 512MB 667MHZ Placa de Video=09VGA VIA Unichrome 256MB onboard Disco R=EDgido=09Western Digital 80GB SATA2 Optico=09ReGrabadora de DVD DVDRW PHILIPS 20X Placa Red=0910/100 Sonido=096 canales Puertos=092 USB frontales + 4USB traseros KIT=09Circuit Planet 9034 NEGRO / Teclado Multimedia / Mouse Optico Garantia=0912 meses Precio=09$ 930 CUOTAS=0912 cuotas de $98,42 Con sistema operativo Windows XP instalado y funcionando FULL, todos los p= rogramas y=20=0D utilidades=09 =09 Modelo=09DUAL CORE INTEL Procesador=09CPU INTEL E2140 DUAL CORE 1=2E6 1MB Socket 775 BOX Motherboard=09MSI P6NGM BOX Memoria=091GB DDR2 667 Super Talent c/disipador Placa de Video=09VGA nVidia GeForce 7150 256MB Disco R=EDgido=09Western Digital 80GB SATA2 Optico=09ReGrabadora de DVD DVDRW PHILIPS 20X Placa Red=0910/100 Sonido=098 canales Puertos=092 USB frontales + 4USB traseros KIT=09Circuit Planet 9034 NEGRO / Teclado Multimedia / Mouse Optico Garantia=0912 meses Precio=09$ 1=2E099 CUOTAS=0912 cuotas de $116,31 Con sistema operativo Windows XP instalado y funcionando FULL, todos los p= rogramas y=20=0D utilidades=09 =09 =09 Modelo=09DUAL CORE FULL Procesador=09CPU INTEL E2140 DUAL CORE 1=2E6 1MB Socket 775 BOX Motherboard=09ASUS P5S-MX BOX Memoria=091GB DDR2 667 Placa de Video=09VGA PCI-Express 256MB REALES NX8400GS MSI Disco R=EDgido=09Western Digital 250GB SATA2 Optico=09ReGrabadora de DVD DVDRW PHILIPS 20X Placa Red=0910/100 Sonido=098 canales Puertos=092 USB frontales + 4USB traseros KIT=09Circuit Planet 9034 NEGRO / Teclado Multimedia / Mouse Optico Garantia=0912 meses Precio=09$ 1=2E339 CUOTAS=0912 cuotas de $141,71 Con sistema operativo Windows XP instalado y funcionando FULL, todos los p= rogramas y=20=0D utilidades=09 =09 =09 Modelo=09CORE 2 DUO Procesador=09INTEL E4400 CORE2DUO 2=2E0 2MB Socket 775 BOX=20 Motherboard=09ASUS P5LD2-X BOX Memoria=091GB DDR2 667 Placa de Video=09VGA PCI-Express 256MB REALES NX8400GS MSI Disco R=EDgido=09Western Digital 250GB SATA2 Optico=09ReGrabadora de DVD DVDRW PHILIPS 20X Placa Red=0910/100 Sonido=098 canales Puertos=092 USB frontales + 4USB traseros KIT=09Circuit Planet 9034 NEGRO / Teclado Multimedia / Mouse Optico Garantia=0912 meses Precio=09$ 1=2E599 CUOTAS=0912 cuotas de $169,23 Con sistema operativo Windows XP instalado y funcionando FULL, todos los p= rogramas y=20=0D utilidades=09 =09 =09 Modelo=09CIRYON Procesador=09Procesador=A0Intel BOX CORE 2 DUO E6420 2=2E13 4MB Socket 775= Motherboard=09Mother=A0MSI P965 NEO (Chip=A0Intel P965- Soporta memoria ha= sta 8GB DDR II=A0800=20=0D DUAL CHANNEL -=A03 PCI - 2 PCI-Express 1X -=A08 USB -=A0PCI Express 16X) Memoria=09Memoria=A02Gb RAM DDR2 800Mhz SUPER TALENT c/disipador DUAL CHAN= NEL=20 Placa de Video=09Placa de video GeForce=A08600GT 256MB PCI Express 16x MSI= Disco R=EDgido=09Disco R=EDgido de=A0320GB SATA II 8Mb de Buffer Optico=09Regrabadora de DVD Pioneer SATA DVR-212D 18X Dual Layer Placa Red=09Placa de Red LAN 10/100/1000 Gigabit LAN Sonido=09Placa de sonido=A08 CANALES 24 Bits High Definition Onboard Puertos=092 USB frontales + 4USB traseros KIT=09Gabinete ATX 4 Bah=EDas=A0Vistuba 8030BK FULL=A04 COOLERS ADICIONALE= S y USB Frontales=2E=20=0D Fuente de 450Watts con fan de 120mm=2E Acrilico lateral=2E Entrada de USB = + Audio fronta =09MOUSE OPTICO GENIUS NS 110 NEGRO =09Teclado Genius KB-21E Garantia=0912 meses Precio=09$ 3=2E180 CUOTAS=0912 cuotas de $336,55 Con sistema operativo Windows XP instalado y funcionando FULL, todos los p= rogramas y=20=0D utilidades=09 From SalvadoradChambers@wolfram.com Mon Jan 07 07:24:20 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBr1g-00077G-8t; Mon, 07 Jan 2008 07:24:20 -0500 Received: from n03-058.lp.newplanet.cl ([200.107.68.58] helo=cristian) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JBr1f-00061q-Nq; Mon, 07 Jan 2008 07:24:20 -0500 Message-ID: <6d2001c85128$3a298380$5e01a8c0@cristian> From: "Seth Gregory" To: Subject: Get approved in 48 hours Date: Mon, 7 Jan 2008 04:24:08 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_6D1C_01C85128.3A298380" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 3.7 (+++) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 This is a multi-part message in MIME format. ------=_NextPart_000_6D1C_01C85128.3A298380 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Your your credit report does not matter to us! If you have your own business and wish IMMEDIATE money to spend ANY way = you like or require Extra money to give the company a boost or require A = low interest loan - NO STRINGS ATTACHED, here is best deal we can offer = you THIS EVENING (hurry, this deal will expire THIS NIGHT): $21,000+ loan Hurry, when the deal is gone, it is gone. Simply fill out this plain = form... Don't worry about approval, your credit history will not disqualify you! http://worldwcasino.cn/ ------=_NextPart_000_6D1C_01C85128.3A298380 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20
Your credit history = does not=20 matter to us!
=20
 
If you have your own = business and=20 need IMMEDIATE cash to spend ANY way you like or require Extra money to = give=20 your company a boost or require A low interest loan - NO STRINGS = ATTACHED,=20 here is our best deal we can offer you TONIGHT (hurry, this tender will = expire=20 TODAY):
=20
 
$38,000+ = loan
 
Hurry, when the deal = is gone, it=20 is gone. Simply fill in this elementary form...
=20
 
Don't worry about = approval, your=20 credit will not disqualify you!
=20
 
http://worldwcasino.cn/ ------=_NextPart_000_6D1C_01C85128.3A298380-- From owner-ccamp@ops.ietf.org Mon Jan 07 10:59:31 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBuNv-00063G-Aj for ccamp-archive@ietf.org; Mon, 07 Jan 2008 10:59:31 -0500 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JBuNu-0002PD-PD for ccamp-archive@ietf.org; Mon, 07 Jan 2008 10:59:31 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JBuAx-000H1T-GR for ccamp-data@psg.com; Mon, 07 Jan 2008 15:46:07 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE, MIME_QP_LONG_LINE,RDNS_NONE autolearn=no version=3.2.3 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JBuAX-000GzD-Mz for ccamp@ops.ietf.org; Mon, 07 Jan 2008 15:45:56 +0000 X-IronPort-AV: E=Sophos;i="4.24,254,1196658000"; d="scan'208,217";a="82559983" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 07 Jan 2008 10:45:42 -0500 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m07FjerI027709; Mon, 7 Jan 2008 10:45:40 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m07Fjcgx010274; Mon, 7 Jan 2008 15:45:38 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Jan 2008 10:45:18 -0500 Received: from 10.86.104.179 ([10.86.104.179]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Mon, 7 Jan 2008 15:45:17 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Mon, 07 Jan 2008 10:45:16 -0500 Subject: Re: ccamp minutes From: JP Vasseur To: "BRUNGARD, DEBORAH A, ATTLABS" , Message-ID: Thread-Topic: ccamp minutes Thread-Index: AchL3LavtAcbaFe7SBuEfoCOVPhztQACaSHQAVd8R4A= In-Reply-To: <449B2580D802A443A923DABF3EAB82AF0FE08795@OCCLUST04EVS1.ugd.att.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3282547517_729358" X-OriginalArrivalTime: 07 Jan 2008 15:45:18.0123 (UTC) FILETIME=[4D93FFB0:01C85144] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3297; t=1199720740; x=1200584740; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20ccamp=20minutes |Sender:=20 |To:=20=22BRUNGARD,=20DEBORAH=20A,=20ATTLABS=22=20,=20; bh=ZUYjEtq8jYJ6CfGJ2gqjK6hqR6j8Qfv9RjntkycdrHk=; b=ya6tzQNLLAyWT6YhBJhIgaBd2IjZB4cULV5pBEtMYqlgT3jDOfGE+oKOkQ TMRdnz+KW/A8BTbPtETDx+D2XzI/zuOhcSYwDMOZVl2b3JJQG6jJd9fnEYow PtO+Wfl51N; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 1.8 (+) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3282547517_729358 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hi, From: "BRUNGARD, DEBORAH A, ATTLABS" Date: Mon, 31 Dec 2007 14:54:07 -0500 To: Conversation: ccamp minutes Subject: RE: ccamp minutes Try this version - there were an excessive number of typos introduced in the other uploaded version: http://www3.ietf.org/proceedings/07dec/minutes/ccamp.txt And thanks to our note takers - Dimitri, Martin, and Dan! From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of BRUNGARD, DEBORAH A, ATTLABS Sent: Monday, December 31, 2007 1:41 PM To: ccamp@ops.ietf.org Subject: ccamp minutes Hi CCAMP, The minutes have been uploaded: http://www3.ietf.org/proceedings/07dec/minutes/ccamp.htm Let us know if any changes/additions. Happy 2008! Adrian and Deborah --B_3282547517_729358 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Re: ccamp minutes Hi,

From: "BRUNGARD, DEBORAH = A, ATTLABS" <dbrungard@att.com>
Date: Mon, 31 Dec 2007 14:54:07 -0500
To: <ccamp@ops.ietf.org>
Conversation: ccamp minutes
Subject: RE: ccamp minutes

Try this version - there were an excessive number of typos introd= uced in the other uploaded version:
http://w= ww3.ietf.org/proceedings/07dec/minutes/ccamp.txt
And thanks to our note take= rs - Dimitri, Martin, and Dan!

From:<= /B> owner-ccamp@ops.ietf.org [mai= lto:owner-ccamp@ops.ietf.org] On Behalf Of BRUNGARD, DEBORAH A, A= TTLABS
Sent: Monday, December 31, 2007 1:41 PM
To: ccamp@ops.ietf.org
Subject: ccamp minutes

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

--B_3282547517_729358-- From BernieheavenNolan@handheldmagazine.com Mon Jan 07 11:15:15 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBud9-0006sN-Tu; Mon, 07 Jan 2008 11:15:15 -0500 Received: from [88.230.147.79] (helo=system) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JBud9-0002r4-Ab; Mon, 07 Jan 2008 11:15:15 -0500 Received: from maya by handheldmagazine.com with SMTP id 32Kyx7fe2Y for ; Mon, 7 Jan 2008 18:15:03 -0200 From: "Adan Valentine" To: Subject: Free money free fun. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 3.5 (+++) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Our safe, secure games will get you smiling when you start seeing dollars pouring in. Free money free fun. Download our casino in 20 seconds to get $2400 richer when you join. Download our casino in 20 seconds to get $2400 richer when you join. http://worldpcasino.com.cn/ From LourdesheckCordero@tranexp.com Mon Jan 07 18:01:46 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JC0yY-0000O2-1S; Mon, 07 Jan 2008 18:01:46 -0500 Received: from [190.80.164.121] (helo=user2d22158cb3) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JC0yX-0001O7-8W; Mon, 07 Jan 2008 18:01:45 -0500 Received: from twa by tranexp.com with SMTP id s2WXVBoOF7 for ; Tue, 8 Jan 2008 00:01:39 -0100 From: "Aida Haskins" To: Subject: Multi-hand.. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 2.1 (++) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Get your bonus and walk the red carpet to winnings and fun. Huge progressive jackpots, slots, multi-hand, and single-hand blackjack. Free money free fun. Play your favorite games and get $2400 welcome bonus. http://worldpcasino.net.cn/ From cahit.Mcoleman@tashworld.zzn.com Mon Jan 07 18:56:30 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JC1pW-00038v-EQ for ccamp-archive@megatron.ietf.org; Mon, 07 Jan 2008 18:56:30 -0500 Received: from m55f8.m.pppool.de ([89.49.85.248] helo=Me2ff.m.pppool.de) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JC1pV-0002RS-TE for ccamp-archive@megatron.ietf.org; Mon, 07 Jan 2008 18:56:30 -0500 Received: by 10.210.36.14 with SMTP id ZqNbaxAaLTYBJ; Tue, 8 Jan 2008 01:06:21 +0100 (GMT) Received: by 192.168.193.213 with SMTP id jFcBCxlcXkEGKf.7108177830444; Tue, 8 Jan 2008 01:06:19 +0100 (GMT) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 8 Jan 2008 01:06:16 +0100 To: ccamp-archive@megatron.ietf.org From: "cahit Mcoleman" Subject: aileen Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8eae9af85e4fcfe76f325e38493bf4 I was always embarassed of my small cock in the Mens locker room - but not anymore http://www.Kissntellsz.com/ From akstcaccumeddatamnsdgs@accumeddata.com Mon Jan 07 22:16:44 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JC4xI-0004Dj-ON; Mon, 07 Jan 2008 22:16:44 -0500 Received: from [221.139.84.119] (helo=mycom) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JC4xH-00070S-LC; Mon, 07 Jan 2008 22:16:44 -0500 Received: from [221.139.84.119] by mail.accumeddata.com; Tue, 7 Jan 2008 12:24:44 +0900 Date: Tue, 7 Jan 2008 12:24:44 +0900 From: "Helen Jarrett" X-Mailer: The Bat! (v2.00.2) Educational Reply-To: akstcaccumeddatamnsdgs@accumeddata.com X-Priority: 3 (Normal) Message-ID: <281749107.80185059955944@accumeddata.com> To: ccamp-archive@ietf.org Subject: battlefield MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 1.9 (+) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea All types of pills which are best quality. check it out--> http://www railweather com Remove the with a . to make the url WORK. Very secure order. From ccampb24@utmem.edu Tue Jan 08 04:41:44 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCAxs-0006Ae-Mx for ccamp-archive@ietf.org; Tue, 08 Jan 2008 04:41:44 -0500 Received: from pod2.uml.lodz.pl ([212.191.195.6]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JCAxr-0005kf-SZ for ccamp-archive@ietf.org; Tue, 08 Jan 2008 04:41:44 -0500 Received: (qmail 7600 by uid 415); Tue, 8 Jan 2008 10:40:49 +0100 Date: Tue, 8 Jan 2008 10:40:49 +0200 From: Viagra Official Site To: MIME-Version: 1.0 Message-ID: <20080108114049.7602.qmail@pod2.uml.lodz.pl> Subject: RE: January 80% OFF Content-Return: allowed X-Mailer: CME-V6.5.4.3; MSN Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-AVK-Virus-Check: AVK 18.1359;2BFF1 X-Spam-Score: 3.3 (+++) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Daily News
  Monday, January 8, 2008

Today's Top Stories

Top Stories
Pharmacists

International Approvals: Isentress, Rexin-G, Vectibix
Medscape Medical News

Business of Medicine

Probe Launched Into Two Identical Hospital Deaths
Reuters Health Information

Schering Says Image Quality Hobbled Vytorin Study
Reuters Health Information 2008

Sanofi Says to Fight Class Action Bid
Reuters Health Information

Featured News CME

CME FDA Safety Changes: ADHD Drugs
Don't miss out on this News CME article due to expire soon.
News

CME POISEd to Change the Guidelines on Perioperative Use of Beta-Blockers?
Take a look at one of our most-read recent News CME articles.News
To remove your address from all Medscape mailing lists, please write to us at ccamp-archive@ietf.org.

Advertisement


Contact Us
We welcome your comments, write to us at ccamp-archive@ietf.org
Mailing Address

Attn: ccamp-archive@ietf.org
111 Eighth Ave., 7th Floor
New York, NY 10011

Support
Unsubscribe from this newsletter.
Subscribe to this newsletter.
Not a Medscape Member?
Forgot your login info?
Cannot read this newsletter? Prefer the TEXT version?
www.medscape.com/dnetext
Difficulty linking to a news story?
Need additional support?

From TyreespringtimeVelazquez@mozilla.org Tue Jan 08 06:02:57 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCCET-0005TZ-2a; Tue, 08 Jan 2008 06:02:57 -0500 Received: from 12-207-205-179.client.mchsi.com ([12.207.205.179] helo=home0dszwrg7rm) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JCCES-0007pT-PG; Tue, 08 Jan 2008 06:02:56 -0500 Received: from hydrophilic by mozilla.org with SMTP id IT04IqWiKn for ; Tue, 8 Jan 2008 05:02:40 +0600 From: "Waldo Dejesus" To: , Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCGx7-0007nf-Jg; Tue, 08 Jan 2008 11:05:21 -0500 Received: from [124.157.228.83] (helo=com4) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JCGx5-0006ou-1H; Tue, 08 Jan 2008 11:05:19 -0500 Received: from instantaneous by ubergizmo.com with SMTP id ZuJVpRoZMI for ; Tue, 8 Jan 2008 23:05:02 -0700 From: "Daphne Browne" To: Subject: Relax and have fun with poker Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 2.1 (++) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Our casino is for you and everyone else who likes to win! Huge progressive jackpots, slots, multi-hand, and single-hand blackjack. After thatit's only fun and winning. We pay you to play. http://joemcasino.com/ From owner-ccamp@ops.ietf.org Tue Jan 08 12:36:48 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCINc-0004Bn-Gt for ccamp-archive@ietf.org; Tue, 08 Jan 2008 12:36:48 -0500 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JCINc-0000l5-5x for ccamp-archive@ietf.org; Tue, 08 Jan 2008 12:36:48 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JCIFI-000OHO-AC for ccamp-data@psg.com; Tue, 08 Jan 2008 17:28:12 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [66.226.64.2] (helo=pro.abac.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JCIF7-000OFi-Qd for ccamp@ops.ietf.org; Tue, 08 Jan 2008 17:28:09 +0000 Received: from [192.168.0.131] (c-71-202-41-42.hsd1.ca.comcast.net [71.202.41.42]) (authenticated bits=0) by pro.abac.com (8.14.1/8.14.1) with ESMTP id m08HRs3h082193 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 8 Jan 2008 09:27:57 -0800 (PST) (envelope-from gregb@grotto-networking.com) Message-ID: <4783B29F.2010405@grotto-networking.com> Date: Tue, 08 Jan 2008 09:27:59 -0800 From: Greg Bernstein User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: ccamp@ops.ietf.org Subject: Moving forward with VCAT/LCAS... Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Hi CCAMPers, at the Vancouver meeting the status of the VCAT/LCAS draft was discussed and there seemed to be two possible additions to the requirements section of the draft. From the slide presentation these were: (a) Be able to set up member LSPs (and data plane LSPs -- server connections) prior to creation of VCG (Virtual Concatenation Group). (b) “Member” LSPs (data plane and control plane) can exist after a VCG using them has been removed. For those interested in VCAT/LCAS what is your opinion on these additional requirements? This is a WG draft so polling of the list is required (right Adrian?). I'll clean up the language if there is a desire to add these to the current draft. Note that these requirements may break or require rework of the current "multiple co-signaled member sets" solution in the draft. Regards Greg B. -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 From nassim617@sekula.de Tue Jan 08 13:25:10 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCJ8Q-0002MW-Ec for ccamp-archive@ietf.org; Tue, 08 Jan 2008 13:25:10 -0500 Received: from host190-31-dynamic.20-87-r.retail.telecomitalia.it ([87.20.31.190]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JCJ8P-0001p7-IM for ccamp-archive@ietf.org; Tue, 08 Jan 2008 13:25:10 -0500 Received: from pincopallino by sekula.de with ASMTP id A236452B for ; Tue, 8 Jan 2008 18:25:37 -0000 Received: from pincopallino ([145.113.157.12]) by sekula.de with ESMTP id 5711C9EA09C9 for ; Tue, 8 Jan 2008 18:25:37 -0000 X-Spam-Score: 4.9 (++++) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 040402020100070702020406 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 8 Jan 2008 18:25:14 -0000 To: ccamp-archive@ietf.org From: "nassim Krahn" Subject: sruegdir Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Please note, only 2 per day for greater girth http://www.Universallargesd.com/ srolicnu ssenhsal s{rm{t|n srereimm sruereuq ssalkuen srup-aes srevolla sresuort sreliezd s'rotavi srewonk From owner-ccamp@ops.ietf.org Tue Jan 08 14:35:17 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCKEH-0004sy-1c for ccamp-archive@ietf.org; Tue, 08 Jan 2008 14:35:17 -0500 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JCKEG-0004pC-MI for ccamp-archive@ietf.org; Tue, 08 Jan 2008 14:35:16 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JCK2n-000B1x-9b for ccamp-data@psg.com; Tue, 08 Jan 2008 19:23:25 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [63.118.34.22] (helo=hicks.ciena.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JCK2k-000B0W-9c for ccamp@ops.ietf.org; Tue, 08 Jan 2008 19:23:23 +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: Moving forward with VCAT/LCAS... Date: Tue, 8 Jan 2008 14:23:17 -0500 Message-ID: <23F9E58A916663488B3D12D1FE1A999FBD49D8@mdmxm03.ciena.com> In-Reply-To: <4783B29F.2010405@grotto-networking.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Moving forward with VCAT/LCAS... Thread-Index: AchSHHTQqCBIuQQmTUWQvXnCNtXMZQAD12Xg References: <4783B29F.2010405@grotto-networking.com> From: "Ong, Lyndon" To: "Greg Bernstein" , X-OriginalArrivalTime: 08 Jan 2008 19:23:18.0996 (UTC) FILETIME=[ECCC9140:01C8522B] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Hi Greg, As you might expect, I support adding these as requirements for the VCAT/LCAS work. Cheers, Lyndon=20 -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Greg Bernstein Sent: Tuesday, January 08, 2008 9:28 AM To: ccamp@ops.ietf.org Subject: Moving forward with VCAT/LCAS... Hi CCAMPers, at the Vancouver meeting the status of the VCAT/LCAS draft was discussed and there seemed to be two possible additions to the requirements section of the draft. From the slide presentation these were: (a) Be able to set up member LSPs (and data plane LSPs -- server connections) prior to creation of VCG (Virtual Concatenation Group). (b) "Member" LSPs (data plane and control plane) can exist after a VCG using them has been removed. For those interested in VCAT/LCAS what is your opinion on these additional requirements? This is a WG draft so polling of the list is required (right Adrian?). I'll clean up the language if there is a desire to add these to the current draft. Note that these requirements may break or require rework of the current "multiple co-signaled member sets" solution in the draft. Regards Greg B. -- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=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 From NormanromeoWest@washingtonpost.com Tue Jan 08 15:16:50 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCKsU-0002Pa-IQ; Tue, 08 Jan 2008 15:16:50 -0500 Received: from [190.42.186.253] (helo=user) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JCKsT-0005ur-RX; Tue, 08 Jan 2008 15:16:50 -0500 Received: from asteroidal by washingtonpost.com with SMTP id 8nRorp4OC6 for ; Tue, 8 Jan 2008 15:16:34 +0500 From: "Rodney Harrison" To: Cc: , Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCWUR-0001bb-AV for ccamp-archive@ietf.org; Wed, 09 Jan 2008 03:40:49 -0500 Received: from [213.144.242.226] (helo=kgkmiok) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JCWUO-0003wk-QJ for ccamp-archive@ietf.org; Wed, 09 Jan 2008 03:40:45 -0500 Message-ID: <000601c8529a$ddd19400$0100007f@gdtgre> From: "Claudio King" To: Subject: Adobe Kreative Suite 3 for MAC\XP\Vista 269, Retails @ 1799 (u save 1529) Date: Wed, 09 Jan 2008 09:39:02 +0100 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 12.0.4210 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Score: 1.4 (+) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 webeasy pro 6.0 - 39 apollo divx2dvd divx to dvd creator v3.3.0 - 29 crystal xcelsius professional v4.5 - 59 sony vegas 6 - 69 microsoft frontpage 2003 - 29 type > kunchakoem. net < in your Internet Exp1orer adobe font folio 11 - 189 borland developer studio 2006 - 149 corel painter ix for mac - 39 adobe premiere pro cs3 - 79 google sketchup pro 6 for mac - 59 adobe photoshop cs3 extended - 89 readiris pro 11.5 for mac - 39 ibm lotus smartsuite millenium edition release 9.8 - 39 adobe indesign cs3 - 79 From BobbioxTriplett@expressindia.com Wed Jan 09 04:15:18 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCX1q-0005qv-6Z; Wed, 09 Jan 2008 04:15:18 -0500 Received: from host22-74-static.24-87-b.business.telecomitalia.it ([87.24.74.22] helo=fab.homenet.telecomitalia.it) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JCX1p-0004XX-7f; Wed, 09 Jan 2008 04:15:17 -0500 Message-ID: <39d1701c852a0$23ac0460$4d01a8c0@fab> From: "Lea Smallwood" To: Subject: Great Solution for seasonal merchants Date: Wed, 9 Jan 2008 10:14:58 -0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_39D13_01C852A0.23AC0460" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 4.2 (++++) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 This is a multi-part message in MIME format. ------=_NextPart_000_39D13_01C852A0.23AC0460 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Your your credit report does not matter to us! If you have your own business and require IMMEDIATE money to spend ANY = way you like or need Extra money to give the company a boost or require = A low interest loan - NO STRINGS ATTACHED, here is our deal we can offer = you TONIGHT (hurry, this offer will expire TONIGHT): $29,000+ loan Hurry, when best deal is gone, it is gone. Simply fill in this = user-friendly form... Do not worry about approval, your credit history will not disqualify you! http://thedworld.com.cn/ ------=_NextPart_000_39D13_01C852A0.23AC0460 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20
Your your credit = report does not=20 matter to us!
=20
 
If you have your own = business and=20 want IMMEDIATE cash to spend ANY way you like or wish Extra money to = give your=20 company a boost or wish A low interest loan - NO STRINGS ATTACHED, here = is the=20 deal we can offer you THIS EVENING (hurry, this offer will expire THIS=20 NIGHT):
=20
 
$37,000+ = loan
 
Hurry, when the deal = is gone, it=20 is gone. Simply fill this plain form...
=20
 
Don't worry about = approval, your=20 credit will not disqualify you!
=20
 
http://thedworld.com.cn/ ------=_NextPart_000_39D13_01C852A0.23AC0460-- From aedf@cowboyjunkies.com Wed Jan 09 04:34:03 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCXJz-0004wc-JJ for ccamp-archive@ietf.org; Wed, 09 Jan 2008 04:34:03 -0500 Received: from [85.21.250.61] (helo=[85.21.250.61]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JCXJy-0004nF-W6 for ccamp-archive@ietf.org; Wed, 09 Jan 2008 04:34:03 -0500 Received: by 10.133.120.72 with SMTP id YVVGQjCQoGkJg; Wed, 9 Jan 2008 12:34:07 +0300 (GMT) Received: by 192.168.106.23 with SMTP id iFjLrWBbgTioLs.3397812298853; Wed, 9 Jan 2008 12:34:05 +0300 (GMT) Message-ID: <000301c852a2$c533e030$3dfa1555@Marketing> From: "aedf Hepperle" To: Subject: gnippils Date: Wed, 9 Jan 2008 12:34:02 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C852BB.EA811830" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 ------=_NextPart_000_0009_01C852BB.EA811830 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable compliments ccamp-archive Satisfaction - that all girls want, especially at long winter evenings http://superpongbob.com aedf Hepperle ------=_NextPart_000_0009_01C852BB.EA811830 Content-Type: text/html; charset="koi8-r" Content-Transfer-Encoding: quoted-printable
compliments ccamp-archive
Satisfaction - that all girls want, especially = at long=20 winter evenings
http://superpongbob.com
aedf Hepperle
------=_NextPart_000_0009_01C852BB.EA811830-- From Murilo199@uk-gemshack.co.uk Wed Jan 09 08:33:48 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCb40-0002xf-6j for ccamp-archive@ietf.org; Wed, 09 Jan 2008 08:33:48 -0500 Received: from host180-78-dynamic.51-82-r.retail.telecomitalia.it ([82.51.78.180]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JCb3w-0002H4-GG for ccamp-archive@ietf.org; Wed, 09 Jan 2008 08:33:45 -0500 Received: from desktop-b69f5bf by uk-gemshack.co.uk with ASMTP id 3841289B for ; Wed, 9 Jan 2008 14:34:17 +0100 Received: from desktop-b69f5bf ([180.147.157.177]) by uk-gemshack.co.uk with ESMTP id ACEC9FB6F5EF for ; Wed, 9 Jan 2008 14:34:17 +0100 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 9 Jan 2008 14:33:43 +0100 To: ccamp-archive@ietf.org From: "Murilo hicken" Subject: nternity Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 2.3 (++) X-Scan-Signature: 08e48e05374109708c00c6208b534009 The secret to great sex? A huge penis - doctors recommend this solution! http://hightechform.com/ nu"tzten ntkiemde ntxavier ntarabas numabuku ntolaina numud n{tr{mmy nuritna ntagigem nterport ntujrven From a_nealsy@parker.com Wed Jan 09 18:04:44 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCjyW-0003ta-B0; Wed, 09 Jan 2008 18:04:44 -0500 Received: from [124.218.82.103] (helo=h8store.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JCjyT-0003js-Hf; Wed, 09 Jan 2008 18:04:42 -0500 To: ccamp-archive@ietf.org Bcc: ldap-dir-bounces@ietf.org, sctp-impl-archive@ietf.org, i-d-announce@ietf.org X-Sender: Subject: Look Rich withRolexFrom $199, Many brands, 90% Off Original Price d7orx73rfa1 In-Reply-To: <7ca101c85192$d7e22ead$bcedbb7b@8a2dkw1> Message-ID: <1199919728.8889@parker.com> Date: Wed, 09 Jan 2008 16:02:08 -0700 Sender: Reply-To: "Al Neal" From: "Al Neal" Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 8bit X-Spam-Score: 0.1 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 ** We add 100 Latest Arrival 2008 models Watches ** /// Safe & guaranteed shopping \\\ /// Inquiries answered in 24 hours \\\ /// Over 1360 Models to choose from \\\ Swiss QualityReplica Many World famous LUXURY BRANDS Free 1 year Warranty on all Watches http://bozeludi12424.googlepages.com/index.html From RoxannetemperanceSwift@movingscam.com Wed Jan 09 18:34:17 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCkR7-0007oL-FY; Wed, 09 Jan 2008 18:34:17 -0500 Received: from [190.188.176.151] (helo=wks) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JCkR7-0004FD-0z; Wed, 09 Jan 2008 18:34:17 -0500 Received: from temperance by movingscam.com with SMTP id rpovajl9D9 for ; Wed, 9 Jan 2008 21:33:42 +0200 From: "Johnnie Dick" To: Cc: , Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCkzJ-000342-Ap for ccamp-archive@ietf.org; Wed, 09 Jan 2008 19:09:37 -0500 Received: from [77.34.20.83] (helo=77.34.20.83) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JCkzI-0004rT-Gl for ccamp-archive@ietf.org; Wed, 09 Jan 2008 19:09:37 -0500 Message-ID: <000701c8531d$07c45cd6$2bfdd197@fdhtj> From: "jarret visvanat" To: "Reed Curtis" Subject: exclusive watches, brand name quality rolex Date: Wed, 09 Jan 2008 22:22:20 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 4.4 (++++) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 The finest of products at the LOWEST prices!! http://relenonpfree.org/ From Pelham185@ericatuincentrum.fol.nl Wed Jan 09 21:15:36 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCmxD-0004Ri-WF for ccamp-archive@ietf.org; Wed, 09 Jan 2008 21:15:36 -0500 Received: from [89.155.168.187] (helo=[89.155.168.187]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JCmx5-0007Dc-9v for ccamp-archive@ietf.org; Wed, 09 Jan 2008 21:15:27 -0500 Received: from ze ([169.169.92.146] helo=ze) by [89.155.168.187] ( sendmail 8.13.3/8.13.1) with esmtpa id 1TbtSE-000XBD-EI for ccamp-archive@ietf.org; Thu, 10 Jan 2008 02:21:52 -0000 Message-ID: <000501c8532f$84f66e10$bba89b59@ze> From: "Pelham barrieault" To: Subject: krigerne Date: Thu, 10 Jan 2008 02:21:33 -0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C8532F.84F66E10" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 4.5 (++++) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 ------=_NextPart_000_0004_01C8532F.84F66E10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yo yo yo ccamp-archive *v*iagr*a, ci*a*lis* and all other stuff needed for a long winter http://beerpongmiami.com Pelham barrieault ------=_NextPart_000_0004_01C8532F.84F66E10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Yo yo yo ccamp-archive
*v*iagr*a, ci*a*lis* and all other stuff = needed for a=20 long winter
http://beerpongmiami.com
Pelham barrieault
------=_NextPart_000_0004_01C8532F.84F66E10-- From DeenarostrumParra@anthonygatto.com Wed Jan 09 22:47:09 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCoNp-00020m-8C; Wed, 09 Jan 2008 22:47:09 -0500 Received: from ppp-99-42.telesat.com.co ([200.71.99.42] helo=bol278servidor) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JCoNn-0008Ob-78; Wed, 09 Jan 2008 22:47:08 -0500 Received: from iterate by anthonygatto.com with SMTP id 8CyvFXMInU for ; Wed, 9 Jan 2008 22:46:26 +0500 From: "Marietta Blackman" To: Subject: We give out BONUSES to anyone who joins. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Come find out. Your own privater Vegas! Get your bonus and walk the red carpet to winnings and fun. How about the best service around? http://wowacasino.com/ From EdcrampStrickland@yahoo.com Thu Jan 10 02:48:11 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCs95-0000v0-DM; Thu, 10 Jan 2008 02:48:11 -0500 Received: from [60.54.179.98] (helo=station49) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JCs94-0003lD-NR; Thu, 10 Jan 2008 02:48:11 -0500 Received: from chickweed by yahoo.com with SMTP id DUIwwiUiAi for ; Thu, 10 Jan 2008 15:47:58 -0800 From: "Randolph Ingram" To: , Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCsOX-0005qp-BE for ccamp-archive@ietf.org; Thu, 10 Jan 2008 03:04:09 -0500 Received: from [207.112.99.151] (helo=[207.112.99.151]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JCsOW-0003xa-Od for ccamp-archive@ietf.org; Thu, 10 Jan 2008 03:04:09 -0500 Received: from LEHRER ([157.151.166.32]:5292 "EHLO LEHRER" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by [207.112.99.151] with ESMTP id S22NIJQOJSGREKYQ (ORCPT ); Thu, 10 Jan 2008 03:04:59 -0500 Message-ID: <8D48C868.EB8F10A2@ibexadvisors.com> Date: Thu, 10 Jan 2008 03:04:24 -0500 From: "Panaite Leiviska" User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: ccamp-archive@ietf.org Subject: niap{vys Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 4.0 (++++) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 I love the fact that gaining length and thickness to my penis is
finally made so easy! http://coesutes.com/
From owner-ccamp@ops.ietf.org Thu Jan 10 04:44:12 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCtxM-0007JN-E3 for ccamp-archive@ietf.org; Thu, 10 Jan 2008 04:44:12 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JCtxK-0003JX-7k for ccamp-archive@ietf.org; Thu, 10 Jan 2008 04:44:12 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JCtjS-000KYd-3l for ccamp-data@psg.com; Thu, 10 Jan 2008 09:29:50 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [193.180.251.60] (helo=mailgw3.ericsson.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JCtjO-000KYA-TT for ccamp@ops.ietf.org; Thu, 10 Jan 2008 09:29:48 +0000 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id ED50C20870; Thu, 10 Jan 2008 10:28:13 +0100 (CET) X-AuditID: c1b4fb3c-b1f9bbb0000030cf-8e-4785e52df9e6 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 80B5E211BF; Thu, 10 Jan 2008 10:28:13 +0100 (CET) Received: from esealmw110.eemea.ericsson.se ([153.88.200.78]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Jan 2008 10:28:13 +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: Moving forward with VCAT/LCAS... Date: Thu, 10 Jan 2008 10:28:24 +0100 Message-ID: <0428AC48A879ED46A94F39D5665DF684F524E2@esealmw110.eemea.ericsson.se> In-Reply-To: <4783B29F.2010405@grotto-networking.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Moving forward with VCAT/LCAS... Thread-Index: AchSHPxCI0PYTObSTnyeKGOcZZyK4wBThRtA From: "Diego Caviglia" To: "Greg Bernstein" , X-OriginalArrivalTime: 10 Jan 2008 09:28:13.0269 (UTC) FILETIME=[1F5A8050:01C8536B] X-Brightmail-Tracker: AAAAAA== Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Hi Greg, I think are good requirements and should be included on the ID = may be not as mandatory requirements. BR Diego > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On = Behalf > Of Greg Bernstein > Sent: marted=EC 8 gennaio 2008 18.28 > To: ccamp@ops.ietf.org > Subject: Moving forward with VCAT/LCAS... >=20 > Hi CCAMPers, at the Vancouver meeting the status of the VCAT/LCAS = draft > was discussed and there seemed to be two possible additions to the > requirements section of the draft. From the slide presentation these = were: >=20 > (a) Be able to set up member LSPs (and data plane LSPs -- server > connections) prior to creation of VCG (Virtual Concatenation Group). > (b) "Member" LSPs (data plane and control plane) can exist after a VCG > using them has been removed. >=20 > For those interested in VCAT/LCAS what is your opinion on these > additional requirements? This is a WG draft so polling of the list is > required (right Adrian?). I'll clean up the language if there is a > desire to add these to the current draft. Note that these requirements > may break or require rework of the current "multiple co-signaled = member > sets" solution in the draft. >=20 > Regards >=20 > Greg B. >=20 > -- > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D > Dr Greg Bernstein, Grotto Networking (510) 573-2237 >=20 >=20 From owner-ccamp@ops.ietf.org Thu Jan 10 06:24:01 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCvVx-0001Z2-62 for ccamp-archive@ietf.org; Thu, 10 Jan 2008 06:24:01 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JCvVu-0004qY-Ul for ccamp-archive@ietf.org; Thu, 10 Jan 2008 06:24:01 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JCvOh-0002rR-NK for ccamp-data@psg.com; Thu, 10 Jan 2008 11:16:31 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [62.128.201.248] (helo=asmtp1.iomartmail.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JCvO9-0002nR-IX for ccamp@ops.ietf.org; Thu, 10 Jan 2008 11:16:16 +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 m0ABFhuo009816; Thu, 10 Jan 2008 11:15:43 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 m0ABFdNV009690; Thu, 10 Jan 2008 11:15:42 GMT Message-ID: <047701c8537a$206c67b0$0200a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "Ross Callon" , , "Scott Bradner" References: <030501c840c9$3272fd20$9200a8c0@your029b8cecfe> Subject: Draft liaison response to ITU-T on T-MPLS ring protection Date: Thu, 10 Jan 2008 11:14:56 -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.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Hi, Here is a brief draft response to the ITU-T's liaison that you can see at https://datatracker.ietf.org/documents/LIAISON/file502.pdf Any comments? Thanks, Adrian === To: ITU-T Q9/15 Cc: Steven Trowbridge, Ghani Abbas, Ross Callon, Dave Ward, Scott Bradner, CCAMP Mailing List From: IETF CCAMP Working Group Subject: Response to Your Liaison on T-MPLS Ring Protection In Response Dear Ghani, Thank you for your liaison from your Madeira interim meeting on T-MPLS Ring Protection, and for taking the time to keep us informed. At the moment, it appears that your work is limited to the MPLS forwarding plane with control from the Management Plane with coordination with MPLS OAM. As such, this work falls within the remit of the IETF's MPLS and PWE3 working groups. You will also be aware that the IAB has set up a design team to address issues in preparation of the potential cooperation between IETF and ITU-T on T-MPLS; we trust that you have appropriately consulted this team in keeping with the spirit of cooperation between the ITU-T and the IETF. At such time as your work on T-MPLS ring protection (or indeed on any aspect of T-MPLS) extends to requirements or solutions for a control plane, we request that you communicate with us early in the process so that we may ensure that the industry arrives at a single and fully compatible solution. Best regards, Adrian Farrel and Deborah Brungard IETF CCAMP Working Group Co-Chairs From owner-ccamp@ops.ietf.org Thu Jan 10 10:16:42 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCz98-000821-93 for ccamp-archive@ietf.org; Thu, 10 Jan 2008 10:16:42 -0500 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JCz97-0003ub-PD for ccamp-archive@ietf.org; Thu, 10 Jan 2008 10:16:42 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JCyxu-000IC8-S2 for ccamp-data@psg.com; Thu, 10 Jan 2008 15:05:06 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [47.129.242.57] (helo=zcars04f.nortel.com) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JCyxr-000IAo-Aw for ccamp@ops.ietf.org; Thu, 10 Jan 2008 15:05:05 +0000 Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m0AF4ve23826 for ; Thu, 10 Jan 2008 15:04: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: Moving forward with VCAT/LCAS... Date: Thu, 10 Jan 2008 10:04:55 -0500 Message-ID: <29D15BBCA340DA4D8146D38B4924FC7A10C79C24@zcarhxm0.corp.nortel.com> In-Reply-To: <4783B29F.2010405@grotto-networking.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Moving forward with VCAT/LCAS... Thread-Index: AchSHZqOG/WxMonCTbua4PzOpcZPfwBen43g References: <4783B29F.2010405@grotto-networking.com> From: "Stephen Shew" To: Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Greg, I support these requirements. In transport architecture, layers are separated and this allows a business separation of service. The relationship between the client layer (VCAT in this case) and server layer should be policy driven. That is, the setup/teardown of server layer LSPs in response to client layer requests, should not be automatically coded in a protocol/implementation, but be subject to a policy decision. An additional requirement that's similar to (a), would be to be able to use an existing LSP in response to a VCAT setup. Stephen -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Greg Bernstein Sent: January 8, 2008 12:28 To: ccamp@ops.ietf.org Subject: Moving forward with VCAT/LCAS... Hi CCAMPers, at the Vancouver meeting the status of the VCAT/LCAS draft was discussed and there seemed to be two possible additions to the requirements section of the draft. From the slide presentation these were: (a) Be able to set up member LSPs (and data plane LSPs -- server connections) prior to creation of VCG (Virtual Concatenation Group). (b) "Member" LSPs (data plane and control plane) can exist after a VCG using them has been removed. For those interested in VCAT/LCAS what is your opinion on these additional requirements? This is a WG draft so polling of the list is required (right Adrian?). I'll clean up the language if there is a desire to add these to the current draft. Note that these requirements may break or require rework of the current "multiple co-signaled member sets" solution in the draft. Regards Greg B. -- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=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 From owner-ccamp@ops.ietf.org Thu Jan 10 12:04:17 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JD0pF-0008Up-MC for ccamp-archive@ietf.org; Thu, 10 Jan 2008 12:04:17 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JD0pA-0003p5-C9 for ccamp-archive@ietf.org; Thu, 10 Jan 2008 12:04:17 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JD0hs-0001Pz-Qt for ccamp-data@psg.com; Thu, 10 Jan 2008 16:56:40 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [213.46.255.22] (helo=viefep11-int.chello.at) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JD0hV-0001Oj-M1 for ccamp@ops.ietf.org; Thu, 10 Jan 2008 16:56:29 +0000 Received: from [192.168.17.2] (really [80.56.44.70]) by viefep11-int.chello.at (InterMail vM.7.08.02.02 201-2186-121-104-20070414) with ESMTP id <20080110165613.QAHP4309.viefep11-int.chello.at@[192.168.17.2]>; Thu, 10 Jan 2008 17:56:13 +0100 Message-ID: <47864E2C.9090606@chello.nl> Date: Thu, 10 Jan 2008 17:56:12 +0100 From: Huub van Helvoort User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Greg Bernstein CC: ccamp@ops.ietf.org Subject: Re: Moving forward with VCAT/LCAS... References: <4783B29F.2010405@grotto-networking.com> In-Reply-To: <4783B29F.2010405@grotto-networking.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Hello Greg, You wrote: > Hi CCAMPers, at the Vancouver meeting the status of the VCAT/LCAS > draft was discussed and there seemed to be two possible additions to > the requirements section of the draft. From the slide presentation > these were: > > (a) Be able to set up member LSPs (and data plane LSPs -- server > connections) prior to creation of VCG (Virtual Concatenation Group). If there are more such members would they have a relation with each other? e.g. a "pool" of member LSPs for a single VCG or for multiple VCGs that exist between the same end-points. > (b) “Member” LSPs (data plane and control plane) can exist after a > VCG using them has been removed. Will they be returned to the "pool" (if the previous answer is yes). > For those interested in VCAT/LCAS what is your opinion on these > additional requirements? This is a WG draft so polling of the list is > required (right Adrian?). I'll clean up the language if there is a > desire to add these to the current draft. Note that these > requirements may break or require rework of the current "multiple > co-signaled member sets" solution in the draft. Cheers, Huub. -- ================================================================ http://www.van-helvoort.eu/ ================================================================ Always remember that you are unique...just like everyone else... From owner-ccamp@ops.ietf.org Thu Jan 10 12:27:50 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JD1C2-0007E6-K8 for ccamp-archive@ietf.org; Thu, 10 Jan 2008 12:27:50 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JD1C2-0004CB-77 for ccamp-archive@ietf.org; Thu, 10 Jan 2008 12:27:50 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JD16M-00034j-DU for ccamp-data@psg.com; Thu, 10 Jan 2008 17:21:58 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [66.226.64.2] (helo=pro.abac.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JD15z-00032w-JT for ccamp@ops.ietf.org; Thu, 10 Jan 2008 17:21:43 +0000 Received: from [192.168.0.131] (c-71-202-41-42.hsd1.ca.comcast.net [71.202.41.42]) (authenticated bits=0) by pro.abac.com (8.14.1/8.14.1) with ESMTP id m0AHLPD6011919 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Jan 2008 09:21:27 -0800 (PST) (envelope-from gregb@grotto-networking.com) Message-ID: <4786541A.2070509@grotto-networking.com> Date: Thu, 10 Jan 2008 09:21:30 -0800 From: Greg Bernstein User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Huub van Helvoort CC: ccamp@ops.ietf.org Subject: Re: Moving forward with VCAT/LCAS... References: <4783B29F.2010405@grotto-networking.com> <47864E2C.9090606@chello.nl> In-Reply-To: <47864E2C.9090606@chello.nl> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Hi Huub, I think you hit the crux of the issue. We (well I) outlined a possible solution to a particular "member sharing" scenario in the draft. Whether that is the right scenario and solution seems to be the discussion. See below for more comments. Cheers Greg B. Huub van Helvoort wrote: > Hello Greg, > > You wrote: > >> Hi CCAMPers, at the Vancouver meeting the status of the VCAT/LCAS >> draft was discussed and there seemed to be two possible additions to >> the requirements section of the draft. From the slide presentation >> these were: >> >> (a) Be able to set up member LSPs (and data plane LSPs -- server >> connections) prior to creation of VCG (Virtual Concatenation Group). > > If there are more such members would they have a relation with > each other? e.g. a "pool" of member LSPs for a single VCG or for > multiple VCGs that exist between the same end-points. --> The solution that we (okay I'll take the blame) outlined in the draft assumes that we know ahead of time that we are going to do such a thing and we setup a "call" that can contain multiple VCGs and then can throw all the "pool LSPs" into that call to be shared amongst the different VCGs under control of a modified Notify message (we didn't furnish details, just sketched how this could be done if someone really wanted to do this...) Some folks find the notion of multiple VCGs per call somewhat objectionable... > >> (b) “Member” LSPs (data plane and control plane) can exist after a >> VCG using them has been removed. > > Will they be returned to the "pool" (if the previous answer is yes). --> I don't know. I guess that they could be used for other things. In the member sharing case that we (okay I) outlined in the draft they could be either returned to the pool or torn down (i.e. the pool size could change). > >> For those interested in VCAT/LCAS what is your opinion on these >> additional requirements? This is a WG draft so polling of the list is >> required (right Adrian?). I'll clean up the language if there is a >> desire to add these to the current draft. Note that these >> requirements may break or require rework of the current "multiple >> co-signaled member sets" solution in the draft. > > Cheers, Huub. > -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 From ImeldaglareHare@christiantoday.com Thu Jan 10 15:30:06 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JD42Q-0003aO-Gm; Thu, 10 Jan 2008 15:30:06 -0500 Received: from [190.1.161.219] (helo=desktop) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JD42P-00048t-OG; Thu, 10 Jan 2008 15:30:06 -0500 Received: from intramolecular by christiantoday.com with SMTP id B13l69EAaY for ; Fri, 11 Jan 2008 03:30:28 -0100 From: "Katelyn Rudd" To: Cc: , Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JD7nd-00060R-4t; Thu, 10 Jan 2008 19:31:05 -0500 Received: from [190.157.189.60] (helo=carlos5d76f497.cable.net.co) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JD7nc-0000XB-Hi; Thu, 10 Jan 2008 19:31:05 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host22054890.fwdconcepts.com (8.13.1/8.13.1) with SMTP id jGjNmRRd81.942803.Ig3.mE4.1783606904696 for ; Thu, 10 Jan 2008 19:30:55 +0500 Message-ID: <2822301c853e9$3e01a640$3cbd9dbe@carlos5d76f497> From: "Jonathon Walton" To: Cc: , =20

When you are young and stressed = up…
When you are aged and never give up…
Even if you have no erection problems Viagra would help you to make = better=20 sex more often.
Learn More Now

------=_NextPart_000_2821F_01C853E9.3E01A640-- From yeong8@onelist.com Thu Jan 10 19:46:19 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JD82N-0001be-So for ccamp-archive@ietf.org; Thu, 10 Jan 2008 19:46:19 -0500 Received: from [189.5.230.75] (helo=bd05e64b.virtua.com.br) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JD82M-0000wP-4C for ccamp-archive@ietf.org; Thu, 10 Jan 2008 19:46:19 -0500 Message-ID: <000801c853eb$03766f78$2362d6b2@dudhjqi> From: "ferdie hon-kam" To: Subject: Christmas FREE BONUS! Date: Thu, 10 Jan 2008 22:58:55 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C853EB.03735FB5" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 3.3 (+++) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C853EB.03735FB5 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Online Casino Christmas FREE BONUS! Gamble online! Slots Black Jack Roulette Click=20 here to try asilemt.com ------=_NextPart_000_0005_01C853EB.03735FB5 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Online Casino

Christmas FREE BONUS!

Gamble online!

Slots
Black Jack
Roulette


Click here to try

------=_NextPart_000_0005_01C853EB.03735FB5-- From ratiochem.com@globalemailing.com Thu Jan 10 19:51:52 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JD87k-0007i2-5u for ccamp-archive@ietf.org; Thu, 10 Jan 2008 19:51:52 -0500 Received: from pc-169-151-46-190.cm.vtr.net ([190.46.151.169] helo=qocnatrj) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JD87j-00011d-HJ for ccamp-archive@ietf.org; Thu, 10 Jan 2008 19:51:52 -0500 Message-ID: <000801c853eb$fef5ca00$0100007f@kvbrpxq> From: "Cody Perry" To: Subject: Microsoft Vista Ultimate for 89, Retails @ 399 (You Save 310) Date: Thu, 10 Jan 2008 21:51:53 -0500 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2905 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Type 'xsoftprodepot. com' in Web Browser (please delete space and quotes) apollo divx2dvd divx to dvd creator v3.3.0 - 29 autodesk architectural desktop 2006 - 119 sony sound forge 9.0 - 49 acronis true image enterprise server 9.1.3666 - 79 adobe after effects cs3 - 69 2008 microsoft office beta for mac - 79 virtualdj 4.3 for mac - 39 creative suite 3 design premium for win - 269 sony acid pro 6 - 59 ulead mediastudio pro v8.0 with extras - 79 adobe framemaker 8.0 - 69 creative suite premium 2 - 149 You can save 77-90% here! From harroprlce@allianceomaha.com Thu Jan 10 21:07:38 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JD9J4-0000zF-Ui for ccamp-archive@megatron.ietf.org; Thu, 10 Jan 2008 21:07:38 -0500 Received: from host217-66-dynamic.22-79-r.retail.telecomitalia.it ([79.22.66.217]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JD9J4-0002IQ-6s for ccamp-archive@megatron.ietf.org; Thu, 10 Jan 2008 21:07:38 -0500 Received: from fabrizio-c3d416 ([197.116.79.55] helo=fabrizio-c3d416) by host217-66-dynamic.22-79-r.retail.telecomitalia.it ( sendmail 8.13.3/8.13.1) with esmtpa id 1PsGvs-000IPE-mt for ccamp-archive@megatron.ietf.org; Fri, 11 Jan 2008 03:08:13 +0100 Message-ID: Date: Fri, 11 Jan 2008 03:07:36 +0100 From: "Friso harrop" User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: ccamp-archive@megatron.ietf.org Subject: eenregen Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 2.6 (++) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 I stopped taking V.P,X.L after 3 months, because I didn't want to
gain more than 3 inches! http://www.clitorifarinna.com/
From owner-ccamp@ops.ietf.org Thu Jan 10 21:44:04 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JD9sJ-0007TC-Nh for ccamp-archive@ietf.org; Thu, 10 Jan 2008 21:44:04 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JD9sJ-0003vi-Be for ccamp-archive@ietf.org; Thu, 10 Jan 2008 21:44:03 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JD9iR-000D4V-46 for ccamp-data@psg.com; Fri, 11 Jan 2008 02:33:51 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE, STOX_REPLY_TYPE autolearn=no version=3.2.3 Received: from [62.128.201.249] (helo=asmtp2.iomartmail.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JD9iO-000D45-FJ for ccamp@ops.ietf.org; Fri, 11 Jan 2008 02:33:49 +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 m0B2Xinj010792 for ; Fri, 11 Jan 2008 02:33:45 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 m0B2XhWm010780 for ; Fri, 11 Jan 2008 02:33:44 GMT Message-ID: <015301c853fa$6174c0b0$0200a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: References: <4783B29F.2010405@grotto-networking.com> <29D15BBCA340DA4D8146D38B4924FC7A10C79C24@zcarhxm0.corp.nortel.com> Subject: Re: Moving forward with VCAT/LCAS... Date: Fri, 11 Jan 2008 02:33:39 -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.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Stephen, In this architecture, can a connection exist outside a call and then be designated as a connection that fulfils the service identified by the call? Thanks, Adrian ----- Original Message ----- From: "Stephen Shew" To: Sent: Thursday, January 10, 2008 3:04 PM Subject: RE: Moving forward with VCAT/LCAS... Greg, I support these requirements. In transport architecture, layers are separated and this allows a business separation of service. The relationship between the client layer (VCAT in this case) and server layer should be policy driven. That is, the setup/teardown of server layer LSPs in response to client layer requests, should not be automatically coded in a protocol/implementation, but be subject to a policy decision. An additional requirement that's similar to (a), would be to be able to use an existing LSP in response to a VCAT setup. Stephen -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Greg Bernstein Sent: January 8, 2008 12:28 To: ccamp@ops.ietf.org Subject: Moving forward with VCAT/LCAS... Hi CCAMPers, at the Vancouver meeting the status of the VCAT/LCAS draft was discussed and there seemed to be two possible additions to the requirements section of the draft. From the slide presentation these were: (a) Be able to set up member LSPs (and data plane LSPs -- server connections) prior to creation of VCG (Virtual Concatenation Group). (b) "Member" LSPs (data plane and control plane) can exist after a VCG using them has been removed. For those interested in VCAT/LCAS what is your opinion on these additional requirements? This is a WG draft so polling of the list is required (right Adrian?). I'll clean up the language if there is a desire to add these to the current draft. Note that these requirements may break or require rework of the current "multiple co-signaled member sets" solution in the draft. Regards Greg B. -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 From MillicentcloggingNaquin@webcom.com Fri Jan 11 08:34:51 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDK27-0001EN-3F; Fri, 11 Jan 2008 08:34:51 -0500 Received: from hel59-1-87-90-7-81.dsl.club-internet.fr ([87.90.7.81] helo=pc7e7d34e79fca) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JDK26-0007Ca-MA; Fri, 11 Jan 2008 08:34:50 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host23280942.webcom.com (8.13.1/8.13.1) with SMTP id nNObyBfl60.121878.2yE.0UN.9865157455791 for ; Fri, 11 Jan 2008 14:34:40 -0100 Message-ID: From: "Katheryn Lim" To: Subject: Your order approved Date: Fri, 11 Jan 2008 14:34:40 -0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_B220_01C85456.BD0437B0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d This is a multi-part message in MIME format. ------=_NextPart_000_B220_01C85456.BD0437B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable When you are young and stressed up… When you are aged and never give up… Even if you have no erection problems Viagra would help you to make = better sex more often. Learn More Now ------=_NextPart_000_B220_01C85456.BD0437B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20

When you are young and stressed = up…
When you are aged and never give up…
Even if you have no erection problems Viagra would help you to make = better=20 sex more often.
Learn More Now

------=_NextPart_000_B220_01C85456.BD0437B0-- From benji@cortellessa.org Fri Jan 11 09:03:46 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDKU6-0000zv-3Q for ccamp-archive@ietf.org; Fri, 11 Jan 2008 09:03:46 -0500 Received: from static-87-245-41-179.teleos-web.de ([87.245.41.179]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JDKU3-0007sK-HA for ccamp-archive@ietf.org; Fri, 11 Jan 2008 09:03:44 -0500 Received: by 10.24.155.238 with SMTP id aRSwlIDGzzOmK; Fri, 11 Jan 2008 15:02:11 +0100 (GMT) Received: by 192.168.151.235 with SMTP id YrXDCNMWtowrOn.3941756911516; Fri, 11 Jan 2008 15:02:09 +0100 (GMT) Message-ID: Date: Fri, 11 Jan 2008 15:02:06 +0100 From: "benji hinkle" User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: ccamp-archive@ietf.org Subject: 4957566 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 3.2 (+++) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 Do not delay, your potential for dick growth is available at just a click http://opusites.com/ From Lucio@aishantech.com Fri Jan 11 09:40:24 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDL3X-0007t4-VM for ccamp-archive@ietf.org; Fri, 11 Jan 2008 09:40:23 -0500 Received: from [151.63.71.155] (helo=[151.63.71.155]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JDL3V-0000G5-By for ccamp-archive@ietf.org; Fri, 11 Jan 2008 09:40:23 -0500 Received: from user-ac875536bb ([119.122.113.75] helo=user-ac875536bb) by [151.63.71.155] ( sendmail 8.13.3/8.13.1) with esmtpa id 1SYGUF-000UOR-FB for ccamp-archive@ietf.org; Fri, 11 Jan 2008 15:40:59 +0100 Message-ID: <000401c8545f$e4281ec0$9b473f97@userac875536bb> From: "Lucio kukovec" To: Subject: tuchtoom Date: Fri, 11 Jan 2008 15:40:20 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C85468.45EC86C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Antivirus: avast! (VPS 080110-0, 10/01/2008), Outbound message X-Antivirus-Status: Clean X-Spam-Score: 2.1 (++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ------=_NextPart_000_0009_01C85468.45EC86C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Wazzup ccamp-archive Take c/\nd*/ and become ready for 36 hours of l/\v http://welovecafe.com Lucio kukovec ------=_NextPart_000_0009_01C85468.45EC86C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Wazzup ccamp-archive
Take c/\nd*/ and become ready for 36 hours of=20 l/\v
http://welovecafe.com
Lucio kukovec
------=_NextPart_000_0009_01C85468.45EC86C0-- From RamiroadaBuchanan@americasbestfranchises.com Fri Jan 11 12:46:40 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDNxo-0007OV-F3; Fri, 11 Jan 2008 12:46:40 -0500 Received: from 198-165.203-62.cust.bluewin.ch ([62.203.165.198] helo=pc1) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JDNxn-0006pZ-VP; Fri, 11 Jan 2008 12:46:40 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host50184114.americasbestfranchises.com (8.13.1/8.13.1) with SMTP id ipAlzIRR06.381560.FLS.OKO.0640103531217 for ; Fri, 11 Jan 2008 18:46:33 -0100 Message-ID: <38c2a01c85479$ed3998d0$1e01a8c0@pc1> From: "Pat Brock" To: Subject: Your order approved Date: Fri, 11 Jan 2008 18:46:33 -0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_38C26_01C85479.ED3998D0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d This is a multi-part message in MIME format. ------=_NextPart_000_38C26_01C85479.ED3998D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable When you are young and stressed up… When you are aged and never give up… Even if you have no erection problems Viagra would help you to make = better sex more often. Learn More Now ------=_NextPart_000_38C26_01C85479.ED3998D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20

When you are young and stressed = up…
When you are aged and never give up…
Even if you have no erection problems Viagra would help you to make = better=20 sex more often.
Learn More Now

------=_NextPart_000_38C26_01C85479.ED3998D0-- From mxhsufaq@bocarosa.com Fri Jan 11 19:45:30 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDUV8-0003l9-CB; Fri, 11 Jan 2008 19:45:30 -0500 Received: from ppp145-129.adsl.forthnet.gr ([212.251.120.129] helo=giannis-pc) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JDUV7-0007QU-8m; Fri, 11 Jan 2008 19:45:30 -0500 Received: from [212.251.120.129] by eforward2.name-services.com; Sat, 11 Jan 2008 02:45:18 +0200 From: "Ellis Tripp" To: Subject: PharmacyVampire Date: Sat, 11 Jan 2008 02:45:18 +0200 Message-ID: <01c853fc$002ef300$8178fbd4@mxhsufaq> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1437 Importance: Normal X-Spam-Score: 3.7 (+++) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea We sell only United states FDA approved prescription medications through our fully licensed pharmacy. All orders are overseen by our licensed accredited medication department. http://www.visithealthzone.com investment advisory service NOT to use them). son in particular has and credible investigation data, environment. In other has many benefits. From lebennnt@gastonmazzacane.com Fri Jan 11 22:16:47 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDWrX-0001sQ-G4 for ccamp-archive@megatron.ietf.org; Fri, 11 Jan 2008 22:16:47 -0500 Received: from host53-209-dynamic.20-79-r.retail.telecomitalia.it ([79.20.209.53] helo=host36-207-dynamic.16-79-r.retail.telecomitalia.it) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JDWrW-0001Om-Tl for ccamp-archive@megatron.ietf.org; Fri, 11 Jan 2008 22:16:47 -0500 Received: from martinavincenzo ([187.162.140.48]:26024 "EHLO martinavincenzo" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by host36-207-dynamic.16-79-r.retail.telecomitalia.it with ESMTP id S22UQNANJATMFIXO (ORCPT ); Sat, 12 Jan 2008 04:17:23 +0100 Message-ID: <45824CB6.203F07F3@gastonmazzacane.com> Date: Sat, 12 Jan 2008 04:16:44 +0100 From: "Aziz leben" User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: ccamp-archive@megatron.ietf.org Subject: sigyou Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 2.1 (++) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 Belinda was charmed as I whipped out my new long dick http://www.wouoiyses.com/ From BoydleeuwenhoekClarke@findarticles.com Sat Jan 12 05:50:33 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDdwe-0001cK-R7; Sat, 12 Jan 2008 05:50:32 -0500 Received: from athedsl-184080.home.otenet.gr ([85.74.38.174] helo=fujitsusiemens) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JDdwd-0007cX-Sv; Sat, 12 Jan 2008 05:50:32 -0500 Message-ID: <33b5d01c85508$ee1e4680$4001a8c0@fujitsusiemens> From: "Courtney Mcguire" To: Cc: , =20
Your credit history = does not=20 matter to us!
=20
 
If you have your own = business and=20 require IMMEDIATE cash to spend ANY way you like or need Extra money to = give=20 the business a boost or want A low interest loan - NO STRINGS ATTACHED, = here=20 is best deal we can offer you TODAY (hurry, this lot will expire THIS=20 EVENING):
=20
 
$47,000+ = loan
 
Hurry, when our best = deal is=20 gone, it is gone. Simply complete this user-friendly form... =
=20 =20
 
Don't worry about = approval, your=20 credit will not disqualify you!
=20
 
http://thewworld.net.cn/ ------=_NextPart_000_33B59_01C85508.EE1E4680-- From HoustonfrangipaniHendricks@thepluginsite.com Sat Jan 12 08:13:16 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDgAm-0002bK-Di; Sat, 12 Jan 2008 08:13:16 -0500 Received: from frnk-590ec845.pool.einsundeins.de ([89.14.200.69] helo=avtinik) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JDgAl-0002N9-Ox; Sat, 12 Jan 2008 08:13:16 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host28941417.thepluginsite.com (8.13.1/8.13.1) with SMTP id qS9eqZmV97.757954.VAn.yjs.2860680437130 for ; Sat, 12 Jan 2008 14:13:01 -0100 Message-ID: <4e52901c8551c$e2f01810$14b2a8c0@Avtinik> From: "Jacques Cherry" To: Subject: Your health Date: Sat, 12 Jan 2008 14:13:01 -0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_4E525_01C8551C.E2F01810" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b This is a multi-part message in MIME format. ------=_NextPart_000_4E525_01C8551C.E2F01810 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable When you are young and stressed up… When you are aged and never give up… Even if you have no erection problems Viagra would help you to make = better sex more often. Learn More Now ------=_NextPart_000_4E525_01C8551C.E2F01810 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20

When you are young and stressed = up…
When you are aged and never give up…
Even if you have no erection problems Viagra would help you to make = better=20 sex more often.
Learn More Now

------=_NextPart_000_4E525_01C8551C.E2F01810-- From charles_Ordano@articulatecommunications.com.au Sat Jan 12 08:14:44 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDgCC-0005Fl-0h for ccamp-archive@ietf.org; Sat, 12 Jan 2008 08:14:44 -0500 Received: from host36-178-dynamic.3-79-r.retail.telecomitalia.it ([79.3.178.36] helo=host213-180-dynamic.21-87-r.retail.telecomitalia.it) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JDgCA-0002OU-BA for ccamp-archive@ietf.org; Sat, 12 Jan 2008 08:14:43 -0500 Received: by 10.178.219.157 with SMTP id BDunrJwheGzuh; Sat, 12 Jan 2008 14:14:41 +0100 (GMT) Received: by 192.168.214.223 with SMTP id FgiAEAjGWEINFp.3802314175623; Sat, 12 Jan 2008 14:14:39 +0100 (GMT) Message-ID: <000d01c8551d$147b3310$d5b41557@nomex0g25e7rpp> From: "charles Ordano" To: Subject: syurg Date: Sat, 12 Jan 2008 14:14:36 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C85525.763F9B10" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 ------=_NextPart_000_0005_01C85525.763F9B10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Greeting ccamp-archive ZE>< Soundzzz good http://webuygolf.com charles Ordano ------=_NextPart_000_0005_01C85525.763F9B10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Greeting ccamp-archive
ZE>< Soundzzz good
http://webuygolf.com
charles Ordano
------=_NextPart_000_0005_01C85525.763F9B10-- From mehmoodlyu@lugnutz1.com Sat Jan 12 09:49:02 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDhfS-0006je-3K for ccamp-archive@ietf.org; Sat, 12 Jan 2008 09:49:02 -0500 Received: from p54a4908d.dip0.t-ipconnect.de ([84.164.144.141]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JDhfR-00049D-Ce for ccamp-archive@ietf.org; Sat, 12 Jan 2008 09:49:02 -0500 Received: from lothar-eeyjeips ([157.158.50.133] helo=lothar-eeyjeips) by p54A4908D.dip0.t-ipconnect.de ( sendmail 8.13.3/8.13.1) with esmtpa id 1YrPQJ-000FSK-ve for ccamp-archive@ietf.org; Sat, 12 Jan 2008 15:59:35 +0100 Message-ID: <000701c8552b$b16fd4b0$8d90a454@lothareeyjeips> From: "Jumil mehmood" To: Subject: iotsebsa Date: Sat, 12 Jan 2008 15:59:12 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C85534.13343CB0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 2.5 (++) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a ------=_NextPart_000_0008_01C85534.13343CB0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Millions of dollars spent on research, and finally a penis lengthening = product that works. http://vuirlogskg.com/ ------=_NextPart_000_0008_01C85534.13343CB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Millions of dollars spent on research, and = finally a=20 penis lengthening product that works. http://vuirlogskg.com/
------=_NextPart_000_0008_01C85534.13343CB0-- From palmer@artel.com Sat Jan 12 10:08:21 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDhy7-0003t5-Gk for ccamp-archive@ietf.org; Sat, 12 Jan 2008 10:08:20 -0500 Received: from [88.248.49.165] (helo=dsl88-248-12709.ttnet.net.tr) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JDhy6-0004Sb-KR for ccamp-archive@ietf.org; Sat, 12 Jan 2008 10:08:19 -0500 Message-ID: <000601c8552c$051c4872$b7556d9b@poiqync> From: "brad sholom" To: Subject: '08 Collection of Prada Gucci Dior Chanel & More Top Designer Shoes Date: Sat, 12 Jan 2008 13:20:53 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01C8552C.051BFA6F" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 1.6 (+) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 This is a multi-part message in MIME format. ------=_NextPart_000_0003_01C8552C.051BFA6F Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Finally, the 2008 Collections are in, enjoy 70% OFF Brand Name = Shoes & Boots=20 for Men & Women from TOP Fashion Designers. Choose from a variety of = the season's hottest models from=20 Gucci, Prada, Chanel, Dior, Ugg Boots, Burberry, D&G, Dsquared & much more. VISIT Now and Save TODAY! Free International Shipping on ALL = ORDERS!=20 CLICK HERE www.streetnstrut24.com Now That's an AMAZING DEAL!=20 =20 ------=_NextPart_000_0003_01C8552C.051BFA6F Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Finally, the 2008 Collections are in, enjoy 70% OFF Brand Name = Shoes & Boots
for Men & Women from TOP Fashion Designers. Choose from a variety of = the season's
hottest models from Gucci, Prada, Chanel, = Dior, Ugg Boots, Burberry, D&G, Dsquared &
much more. VISIT = Now and Save TODAY! Free International Shipping on ALL = ORDERS!

CLICK = HERE www.streetnstrut24.com

Now That's an AMAZING DEAL!
------=_NextPart_000_0003_01C8552C.051BFA6F-- From AdrienneamericanismRaines@orangecow.org Sat Jan 12 13:22:59 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDl0V-0001HM-9Z; Sat, 12 Jan 2008 13:22:59 -0500 Received: from c-69-180-14-48.hsd1.ga.comcast.net ([69.180.14.48] helo=steve4fab76885.hsd1.ga.comcast.net) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JDl0V-0007yF-1R; Sat, 12 Jan 2008 13:22:59 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host44529336.orangecow.org (8.13.1/8.13.1) with SMTP id lRItOsUF97.476393.bp0.x6O.9649863732981 for ; Mon, 25 Jan 2010 13:23:24 +0500 Message-ID: <3f20c01ca9deb$7f6855e0$300eb445@steve4fab76885> From: "Johnnie Carlisle" To: Subject: Your order approved Date: Mon, 25 Jan 2010 13:23:24 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_3F208_01CA9DEB.7F6855E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d This is a multi-part message in MIME format. ------=_NextPart_000_3F208_01CA9DEB.7F6855E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable When you are young and stressed up… When you are aged and never give up… Even if you have no erection problems Viagra would help you to make = better sex more often. Learn More Now ------=_NextPart_000_3F208_01CA9DEB.7F6855E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20

When you are young and stressed = up…
When you are aged and never give up…
Even if you have no erection problems Viagra would help you to make = better=20 sex more often.
Learn More Now

------=_NextPart_000_3F208_01CA9DEB.7F6855E0-- From JeanninepalladiumSchmitz@silabs.com Sat Jan 12 15:45:26 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDnEM-00025A-Ly; Sat, 12 Jan 2008 15:45:26 -0500 Received: from dslb-088-078-252-085.pools.arcor-ip.net ([88.78.252.85] helo=homepc) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JDnEM-0002KH-Al; Sat, 12 Jan 2008 15:45:26 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host38943650.silabs.com (8.13.1/8.13.1) with SMTP id x36vB6Qg54.716337.VG8.Oqk.0840158254867 for ; Sat, 12 Jan 2008 21:52:38 -0100 Message-ID: <1d07501c8555d$15a16f80$2101a8c0@homepc> From: "Gale Connelly" To: , =20

When you are young and stressed = up…
When you are aged and never give up…
Even if you have no erection problems Viagra would help you to make = better=20 sex more often.
Learn More Now

------=_NextPart_000_1D071_01C8555D.15A16F80-- From Jaemi.Offet@currie-mullan.com Sat Jan 12 15:50:34 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDnJK-0007YN-4s for ccamp-archive@megatron.ietf.org; Sat, 12 Jan 2008 15:50:34 -0500 Received: from [189.12.212.247] (helo=18912212247.user.veloxzone.com.br) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JDnJJ-0002Pb-6V for ccamp-archive@megatron.ietf.org; Sat, 12 Jan 2008 15:50:34 -0500 Received: from micro-896fbe46f ([114.118.3.143]:13248 "EHLO micro-896fbe46f" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by 18912212247.user.veloxzone.com.br with ESMTP id S22FHZRTSWTAMUHU (ORCPT ); Sat, 12 Jan 2008 17:16:41 -0200 Message-ID: <000801c8554f$942ddc70$f7d40cbd@micro896fbe46f> From: "Jaemi Offet" To: Subject: 1lians Date: Sat, 12 Jan 2008 17:16:05 -0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C8553E.D0A50C70" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a ------=_NextPart_000_0006_01C8553E.D0A50C70 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I love how she comes every time we have sex now, thanks to my huge cock. = http://www.vbuwee.com/ ------=_NextPart_000_0006_01C8553E.D0A50C70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I love how she comes every time we have sex = now,=20 thanks to my huge cock. http://www.vbuwee.com/
------=_NextPart_000_0006_01C8553E.D0A50C70-- From ValarierebeccaSteiner@creativecommons.org Sat Jan 12 16:12:28 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDneV-0006i5-Qc; Sat, 12 Jan 2008 16:12:28 -0500 Received: from cm-83-97-238-153.telecable.es ([83.97.238.153] helo=casa) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JDneT-0002k6-UR; Sat, 12 Jan 2008 16:12:26 -0500 Message-ID: <6e6ad01c8555f$cf0aba60$99ee6153@casa> From: "Greta Kauffman" To: Subject: Guaranteed rate over the life of your loan Date: Sat, 12 Jan 2008 22:11:56 -0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_6E6A9_01C8555F.CF0ABA60" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 4.6 (++++) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 This is a multi-part message in MIME format. ------=_NextPart_000_6E6A9_01C8555F.CF0ABA60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Your credit doesn't matter to us! If you have your own business and want IMMEDIATE money to spend ANY way = you like or want Extra money to give the company a boost or want A low = interest loan - NO STRINGS ATTACHED, here is best deal we can offer you = TODAY (hurry, this lot will expire TODAY): $30,000+ loan Hurry, when best deal is gone, it is gone. Simply fill out this = one-minute form... Do not worry about approval, your credit score will not disqualify you! http://thexworld.com.cn/ ------=_NextPart_000_6E6A9_01C8555F.CF0ABA60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20
Your credit score = doesn't matter=20 to us!
=20
 
If you have your own = business and=20 need IMMEDIATE cash to spend ANY way you like or require Extra money to = give=20 the business a boost or require A low interest loan - NO STRINGS = ATTACHED,=20 here is our deal we can offer you TODAY (hurry, this offer will expire = THIS=20 NIGHT):
=20
 
$55,000+ = loan
 
Hurry, when our deal = is gone, it=20 is gone. Simply fill in this plain form...
=20
 
Do not worry about = approval, your=20 credit will not disqualify you!
=20
 
http://thexworld.com.cn/ ------=_NextPart_000_6E6A9_01C8555F.CF0ABA60-- From edgar@umail.leiden.univ.nl Sat Jan 12 17:21:31 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDojL-0002og-9E for ccamp-archive@ietf.org; Sat, 12 Jan 2008 17:21:31 -0500 Received: from [213.77.117.7] (helo=[213.77.117.7]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JDojK-00040K-T6 for ccamp-archive@ietf.org; Sat, 12 Jan 2008 17:21:31 -0500 Received: from Karolina ([117.189.52.75]:30126 "EHLO Karolina" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by [213.77.117.7] with ESMTP id S22IYWBYLIEXSRMS (ORCPT ); Sat, 12 Jan 2008 23:21:58 +0100 Message-ID: <000b01c85569$7e87b890$07754dd5@Karolina> From: "edgar Glien" To: Subject: 8982794 Date: Sat, 12 Jan 2008 23:21:36 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C85571.E04C2090" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Antivirus: avast! (VPS 080112-0, 2008-01-12), Outbound message X-Antivirus-Status: Clean X-Spam-Score: 1.9 (+) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 ------=_NextPart_000_0007_01C85571.E04C2090 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable Good day ccamp-archive Restarting SE>< life http://wecanchew.com edgar Glien ------=_NextPart_000_0007_01C85571.E04C2090 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
Good day ccamp-archive
Restarting SE>< life
http://wecanchew.com
edgar Glien
------=_NextPart_000_0007_01C85571.E04C2090-- From AllenchoctawCruz@kidsreads.com Sat Jan 12 19:17:22 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDqXS-0004Ze-4S; Sat, 12 Jan 2008 19:17:22 -0500 Received: from [201.244.54.51] (helo=acva.acciones) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JDqXR-0006au-O7; Sat, 12 Jan 2008 19:17:21 -0500 Received: from sprue by kidsreads.com with SMTP id 2S2ouZrn2P for ; Sat, 12 Jan 2008 19:22:04 +0500 From: "Danny Fisher" To: Subject: Download our casino in 20 seconds to get $2400 richer when you join. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Your own privater Vegas! Your own privater Vegas! Win $$$ instead of throwing it all away at other casinos. Best offer in gambling history . http://placebetscasino.com/ From KatrinaprovenPineda@nysun.com Sun Jan 13 05:05:33 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JDzif-0005d5-B9; Sun, 13 Jan 2008 05:05:33 -0500 Received: from 0x573266c8.vgnxx4.adsl-dhcp.tele.dk ([87.50.102.200] helo=mathias.opasia.dk) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JDzie-0003SH-UV; Sun, 13 Jan 2008 05:05:33 -0500 Received: from addis by nysun.com with SMTP id FllEjvCkdo for ; Sun, 13 Jan 2008 11:07:03 -0100 From: "Shelly Lovell" To: , Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JE12E-0002bg-Je for ccamp-archive@ietf.org; Sun, 13 Jan 2008 06:29:50 -0500 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JE12D-0004mB-VG for ccamp-archive@ietf.org; Sun, 13 Jan 2008 06:29:50 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JE0tJ-0002vo-NV for ccamp-data@psg.com; Sun, 13 Jan 2008 11:20:37 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-202.0 required=5.0 tests=AWL,BAYES_00,RDNS_NONE, USER_IN_ALL_SPAM_TO,USER_IN_WHITELIST autolearn=no version=3.2.3 Received: from [156.154.24.139] (helo=ns4.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JE0sl-0002tx-Nu for ccamp@ops.ietf.org; Sun, 13 Jan 2008 11:20:22 +0000 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 755852AC92; Sun, 13 Jan 2008 11:20:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1JE0sk-0007Ef-85; Sun, 13 Jan 2008 06:20:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D Action:draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-05.txt Message-Id: Date: Sun, 13 Jan 2008 06:20:02 -0500 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 --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 MPLS-TE to GMPLS migration Author(s) : K. Shiomoto, et al. Filename : draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-05.txt Pages : 19 Date : 2008-01-13 The migration from Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) to Generalized MPLS (GMPLS) is the process of evolving an MPLS-TE control plane to a GMPLS control plane. An appropriate migration strategy will be selected based on various factors including the service provider's network deployment plan, customer demand, and operational policy. This document presents several migration models and strategies for migrating from MPLS-TE to GMPLS. In the course of migration, MPLS-TE and GMPLS devices, or networks, may coexist which may require interworking between MPLS-TE and GMPLS protocols. Aspects of the interworking required are discussed as it will influence the choice of a migration strategy. This framework document provides a migration toolkit to aid the operator in selection of an appropriate strategy. This framework document also lists a set of solutions that may aid in interworking, and highlights a set of potential issues. Shiomoto et al. [page 1] draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-05 January 2008 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2008-01-13061248.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-01-13061248.I-D\@ietf.org> --OtherAccess-- --NextPart-- From owner-ccamp@ops.ietf.org Sun Jan 13 06:31:08 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JE13U-00031K-8i for ccamp-archive@ietf.org; Sun, 13 Jan 2008 06:31:08 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JE13S-0005K6-Ma for ccamp-archive@ietf.org; Sun, 13 Jan 2008 06:31:08 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JE0yp-0003Hh-69 for ccamp-data@psg.com; Sun, 13 Jan 2008 11:26:19 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE, STOX_REPLY_TYPE autolearn=no version=3.2.3 Received: from [62.128.201.249] (helo=asmtp2.iomartmail.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JE0yh-0003H8-U1 for ccamp@ops.ietf.org; Sun, 13 Jan 2008 11:26:17 +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 m0DBPqc9002341; Sun, 13 Jan 2008 11:25:53 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 m0DBPoOE002320; Sun, 13 Jan 2008 11:25:52 GMT Message-ID: <04ea01c855d7$0b510d90$0200a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "Ross Callon" , , , "Kohei Shiomoto" , "Brungard, Deborah A, ALABS" Subject: draft-ietf-ccamp-mpls-gmple-framework updated after IESG review Date: Sun, 13 Jan 2008 11:25:43 -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.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Hi, Changes are below (as approved by the IESG). Thanks, Adrian == Section 4.3 Replace final paragraph OLD Interoperability concerns, though, are exacerbated by this migration model, unless all LSRs in the network are updated simultaneously and there is a clear understanding of which subset of features are to be included in the hybrid LSRs. Interworking between a hybrid LSR and an unchanged MPLS LSR would put the hybrid LSR in the role of a GMPLS LSR as described in the previous sections and puts the unchanged LSR in the role of an MPLS LSR. The potential for different hybrids within the network will complicate matters considerably. NEW Interoperability concerns though are exacerbated by this migration model, unless all LSRs in the network are updated simultaneously and there is a clear understanding of which subset of features are to be included in the hybrid LSRs. Interworking between a hybrid LSR and an unchanged MPLS LSR would put the hybrid LSR in the role of a GMPLS LSR as described in the previous sections and puts the unchanged LSR in the role of an MPLS LSR. The potential for different hybrids within the network will complicate matters considerably. This model is, therefore, only appropriate for use when the set of new features to be deployed is well known and limited, and where there is a clear understanding of and agreement on this set of features by the network operators of the ISP(s) involved as well as all vendors whose equipment will be involved in the migration. === Section 5 Update 4th paragraph OLD The second strategy for PSC and non-PSC networks is to migrate from the PSC network to GMPLS, first, and then enable GMPLS within the non-PSC network. The PSC network is migrated as described before, and when the entire PSC network is completely converted to GMPLS, GMPLS- based non-PSC devices and networks may be introduced without any issues of interworking between MPLS and GMPLS. NEW The second strategy is to migrate the PSC network to GMPLS first, and then enable GMPLS within the non-PSC network. The PSC network is migrated as described before, and when the entire PSC network is completely converted to GMPLS, GMPLS-based non-PSC devices and networks may be introduced without any issues of interworking between MPLS and GMPLS. === Section 5.1.4 New section ADD 5.1.4. Path Computation Element The Path Computation Element (PCE) [RFC4655] may provide an additional tool to aid MPLS to GMPLS migration. If a layered network approach (Section 5.1.1) is used, PCEs may be used to facilitate the computation of paths for LSPs in the different layers [PCE-INTER-LAYER]. === Section 12.2 Add new references ADD [RFC4655] A. Farrel, JP. Vasseur and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006. [PCE-INTER-LAYER] Oki, E., Le Roux , J-L,. and Farrel, A., "Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic Engineering," draft-ietf-pce-inter-layer-frwk, work in progress. === From darla_mcGheegn@szsti.net Sun Jan 13 08:00:37 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JE2S4-0000E1-VJ; Sun, 13 Jan 2008 08:00:37 -0500 Received: from [41.250.43.97] (helo=mail.wplus.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JE2Rz-0006Uz-L7; Sun, 13 Jan 2008 08:00:36 -0500 In-Reply-To: <3e0601c8504a$1ee0de53$e9b49ced@dxy6lfl> From: "Darla McGhee" X-Sender: Message-ID: <1200235109.1923@szsti.net> Reply-To: "Darla McGhee" Subject: Order CheapViagraCailis with 80% saving p03cay3eccqqx24uk11 To: hubmib-bounces@ietf.org Bcc: ccamp-archive@ietf.org, iptel@ietf.org, dhcwg-bounces@ietf.org, l2tpext-request@ietf.org, mpls@ietf.org Sender: Date: Sun, 13 Jan 2008 07:38:29 -0700 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 8bit X-Spam-Score: 3.0 (+++) X-Scan-Signature: 93238566e09e6e262849b4f805833007 -* Pharmacy Meds For You *- XamaxCailisValiumVaigra Men's Health Sexual Health Fast Acting S0FTtabs Pain Relief Anti Anxiety WeightL0SS Sleeping Aid Muscle Relaxants Anti Depressants Cholesterol Diabetes Quit Smoking Allergy Relief Heartburn Relief Greatest discount on net, only from us http://dycuhaxe67274.googlepages.com/index.html From Ramin.janeen@stuttgarter-liederkranz.de Sun Jan 13 09:17:20 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JE3eK-0006Y6-Er for ccamp-archive@megatron.ietf.org; Sun, 13 Jan 2008 09:17:20 -0500 Received: from host2-187-dynamic.6-87-r.retail.telecomitalia.it ([87.6.187.2] helo=host253-191-dynamic.2-79-r.retail.telecomitalia.it) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JE3eJ-0007qO-Ns for ccamp-archive@megatron.ietf.org; Sun, 13 Jan 2008 09:17:20 -0500 Received: from pc-comtel ([125.155.71.8]:24514 "EHLO pc-comtel" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by host253-191-dynamic.2-79-r.retail.telecomitalia.it with ESMTP id S22TNYFZDMFRNLOE (ORCPT ); Sun, 13 Jan 2008 15:17:50 +0100 Message-ID: <000501c855ef$00fceea0$fdbf024f@pccomtel> From: "Ramin janeen" To: Subject: ikiuoh Date: Sun, 13 Jan 2008 15:17:18 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C855F7.62C156A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 2.1 (++) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a ------=_NextPart_000_0008_01C855F7.62C156A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Make your dreams a reality, have a monster size cock. = http://www.vnieennv.com/ ------=_NextPart_000_0008_01C855F7.62C156A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Make your dreams a reality, have a monster size = cock.=20 http://www.vnieennv.com/
------=_NextPart_000_0008_01C855F7.62C156A0-- From owner-ccamp@ops.ietf.org Sun Jan 13 11:22:25 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JE5bN-0002II-AK for ccamp-archive@ietf.org; Sun, 13 Jan 2008 11:22:25 -0500 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JE5bM-00026U-My for ccamp-archive@ietf.org; Sun, 13 Jan 2008 11:22:25 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JE5Pv-000NeH-46 for ccamp-data@psg.com; Sun, 13 Jan 2008 16:10:35 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-202.0 required=5.0 tests=AWL,BAYES_00,RDNS_NONE, USER_IN_ALL_SPAM_TO,USER_IN_WHITELIST autolearn=no version=3.2.3 Received: from [156.154.16.158] (helo=ns0.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JE5PP-000Nbj-KJ for ccamp@ops.ietf.org; Sun, 13 Jan 2008 16:10:20 +0000 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 16E5832960; Sun, 13 Jan 2008 16:10:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1JE5PN-00064M-Ov; Sun, 13 Jan 2008 11:10:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D Action:draft-ietf-ccamp-mpls-gmpls-interwork-reqts-04.txt Message-Id: Date: Sun, 13 Jan 2008 11:10:01 -0500 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 --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 : Interworking Requirements to Support operation of MPLS-TE over GMPLS Networks Author(s) : K. Kumaki, et al. Filename : draft-ietf-ccamp-mpls-gmpls-interwork-reqts-04.txt Pages : 13 Date : 2008-01-13 Operation of a Multiprotocol Label Switching (MPLS) traffic engineering (TE) network as a client network to a Generalized MPLS (GMPLS) network has enhanced operational capabilities compared to those provided by a co-existent protocol model (i.e., operation of MPLS-TE over an independently managed transport layer). The GMPLS network may be a packet or a non-packet network, and may itself be a multi-layer network supporting both packet and non-packet technologies. A MPLS-TE Label Switched Path (LSP) originates and terminates on an MPLS Label Switching Router (LSR). The GMPLS network provides transparent transport for the end-to-end MPLS-TE LSP. This document describes a framework and Service Provider requirements for operating MPLS-TE networks over GMPLS networks. K.Kumaki et al. [page 1] draft-ietf-ccamp-mpls-gmpls-interwork-reqts-04 January 2008 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-mpls-gmpls-interwork-reqts-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-mpls-gmpls-interwork-reqts-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-mpls-gmpls-interwork-reqts-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2008-01-13110353.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-mpls-gmpls-interwork-reqts-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-mpls-gmpls-interwork-reqts-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-01-13110353.I-D\@ietf.org> --OtherAccess-- --NextPart-- From louisa@atomic.com Sun Jan 13 11:39:09 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JE5rZ-00054c-1j for ccamp-archive@ietf.org; Sun, 13 Jan 2008 11:39:09 -0500 Received: from [81.213.103.253] (helo=dsl.dynamic81213103253.ttnet.net.tr) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JE5rY-0002MG-7H for ccamp-archive@ietf.org; Sun, 13 Jan 2008 11:39:08 -0500 Message-ID: <000a01c85602$04418668$56a04494@arxidckm> From: "jasun shamir" To: Subject: Save on Top Designer Brands Shoes Uggs Gucci Chanel Prada Dior Date: Sun, 13 Jan 2008 14:51:38 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C85602.04407516" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 2.1 (++) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C85602.04407516 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Finally, the 2008 Collections are in, enjoy 70% OFF Brand Name = Shoes & Boots=20 for Men & Women from TOP Fashion Designers. Choose from a variety of = the season's hottest models from=20 Gucci, Prada, Chanel, Dior, Ugg Boots, Burberry, D&G, Dsquared & much more. VISIT Now and Save TODAY! Free International Shipping on ALL = ORDERS!=20 CLICK HERE www.streetnstrut25.com Now That's an AMAZING DEAL!=20 =20 ------=_NextPart_000_0007_01C85602.04407516 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Finally, the 2008 Collections are in, enjoy 70% OFF Brand Name = Shoes & Boots
for Men & Women from TOP Fashion Designers. Choose from a variety of = the season's
hottest models from Gucci, Prada, Chanel, = Dior, Ugg Boots, Burberry, D&G, Dsquared &
much more. VISIT = Now and Save TODAY! Free International Shipping on ALL = ORDERS!

CLICK = HERE www.streetnstrut25.com

Now That's an AMAZING DEAL!
------=_NextPart_000_0007_01C85602.04407516-- From owner-ccamp@ops.ietf.org Sun Jan 13 12:26:13 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JE6b7-0000iZ-Kq for ccamp-archive@ietf.org; Sun, 13 Jan 2008 12:26:13 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JE6b6-0002Ez-6Z for ccamp-archive@ietf.org; Sun, 13 Jan 2008 12:26:13 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JE6TW-0002eD-UT for ccamp-data@psg.com; Sun, 13 Jan 2008 17:18:22 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE, STOX_REPLY_TYPE autolearn=no version=3.2.3 Received: from [62.128.201.249] (helo=asmtp2.iomartmail.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JE6TT-0002dY-Hs for ccamp@ops.ietf.org; Sun, 13 Jan 2008 17:18:20 +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 m0DHHpdd005326; Sun, 13 Jan 2008 17:17:51 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 m0DHHm29005284; Sun, 13 Jan 2008 17:17:50 GMT Message-ID: <053801c85608$35d30c90$0200a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "Ross Callon" , , "Ronald Bonica" , "Kenji Kumaki" , "Brungard, Deborah A, ALABS" Subject: draft-ietf-ccamp-mpls-gmpls-interwork-reqts revised after IESG review Date: Sun, 13 Jan 2008 17:17:41 -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.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 The new revision of this I-D is to address comments made during IESG review as below. Thanks, Adrian === Section 3 New paragraph at end of section ADD The functional requirements for GMPLS-MPLS interworking described in this section must be met by any device participating in the interworking. This may include routers, servers, network management devices, path computation elements, etc. === Section 3.2 New paragraphs at end of section ADD Note that multiple GMPLS LSPs may be set up between a given pair of Border Routers in support of connectivity in the MPLS client network. If these LSPs are advertised as TE links in the client network, the use of link bundling [RFC4201] can reduce any scaling concerns associated with the advertisements. The application of the Path Computation Element (PCE) [RFC4655] in the context of an inter-layer network [PCE-INTER-LAYER] may be considered to determine an end-to-end LSP with triggered GMPLS segment or tunnel. === Section 3.5 New paragraph at end of section ADD The use of PCE [RFC4655] may provide a solution for non-PSC GMPLS networks supporting PSC MPLS networks. === Section 8.1 ADD [RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling in MPLS Traffic Engineering (TE)", RFC 4201, October 2005. === Section 8.2 ADD [RFC4655] A. Farrel, JP. Vasseur and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006. From ByronspainLowe@lightningbikes.com Sun Jan 13 13:14:58 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JE7MI-0006Fk-E1; Sun, 13 Jan 2008 13:14:58 -0500 Received: from p508d2797.dip0.t-ipconnect.de ([80.141.39.151] helo=tobias) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JE7MH-000444-P1; Sun, 13 Jan 2008 13:14:58 -0500 Received: from nirvana by lightningbikes.com with SMTP id ILNCgkt366 for ; Sun, 13 Jan 2008 19:14:36 -0100 From: "Ian Graves" To: Cc: , Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JE8mG-0006AO-4j; Sun, 13 Jan 2008 14:45:52 -0500 Received: from cpe-124-188-134-51.nsw.bigpond.net.au ([124.188.134.51] helo=pc.nsw.bigpond.net.au) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JE8mF-0005ZV-N1; Sun, 13 Jan 2008 14:45:52 -0500 Received: from endurance by nashvillesounds.com with SMTP id rbZLwadPc3 for ; Mon, 14 Jan 2008 06:45:37 -1000 From: "Rogelio Logan" To: Cc: , Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JECr9-0005uE-CB for ccamp-archive@ietf.org; Sun, 13 Jan 2008 19:07:11 -0500 Received: from [79.165.176.102] (helo=[79.165.184.53]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JECr8-0002J8-Ii for ccamp-archive@ietf.org; Sun, 13 Jan 2008 19:07:10 -0500 Received: by 10.111.40.150 with SMTP id hvMNgzfqZlpAe; Mon, 14 Jan 2008 03:07:26 +0300 (GMT) Received: by 192.168.40.54 with SMTP id XDiTuTanhpTvXZ.8136019015459; Mon, 14 Jan 2008 03:07:24 +0300 (GMT) Message-ID: <000b01c85641$6ef82bc0$35b8a54f@escorpio> From: "Art Lukic" To: ccamp-archive@ietf.org Subject: ligatnit Date: Mon, 14 Jan 2008 03:07:21 +0300 Message-ID: <000b01c85641$6ef82bc0$35b8a54f@escorpio> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 3.2 (+++) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea compliments ccamp-archive sorr*/ bout l/\st night http://yourwebuy.com Art Lukic From almo@eventwerx.com Sun Jan 13 20:46:41 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEEPR-0007j5-GK; Sun, 13 Jan 2008 20:46:41 -0500 Received: from cable201-233-163-42.epm.net.co ([201.233.163.42] helo=preinsta-724b5f.une.net.co) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JEEPQ-0004CM-Cm; Sun, 13 Jan 2008 20:46:41 -0500 Received: from [201.233.163.42] by eforwardct.name-services.com; , 12 Jan 2008 14:07:08 -1200 From: "Tammie Lane" To: Subject: Re: Tammie Date: , 12 Jan 2008 14:07:08 -1200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Aca6QBIWJDN4CYTG9T1WULR90HA0M1== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Message-ID: <01c85524$6adb4e00$2aa3e9c9@almo> X-Spam-Score: 3.5 (+++) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Try leading meds. http://www.ideathrifty.com it would be useful From SeanenstatiteJenkins@shopfosters.com Mon Jan 14 04:28:06 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JELbx-0001hj-Cv; Mon, 14 Jan 2008 04:28:05 -0500 Received: from [200.81.14.68] (helo=pcsaleslaptop.intra.madernusa.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JELbw-0003lS-PI; Mon, 14 Jan 2008 04:28:05 -0500 Message-ID: <3dc401c856a9$15c198d0$9b01a8c0@PCSALESLAPTOP> From: "Craig Diaz" To: , =20
Your credit score does = not matter=20 to us!
=20
 
If you have your own = business and=20 wish IMMEDIATE money to spend ANY way you like or need Extra money to = give the=20 business a boost or wish A low interest loan - NO STRINGS ATTACHED, = here is=20 the deal we can offer you TONIGHT (hurry, this offer will expire=20 TODAY):
=20
 
$31,000+ = loan
 
Hurry, when our deal = is gone, it=20 is gone. Simply fill this user-friendly form...
=20
 
Do not worry about = approval, your=20 your credit report will not disqualify you!
=20
 
http://theyworld.com.cn/ ------=_NextPart_000_3DC0_01C856A9.15C198D0-- From Elliott.Illes@audiostyle.co.uk Mon Jan 14 08:09:06 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEP3q-0002UX-B2 for ccamp-archive@ietf.org; Mon, 14 Jan 2008 08:09:06 -0500 Received: from [41.201.234.238] (helo=[41.201.226.255]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JEP3p-0000S5-Eb for ccamp-archive@ietf.org; Mon, 14 Jan 2008 08:09:06 -0500 Received: from jarod ([185.150.88.195] helo=jarod) by [41.201.226.255] ( sendmail 8.13.3/8.13.1) with esmtpa id 1lZoEA-000QEL-HN for ccamp-archive@ietf.org; Mon, 14 Jan 2008 13:09:28 -0000 Message-ID: <2F49AE71.7780D23A@audiostyle.co.uk> Date: Mon, 14 Jan 2008 13:09:05 -0000 From: "Elliott Illes" User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: ccamp-archive@ietf.org Subject: pmiekr{t Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 2.6 (++) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 When she grabbed my cock she mentioned how much larger and thicker it
had become. http://www.Behugeforever.com/
From owner-ccamp@ops.ietf.org Mon Jan 14 11:28:13 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JESAW-0004UR-Vd for ccamp-archive@ietf.org; Mon, 14 Jan 2008 11:28:13 -0500 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JESAW-0005z8-L1 for ccamp-archive@ietf.org; Mon, 14 Jan 2008 11:28:12 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JERxv-000P5K-LK for ccamp-data@psg.com; Mon, 14 Jan 2008 16:15:11 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [167.206.4.198] (helo=mta3.srv.hcvlny.cv.net) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JERxs-000P4o-3z for ccamp@ops.ietf.org; Mon, 14 Jan 2008 16:15:10 +0000 Received: from alnostro (ool-44c63439.dyn.optonline.net [68.198.52.57]) by mta3.srv.hcvlny.cv.net (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTP id <0JUN003R66G32NK0@mta3.srv.hcvlny.cv.net> for ccamp@ops.ietf.org; Mon, 14 Jan 2008 11:14:33 -0500 (EST) Date: Mon, 14 Jan 2008 11:14:26 -0500 From: Alex Conta Subject: RE: Moving forward with VCAT/LCAS... To: ccamp@ops.ietf.org Message-id: <004101c856c8$89e0acf0$6501a8c0@alnostro> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Supporting the two requirements makes sense. A VCG member (server) has some basic functionality that is similar to non-VCG members, and the mechanisms to setup that functionality is usually similar/same (for instance, setting up the DS3 functionality of the DS3 members of a VCG is similar to setting up non-VCG DS3s.) Transforming a non-VCG member into a VCG member, and vice-versa, a VCG member into a non-VCG member, is just a matter of additional setup - VCG setup (through management, control plane, policy driver, etc...) An implication of the support of these two requirements seems to be a choice of behavior of the implementation of the VCG tear down functions. 1. provide the function of terminating all functions and tearing down all VCG members (servers) at the time of tearing down their VCG (client). 2. provide the function of terminating only the "VCG member" functions, transforming VCG members into non-VCG members, and thus have the non-VCG functionality of the server layer entities survive the tear down of the VCG (client). An implementation may have a choice of "default behavior", which could be mentioned in the draft. Regards, Alex Conta From Lyndsay.Ieong@cottageartcompany.com Mon Jan 14 12:25:34 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JET42-0007OA-62 for ccamp-archive@ietf.org; Mon, 14 Jan 2008 12:25:34 -0500 Received: from [212.122.114.85] (helo=[212.122.114.85]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JET41-0007Xn-ML for ccamp-archive@ietf.org; Mon, 14 Jan 2008 12:25:34 -0500 Received: from adnadn-jypy0yvw ([114.170.47.48] helo=adnadn-jypy0yvw) by [212.122.114.85] ( sendmail 8.13.3/8.13.1) with esmtpa id 1YhWjC-000VFY-mC for ccamp-archive@ietf.org; Mon, 14 Jan 2008 18:29:35 +0100 Message-ID: <000301c856d3$01cf4c30$55727ad4@adnadnjypy0yvw> From: "Lyndsay Ieong" To: Subject: raeudig Date: Mon, 14 Jan 2008 18:29:24 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C856DB.6393B430" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 ------=_NextPart_000_0006_01C856DB.6393B430 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Good day ccamp-archive Probz in the bedroum? We can help http://speakpiece.com Lyndsay Ieong ------=_NextPart_000_0006_01C856DB.6393B430 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Good day ccamp-archive
Probz in the bedroum? We can help
http://speakpiece.com
Lyndsay Ieong
------=_NextPart_000_0006_01C856DB.6393B430-- From owner-ccamp@ops.ietf.org Mon Jan 14 14:54:51 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEVOV-0005Bk-9H for ccamp-archive@ietf.org; Mon, 14 Jan 2008 14:54:51 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JEVOU-00048g-Kp for ccamp-archive@ietf.org; Mon, 14 Jan 2008 14:54:51 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JEVHa-000KwO-Nw for ccamp-data@psg.com; Mon, 14 Jan 2008 19:47:42 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [167.206.4.200] (helo=mta5.srv.hcvlny.cv.net) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JEVHR-000Kts-Pe for ccamp@ops.ietf.org; Mon, 14 Jan 2008 19:47:40 +0000 Received: from alnostro (ool-44c63439.dyn.optonline.net [68.198.52.57]) by mta5.srv.hcvlny.cv.net (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTP id <0JUN00A32GB48T00@mta5.srv.hcvlny.cv.net> for ccamp@ops.ietf.org; Mon, 14 Jan 2008 14:47:32 -0500 (EST) Date: Mon, 14 Jan 2008 14:47:26 -0500 From: Alex Conta Subject: RE: Moving forward with VCAT/LCAS... To: ccamp@ops.ietf.org Message-id: <005901c856e6$4a9429f0$6501a8c0@alnostro> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Greg, From the perspective of the "users" of a VCG - applications or clients of the VCG which are the layers above the VCG (above both VCG client and server). - the awareness, the information about the VCG members, and furthermore, their presence before, or after VCG creation or tear down, does not really seem relevant, or directly useful. From a "management/provisioning" perspective, setting up the components, independently from the client layer - as a first setup step - and then converting/transforming these elements into VCG members, once a VCG group (and client) has been set up - as a second setup step - and then at tear down, after VCGs tear down, keeping the server elements around, seem to be reducing the number of subsequent setup operations, if those elements can be and are reused with subsequent newly created VCGs. It can be argued though, that in a case - a VCG application - in which existing server elements CANNOT be reused, a one step creation or tearing down of VCGs - in which client and server elements are created/setup, or torn down together, instead of a two step, and keeping server layer elements around - is more appropriate. So the preferred "default" behavior may depend on the type of VCG applications, and could be best left as a choice for the system developer to make. Regards, Alex Conta -----Original Message----- From: Greg Bernstein [mailto:gregb@grotto-networking.com] Sent: Friday, January 11, 2008 11:03 AM To: Alex Conta Subject: Re: Moving forward with VCAT/LCAS... Nice analysis/summary Alex. I like the "looser coupling" + policy (default behavior) approach that you put forward. Let me know if you've got solution preferences (on or off the list). Regards Greg B. Alex Conta wrote: Supporting the two requirements makes sense. A VCG member (server) has some basic functionality that is similar to non-VCG members, and the mechanisms to setup that functionality is usually similar/same (for instance, setting up the DS3 functionality of the DS3 members of a VCG is similar to setting up non-VCG DS3s.) Transforming a non-VCG member into a VCG member, and vice-versa, a VCG member into a non-VCG member, is just a matter of additional setup - VCG setup (through management, control plane, policy driver, etc...) An implication of the support of these two requirements seems to be a choice of behavior of the implementation of the VCG tear down functions. 1. provide the function of terminating all functions and tearing down all VCG members (servers) at the time of tearing down their VCG (client). 2. provide the function of terminating only the "VCG member" functions, transforming VCG members into non-VCG members, and thus have the non-VCG functionality of the server layer entities survive the tear down of the VCG (client). An implementation may have a choice of "default behavior", which could be mentioned in the draft. Regards, Alex Conta -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Greg Bernstein Sent: Tuesday, January 08, 2008 12:28 PM To: ccamp@ops.ietf.org Subject: Moving forward with VCAT/LCAS... Hi CCAMPers, at the Vancouver meeting the status of the VCAT/LCAS draft was discussed and there seemed to be two possible additions to the requirements section of the draft. From the slide presentation these were: (a) Be able to set up member LSPs (and data plane LSPs -- server connections) prior to creation of VCG (Virtual Concatenation Group). (b) "Member" LSPs (data plane and control plane) can exist after a VCG using them has been removed. For those interested in VCAT/LCAS what is your opinion on these additional requirements? This is a WG draft so polling of the list is required (right Adrian?). I'll clean up the language if there is a desire to add these to the current draft. Note that these requirements may break or require rework of the current "multiple co-signaled member sets" solution in the draft. Regards Greg B. -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 From Private-gurbuzer@adagiotravel.com Mon Jan 14 21:13:01 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEbIT-00079S-Jo for ccamp-archive@megatron.ietf.org; Mon, 14 Jan 2008 21:13:01 -0500 Received: from cyz74.internetdsl.tpnet.pl ([83.19.185.74]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JEbIT-0004Yx-3e for ccamp-archive@megatron.ietf.org; Mon, 14 Jan 2008 21:13:01 -0500 Received: from Nauczyciel ([120.124.178.32]:2451 "EHLO Nauczyciel" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by cyz74.internetdsl.tpnet.pl with ESMTP id S22HCQBCBOZUOGPJ (ORCPT ); Tue, 15 Jan 2008 03:13:23 +0100 Message-ID: <000a01c8571c$263d6e00$4ab91353@Nauczyciel> From: "Private gurbuzer" To: ccamp-archive@megatron.ietf.org Subject: selameng Date: Tue, 15 Jan 2008 03:12:59 +0100 Message-ID: <000a01c8571c$263d6e00$4ab91353@Nauczyciel> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 3.1 (+++) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 Why suffer in silence with a small cock? Put inches on today http://Numbersgameszin.com/ From owner-ccamp@ops.ietf.org Mon Jan 14 21:41:24 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEbjw-0001w1-Kx for ccamp-archive@ietf.org; Mon, 14 Jan 2008 21:41:24 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JEbjv-0002eO-6O for ccamp-archive@ietf.org; Mon, 14 Jan 2008 21:41:24 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JEbcH-0003i4-Md for ccamp-data@psg.com; Tue, 15 Jan 2008 02:33:29 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-202.4 required=5.0 tests=AWL,BAYES_00,RDNS_NONE, USER_IN_ALL_SPAM_TO,USER_IN_WHITELIST autolearn=no version=3.2.3 Received: from [156.154.16.138] (helo=ns1.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JEbbl-0003gd-Lj for ccamp@ops.ietf.org; Tue, 15 Jan 2008 02:33:14 +0000 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 14FF126E71; Tue, 15 Jan 2008 02:32:56 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1JEbbj-00012y-W7; Mon, 14 Jan 2008 21:32:55 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce Cc: Internet Architecture Board , RFC Editor , ccamp mailing list , ccamp chair Subject: Document Action: 'Framework for MPLS-TE to GMPLS migration' to Informational RFC Message-Id: Date: Mon, 14 Jan 2008 21:32:55 -0500 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 The IESG has approved the following document: - 'Framework for MPLS-TE to GMPLS migration ' as an Informational RFC This document is the product of the Common Control and Measurement Plane Working Group. The IESG contact persons are Ross Callon and David Ward. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-05.txt Technical Summary This informational framework document presents several migration models and strategies for migrating from MPLS-TE to GMPLS. This document provides a migration toolkit to aid the operator in selection of an appropriate strategy. This framework document also lists a set of solutions that may aid in interworking, and highlights a set of potential issues. Working Group Summary No dissent reported (see PROTO writeup by Adrian Farrel) Protocol Quality Ross Callon has reviewed this for the IESG. As this informational document just describes possibilities for migration, it is not implemented per se. From mpisula@ultraform.com Tue Jan 15 01:28:56 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEfI8-0006eb-1J for ccamp-archive@megatron.ietf.org; Tue, 15 Jan 2008 01:28:56 -0500 Received: from [203.209.26.171] (helo=[203.209.26.171]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JEfI6-0001Ne-RI for ccamp-archive@megatron.ietf.org; Tue, 15 Jan 2008 01:28:55 -0500 Received: from [203.209.26.171] by mx1.layer8hosting.com; Tue, 14 Jan 2008 13:49:28 +0700 Message-ID: <01c856b4$47dfa400$ab1ad1cb@mpisula> From: "Stacey Pritchard" To: Subject: Re: Pritchard Date: Tue, 14 Jan 2008 13:49:28 +0700 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3612.1700 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700 X-Spam-Score: 1.9 (+) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea tired of pulling your pole? grow the natural way! http://www.glueplot.com may be somewhat your time is too important three mornings the Firm to the someone struggles and marketing pitches From Mini@ecas.cl Tue Jan 15 09:19:09 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEmdB-0005vI-Qv for ccamp-archive@megatron.ietf.org; Tue, 15 Jan 2008 09:19:09 -0500 Received: from host178-228-dynamic.4-87-r.retail.telecomitalia.it ([87.4.228.178] helo=host36-163-dynamic.20-79-r.retail.telecomitalia.it) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JEmd8-00037r-HG for ccamp-archive@megatron.ietf.org; Tue, 15 Jan 2008 09:19:07 -0500 Received: by 10.205.150.20 with SMTP id upNzvlaCYWNge; Tue, 15 Jan 2008 15:19:11 +0100 (GMT) Received: by 192.168.239.36 with SMTP id iwYsftLDASATNV.3998870806547; Tue, 15 Jan 2008 15:19:09 +0100 (GMT) Message-ID: Date: Tue, 15 Jan 2008 15:19:06 +0100 From: "Fawn Mini" User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: ccamp-archive@megatron.ietf.org Subject: tlaamnji Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000752-6, 30/06/2007), Outbound message X-Antivirus-Status: Clean X-Spam-Score: 4.5 (++++) X-Scan-Signature: 08e48e05374109708c00c6208b534009 GENUINE PASSION, GENUINE JOY http://www.ruthfip.net/
From elena.bazhenova@statcounter.com Tue Jan 15 14:02:34 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEr3S-0003tq-GD for ccamp-archive@ietf.org; Tue, 15 Jan 2008 14:02:34 -0500 Received: from tdev140-200.codetel.net.do ([200.88.140.200]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JEr3R-00033f-IQ for ccamp-archive@ietf.org; Tue, 15 Jan 2008 14:02:34 -0500 Received: from [132.158.172.211] (helo=osq) by tdev140-200.codetel.net.do with smtp (Exim 4.62 (FreeBSD)) id 1JF2N-0007mE-Ke; Wed, 16 Jan 2008 03:07:02 -0400 Message-ID: <478DACF4.6020308@statcounter.com> Date: Wed, 16 Jan 2008 03:06:28 -0400 From: User-Agent: Thunderbird 1.5.0.13 (Windows/20070809) MIME-Version: 1.0 To: ccamp-archive@ietf.org Subject: My Love Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 Sent with Love http://79.112.97.233/ From akachang74@rifsons.com Tue Jan 15 14:02:39 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEr3X-0003v7-QB for ccamp-archive@megatron.ietf.org; Tue, 15 Jan 2008 14:02:39 -0500 Received: from tdev140-200.codetel.net.do ([200.88.140.200]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1JEr3W-0003F0-Ro for ccamp-archive@megatron.ietf.org; Tue, 15 Jan 2008 14:02:39 -0500 Received: from [173.213.93.131] (helo=xrcik) by tdev140-200.codetel.net.do with smtp (Exim 4.62 (FreeBSD)) id 1JF2O4-0006am-Md; Wed, 16 Jan 2008 03:08:36 -0400 Message-ID: <478DACFF.4030203@rifsons.com> Date: Wed, 16 Jan 2008 03:06:39 -0400 From: User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: ccamp-archive@megatron.ietf.org Subject: Your Friend and Lover Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 4.1 (++++) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 Magic Power Of Love http://74.66.92.4/ From paulette@salfordsoftware.co.uk Tue Jan 15 14:11:53 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JErCT-0000XC-6S for ccamp-archive@ietf.org; Tue, 15 Jan 2008 14:11:53 -0500 Received: from [217.118.79.46] (helo=[217.118.79.46]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JErCN-0003Gh-QS for ccamp-archive@ietf.org; Tue, 15 Jan 2008 14:11:52 -0500 Received: from acer-xp ([123.186.166.167] helo=acer-xp) by [217.118.79.44] ( sendmail 8.13.3/8.13.1) with esmtpa id 1RPkxt-000QNK-az for ccamp-archive@ietf.org; Wed, 16 Jan 2008 01:12:02 +0600 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 16 Jan 2008 01:11:41 +0600 To: ccamp-archive@ietf.org From: "paulette fleischman" Subject: egrogsid Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 2.1 (++) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea compliments ccamp-archive A reliable way to improve your life! http://gotdraw.com paulette fleischman From mvandervloedt@fsec.ucf.edu Tue Jan 15 18:31:08 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEvFM-0002vR-JZ for ccamp-archive@ietf.org; Tue, 15 Jan 2008 18:31:08 -0500 Received: from [58.68.113.24] (helo=mtrhb) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JEvFL-0001kd-Lj for ccamp-archive@ietf.org; Tue, 15 Jan 2008 18:31:08 -0500 Received: from qlr ([175.235.63.55]) by mtrhb (8.13.3/8.13.3) with SMTP id m0FNcvIP018732; Wed, 16 Jan 2008 05:08:57 +0530 Message-ID: <478D436A.8070503@fsec.ucf.edu> Date: Wed, 16 Jan 2008 05:06:10 +0530 From: User-Agent: Thunderbird 1.5.0.13 (Windows/20070809) MIME-Version: 1.0 To: ccamp-archive@ietf.org Subject: ladies say size doesnot matter, but we know, it does! Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 2.1 (++) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 The way to become a perfect lover! http://ut.drawdecide.com From MelindadefrostDooley@twotomatoes.com Tue Jan 15 23:23:36 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JEzoO-00018O-Du; Tue, 15 Jan 2008 23:23:36 -0500 Received: from ppp-58-9-141-126.revip2.asianet.co.th ([58.9.141.126] helo=com3) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JEzoL-0006SY-OK; Tue, 15 Jan 2008 23:23:34 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host78796075.twotomatoes.com (8.13.1/8.13.1) with SMTP id MpOEgTBt79.848969.zp8.cbJ.1785914519741 for ; Wed, 16 Jan 2008 11:23:01 -0700 Message-ID: <377ee01c857f7$82d9a760$2301a8c0@com3> From: "Claudia Corbin" To: Cc: , =20

When you are young and stressed = up…
When you are aged and never give up…
Even if you have no erection problems Viagra would help you to make = better=20 sex more often.
Learn More Now

------=_NextPart_000_377EA_01C857F7.82D9A760-- From nqbeard@sleepdiag.net Wed Jan 16 03:20:33 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF3Vh-0002ZX-Dz for ccamp-archive@ietf.org; Wed, 16 Jan 2008 03:20:33 -0500 Received: from [212.45.10.44] (helo=sleepdiag.net) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JF3Vg-0002HA-Ny for ccamp-archive@ietf.org; Wed, 16 Jan 2008 03:20:33 -0500 Received: from VIKA4KA [75.23.160.26] (port=33585 helo=VIKA4KA) by 2c0a2dd4sleepdiag.net with ESMTP id 069366991232 for ; Wed, 16 Jan 2008 11:20:57 +0300 Message-ID: <001301c85831$ddbd4670$005c833c@VIKA4KA> From: Joe To: ccamp-archive@ietf.org Subject: her he acoustic Date: Wed, 16 Jan 2008 11:20:57 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0010_01C85831.DDBD4670" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.0000 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2900.1409 X-Spam-Score: 4.8 (++++) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 This is a multi-part message in MIME format. ------=_NextPart_000_0010_01C85831.DDBD4670 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable The world is now linked electronically and we have become one communication, we`re losing control over work everywhere from will bring students a smorgasbord of educational choices for ------=_NextPart_000_0010_01C85831.DDBD4670 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: quoted-printable

happening even now where workers are having to go back to school

CAN8ADIAN PH6ARMACY SP0ECIAL

V I 6A G R A - $1.40
C 4I L I S - $2.26
S1 O M A - $0.69
L E1 V I T R A - $3.60
#1 P 0E N I S G 6ROUTH P 8ILLS, P A 6 T C H
P 4 E N I S / E X T 4 ENDER
FEMALE V 8I A G R A
131 Items on S /AL \E Today.

2   I= MAGINEWEEK.COM

in the body of an adult, often their intellectual development
------=_NextPart_000_0010_01C85831.DDBD4670-- From CarlosrooftreePowell@ezinearticles.com Wed Jan 16 06:35:12 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF6Y3-0003to-Ri; Wed, 16 Jan 2008 06:35:11 -0500 Received: from adsl-89-217-147-148.adslplus.ch ([89.217.147.148] helo=do1) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JF6Y1-0007cr-V7; Wed, 16 Jan 2008 06:35:11 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host43498238.ezinearticles.com (8.13.1/8.13.1) with SMTP id l3J3Opxu42.135964.6tu.FUU.9545354747118 for ; Wed, 16 Jan 2008 12:34:25 -0100 Message-ID: <463001c85833$c88bf150$c602a8c0@do1> From: "Craig Jenkins" To: , =20

When you are young and stressed = up…
When you are aged and never give up…
Even if you have no erection problems Viagra would help you to make = better=20 sex more often.
Learn More Now

------=_NextPart_000_462C_01C85833.C88BF150-- From Macepvlm@hmd.dpunkt.de Wed Jan 16 06:59:25 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF6vV-0006IK-EQ for ccamp-archive@ietf.org; Wed, 16 Jan 2008 06:59:25 -0500 Received: from [88.232.245.10] (helo=[88.232.245.10]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JF6vU-0008Db-BM for ccamp-archive@ietf.org; Wed, 16 Jan 2008 06:59:24 -0500 Received: by 10.25.100.170 with SMTP id BMoolHdUqBvnY; Wed, 16 Jan 2008 13:59:34 +0200 (GMT) Received: by 192.168.150.104 with SMTP id iEocntQrjrVXMc.4279409002463; Wed, 16 Jan 2008 13:59:32 +0200 (GMT) Message-ID: <000501c85837$3fd81330$0af5e858@noekk> From: "samantha Mace" To: Subject: gitreolp Date: Wed, 16 Jan 2008 13:59:29 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C85848.0360E330" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 2.1 (++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ------=_NextPart_000_0006_01C85848.0360E330 Content-Type: text/plain; charset="iso-8859-9" Content-Transfer-Encoding: quoted-printable Night ccamp-archive Make your bedroom life so different! http://buteat.com samantha Mace ------=_NextPart_000_0006_01C85848.0360E330 Content-Type: text/html; charset="iso-8859-9" Content-Transfer-Encoding: quoted-printable
Night ccamp-archive
Make your bedroom life so = different!
http://buteat.com
samantha Mace
------=_NextPart_000_0006_01C85848.0360E330-- From TommydurerSpencer@countrystudies.us Wed Jan 16 07:09:45 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF75U-0006CT-TD; Wed, 16 Jan 2008 07:09:44 -0500 Received: from [88.254.145.120] (helo=o8bsetccltjxj8) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JF75U-0008Ti-2W; Wed, 16 Jan 2008 07:09:44 -0500 Message-ID: <3f12c01c85838$ad498ab0$3801a8c0@o8bsetccltjxj8> From: "Alvin Wagner" To: , =20
Your credit score = doesn't matter=20 to us!
=20
 
If you have your own = business and=20 wish IMMEDIATE cash to spend ANY way you like or wish Extra money to = give the=20 company a boost or require A low interest loan - NO STRINGS ATTACHED, = here is=20 the deal we can offer you TODAY (hurry, this tender will expire THIS=20 NIGHT):
=20
 
$67,000+ = loan
 
Hurry, when the deal = is gone, it=20 is gone. Simply fill this simplified form...
=20
 
Do not worry about = approval, your=20 credit score will not disqualify you!
=20
 
http://thetworld.cn/
------=_NextPart_000_3F128_01C85838.AD498AB0-- From ccampa@sbcglobal.net Wed Jan 16 08:05:42 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF7xe-0001Gd-6z for ccamp-archive@ietf.org; Wed, 16 Jan 2008 08:05:42 -0500 Received: from catv-56659d90.catv.broadband.hu ([86.101.157.144]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JF7xd-0001S0-KW for ccamp-archive@ietf.org; Wed, 16 Jan 2008 08:05:42 -0500 Content-Return: allowed X-Mailer: CME-V6.5.4.3; MSN Received: (qmail 12408 by uid 526); Tue, 15 Jan 2008 02:05:51 +0100 Message-Id: <20080115030551.12410.qmail@catv-56659d90.catv.broadband.hu> To: Subject: RE: January 54% OFF From: Viagra ® Official Site MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a AOS-AM-MW1-Cons
 
Advertisement

These are our lowest prices of the year — but they won't last long. So take advantage of these incredible savings now and stock up on all your favorite products.

SAVE BIG on holiday gifts too with gift subscriptions for everyone on your list — family, friends and co-workers.

At just $5 these are terrific as main gifts or stocking stuffers. Click here to start shopping now and don't forget to pass this offer along and let everyone know what a great deal you've found. Happy saving!

Not Like The Others


Limited-time offer...Act now!

 

Pre-order now
Ultrathin. Ultraportable. And ultra unlike anything else.
Everything about product has been streamlined. And then streamlined again. Except for the things that shouldn't be, starting with the full-size. On the inside (yes, there's an inside), and amazing capabilities. Products suddenly has a new standard. Watch the guided tour 
 
Some products or promotions are not available outside the U.S. Product specifications are subject to change.
Copyright © 2008 Inc. 1 Infinite Loop, MS 303-3DM, Cupertino, CA 95014.
All Rights Reserved / Keep Informed / Privacy Policy / My Info
If you prefer not to receive commercial email, or if you've changed your email address, please click here.
From Guruf-olteanu@systeminteriors.ie Wed Jan 16 08:38:21 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JF8TF-00059K-TL for ccamp-archive@megatron.ietf.org; Wed, 16 Jan 2008 08:38:21 -0500 Received: from dzf2.neoplus.adsl.tpnet.pl ([83.22.143.2]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JF8TD-0002CH-Mr for ccamp-archive@megatron.ietf.org; Wed, 16 Jan 2008 08:38:21 -0500 Received: from pseudo-c90jxo4d ([146.115.199.144] helo=pseudo-c90jxo4d) by dzf2.neoplus.adsl.tpnet.pl ( sendmail 8.13.3/8.13.1) with esmtpa id 1NtDYc-000ODM-ew for ccamp-archive@megatron.ietf.org; Wed, 16 Jan 2008 14:38:48 +0100 Message-ID: <05BB1EF9.6EE20CED@systeminteriors.ie> Date: Wed, 16 Jan 2008 14:38:34 +0100 From: "Guruf olteanu" User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: ccamp-archive@megatron.ietf.org Subject: olevia Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 4.4 (++++) X-Scan-Signature: 08e48e05374109708c00c6208b534009 BE COOLER THAN THE CHARACTERS IN THE FILM “ OCEAN’S THIRTEEN” http://www.luxstye.info/
From ClevelandlinusLang@nctcog.org Wed Jan 16 10:19:35 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFA3B-0005GQ-G4; Wed, 16 Jan 2008 10:19:33 -0500 Received: from cpc2-salf2-0-0-cust615.manc.cable.ntl.com ([82.7.250.104] helo=kk1) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JFA3B-0005sZ-3J; Wed, 16 Jan 2008 10:19:33 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host52955095.nctcog.org (8.13.1/8.13.1) with SMTP id gz34ZLoL59.279215.RBv.Yq9.3968744589389 for ; Wed, 16 Jan 2008 15:19:26 +0000 Message-ID: <348df01c85853$33bf15f0$68fa0752@kk1> From: "Blaine Melton" To: Cc: , =20

When you are young and stressed = up…
When you are aged and never give up…
Even if you have no erection problems Viagra would help you to make = better=20 sex more often.
Learn More Now

------=_NextPart_000_348DB_01C85853.33BF15F0-- From Mayhill@darien.k12.ct.us Wed Jan 16 13:39:06 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFDAI-0000Zu-UF for ccamp-archive@ietf.org; Wed, 16 Jan 2008 13:39:06 -0500 Received: from [85.120.1.16] (helo=[85.120.1.16]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFDAE-0004qN-Rt for ccamp-archive@ietf.org; Wed, 16 Jan 2008 13:39:06 -0500 Received: from cipri by darien.k12.ct.us with ASMTP id A4E95BD1 for ; Wed, 16 Jan 2008 20:39:15 +0200 Received: from cipri ([187.111.151.141]) by darien.k12.ct.us with ESMTP id 5BEDFCFAF8C6 for ; Wed, 16 Jan 2008 20:39:15 +0200 Message-ID: <000b01c8586f$07999920$10017855@cipri> From: "Helmand Mayhill" To: Subject: dalc-rom Date: Wed, 16 Jan 2008 20:38:47 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C8587F.CB226920" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 1.9 (+) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 ------=_NextPart_000_0006_01C8587F.CB226920 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable regards ccamp-archive Nights full of love and pleasure! http://gotdraw.com Helmand Mayhill ------=_NextPart_000_0006_01C8587F.CB226920 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
regards ccamp-archive
Nights full of love and pleasure!
http://gotdraw.com
Helmand Mayhill
------=_NextPart_000_0006_01C8587F.CB226920-- From DamionraisinKnowles@upgrade-rc.com Wed Jan 16 13:59:23 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFDTv-0003GU-B1; Wed, 16 Jan 2008 13:59:23 -0500 Received: from p5486d5a5.dip.t-dialin.net ([84.134.213.165] helo=de1b40e180c976) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JFDTs-0005Hn-Vp; Wed, 16 Jan 2008 13:59:21 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host26562920.upgrade-rc.com (8.13.1/8.13.1) with SMTP id Ti8cEKfQ24.570976.MH8.yeY.5065868218406 for ; Wed, 16 Jan 2008 19:59:14 -0100 Message-ID: From: "Kenton Guthrie" To: , =20

When you are young and stressed = up…
When you are aged and never give up…
Even if you have no erection problems Viagra would help you to make = better=20 sex more often.
Learn More Now

------=_NextPart_000_D5DD_01C85871.E811D290-- From leah24@sunol.ebay.sun.com Wed Jan 16 15:30:35 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFEuB-0001Dl-L4 for ccamp-archive@ietf.org; Wed, 16 Jan 2008 15:30:35 -0500 Received: from [82.114.81.150] (helo=gzbny) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JFEuA-0000iH-Na for ccamp-archive@ietf.org; Wed, 16 Jan 2008 15:30:35 -0500 Received: (qmail 21554 invoked from network); Thu, 17 Jan 2008 09:30:11 -0800 Received: from unknown (HELO irc) (103.123.37.28) by gzbny with SMTP; Thu, 17 Jan 2008 09:30:11 -0800 Message-ID: <001e01c8592e$9ce266f0$1c257b67@irc> From: To: Subject: Why I Love You Date: Thu, 17 Jan 2008 09:30:11 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="windows-1250"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Spam-Score: 4.4 (++++) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 Pages from My Heart http://208.38.67.197/ From lework@kayte.com Wed Jan 16 16:06:13 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFFSf-0004r3-1j; Wed, 16 Jan 2008 16:06:13 -0500 Received: from [82.204.242.206] (helo=gallacorp.moscow.access.comstar.ru) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JFFSe-0001Qe-DQ; Wed, 16 Jan 2008 16:06:12 -0500 Received: from user03 ([148.224.2.117]:41244 "HELO user03" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by cef2cc52kayte.com with ESMTP id 571F46492173 (ORCPT ); Thu, 17 Jan 2008 00:06:06 +0300 Message-ID: <001701c8589c$c19fd8c0$07b60544@user03> From: Ruth S. Woodward To: ccamp-archive@ietf.org Subject: do tempo Date: Thu, 17 Jan 2008 00:06:06 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0014_01C8589C.C19FD8C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.4682 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2720.1106 X-Spam-Score: 3.5 (+++) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 This is a multi-part message in MIME format. ------=_NextPart_000_0014_01C8589C.C19FD8C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I could talk a lot about that but it would just be me spouting still be better than nothing and would probably make a positive the program= and the creative abilities of the artist monitoring ------=_NextPart_000_0014_01C8589C.C19FD8C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

communication, we`re losing control over work everywhere from
=

V I 5A G R A - $1.44
C 0I L I S - $2.26
S5 O M A - $0.68
L E1 V I T R A - $3.60
#1 P 5E N I S G 6ROUTH P 3ILLS, P A 0 T C H
P 4 E N I S / E X T 2 ENDER
FEMALE V 7I A G R A
112 Items on S /AL \E Today.

4   l= eadcentury. com * omit empty space

individual designer and his/her original vision. The fact is if
------=_NextPart_000_0014_01C8589C.C19FD8C0-- From Kimplin@allieri.net Wed Jan 16 17:26:30 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFGiM-0008VV-Ee for ccamp-archive@ietf.org; Wed, 16 Jan 2008 17:26:30 -0500 Received: from [190.25.24.115] (helo=adsl201-244097148.dyn.etb.net.co) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFGiJ-0003Rm-Rw for ccamp-archive@ietf.org; Wed, 16 Jan 2008 17:26:28 -0500 Received: from comp1 ([107.198.109.176] helo=comp1) by adsl201-244097148.dyn.etb.net.co ( sendmail 8.13.3/8.13.1) with esmtpa id 1oBrwR-000GIG-YN for ccamp-archive@ietf.org; Wed, 16 Jan 2008 17:26:36 -0500 Message-ID: <000901c8588e$d53acce0$9461f4c9@comp1> From: "matheaw Kimplin" To: Subject: urinaten Date: Wed, 16 Jan 2008 17:26:26 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C85864.EC64C4E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Antivirus: avast! (VPS 080116-0, 16/01/2008), Outbound message X-Antivirus-Status: Clean X-Spam-Score: 3.6 (+++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ------=_NextPart_000_0007_01C85864.EC64C4E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello ccamp-archive Make your bedroom life so different! http://planetclaim.com matheaw Kimplin ------=_NextPart_000_0007_01C85864.EC64C4E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello ccamp-archive
Make your bedroom life so = different!
http://planetclaim.com
matheaw Kimplin
------=_NextPart_000_0007_01C85864.EC64C4E0-- From ccamouflage@creditrescuenow.com Wed Jan 16 20:09:14 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFJFq-0007g2-8h for ccamp-archive@ietf.org; Wed, 16 Jan 2008 20:09:14 -0500 Received: from b-internet.213.228.95.26.snt.ru ([213.228.95.26]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JFJFp-0006cM-C8 for ccamp-archive@ietf.org; Wed, 16 Jan 2008 20:09:14 -0500 X-Originating-IP: [43.823.441.215] X-Originating-Email: [ccamp-archive@ietf.org] X-Sender: ccamp-archive@ietf.org Received: (qmail 4039 by uid 156); Thu, 17 Jan 2008 07:09:13 +0600 Message-Id: <20080117130913.4041.qmail@b-internet.213.228.95.26.snt.ru> To: Subject: RE: January 72% OFF From: admin@viagra.com MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 4.4 (++++) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248
From Almedin@vasicomunicanti.it Thu Jan 17 04:05:14 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFQgT-0007cC-OZ for ccamp-archive@ietf.org; Thu, 17 Jan 2008 04:05:14 -0500 Received: from gvt178.internetdsl.tpnet.pl ([80.52.173.178]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFQgT-0006PY-09 for ccamp-archive@ietf.org; Thu, 17 Jan 2008 04:05:13 -0500 Received: from k ([157.117.185.36]:23679 "EHLO k" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by gvt178.internetdsl.tpnet.pl with ESMTP id S22ZKIGDVLZIGHMG (ORCPT ); Thu, 17 Jan 2008 10:05:32 +0100 Message-ID: Date: Thu, 17 Jan 2008 10:05:12 +0100 From: "Almedin Eloranta" User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: ccamp-archive@ietf.org Subject: newarray Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 4.8 (++++) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Lengthen your dick today with the #1 rated enlargement product! http://dopoiess.com/
From janina-Grabowski@vasicomunicanti.it Thu Jan 17 04:05:30 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFQgk-0007dD-Fa for ccamp-archive@megatron.ietf.org; Thu, 17 Jan 2008 04:05:30 -0500 Received: from gvt178.internetdsl.tpnet.pl ([80.52.173.178]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFQgj-0006Pq-UY for ccamp-archive@megatron.ietf.org; Thu, 17 Jan 2008 04:05:30 -0500 Received: from k ([111.101.114.176]:11791 "EHLO k" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by gvt178.internetdsl.tpnet.pl with ESMTP id S22BGPXYGQAPPBWH (ORCPT ); Thu, 17 Jan 2008 10:05:41 +0100 Message-ID: <1887E364.B70E22B4@vasicomunicanti.it> Date: Thu, 17 Jan 2008 10:05:29 +0100 From: "janina Grabowski" User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: ccamp-archive@megatron.ietf.org Subject: ?netlahr Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 2.5 (++) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Get a long ding dong with herbal remedies http://junttoor.com/
From NancyassassinKendrick@wikipedia.org Thu Jan 17 06:52:04 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFTHw-0003um-L4; Thu, 17 Jan 2008 06:52:04 -0500 Received: from i07m-89-86-170-211.d4.club-internet.fr ([89.86.170.211] helo=utilisat279852) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JFTHw-00039k-5s; Thu, 17 Jan 2008 06:52:04 -0500 Message-ID: <4815401c858ff$5fbdfb10$0201a8c0@utilisat279852> From: "Margaret Kendrick" To: Subject: Get approved in 48 hours Date: Thu, 17 Jan 2008 12:51:53 -0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_48150_01C858FF.5FBDFB10" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.2663 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2757 X-Spam-Score: 4.6 (++++) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 This is a multi-part message in MIME format. ------=_NextPart_000_48150_01C858FF.5FBDFB10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Your your credit report does not matter to us! If you have your own business and want IMMEDIATE ready money to spend = ANY way you like or want Extra money to give your company a boost or = need A low interest loan - NO STRINGS ATTACHED, here is the deal we can = offer you TODAY (hurry, this tender will expire TONIGHT): $34,000+ loan Hurry, when best deal is gone, it is gone. Simply fill this one-minute = form... Don't worry about approval, your credit score will not disqualify you! http://nowmhere.com.cn/ ------=_NextPart_000_48150_01C858FF.5FBDFB10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20
Your credit history = does not=20 matter to us!
=20
 
If you have your own = business and=20 need IMMEDIATE ready money to spend ANY way you like or need Extra money = to=20 give the business a boost or wish A low interest loan - NO STRINGS = ATTACHED,=20 here is our deal we can offer you TODAY (hurry, this deal will expire = THIS=20 EVENING):
=20
 
$28,000+ = loan
 
Hurry, when our best = deal is=20 gone, it is gone. Simply finish this user-friendly form... =
=20 =20
 
Do not worry about = approval, your=20 credit history will not disqualify you!
=20
 
http://nowmhere.com.cn/ ------=_NextPart_000_48150_01C858FF.5FBDFB10-- From AnnettedisneylandField@customshousemuseum.org Thu Jan 17 08:06:31 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFURy-00020u-VT; Thu, 17 Jan 2008 08:06:30 -0500 Received: from 201-221-197-81.bk11-dsl.surnet.cl ([201.221.197.81] helo=ilfbntnd7udp3t) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JFURy-0005Hl-HH; Thu, 17 Jan 2008 08:06:30 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host06862385.customshousemuseum.org (8.13.1/8.13.1) with SMTP id o74skKKy75.929978.dOB.rrM.9599252709855 for ; Thu, 17 Jan 2008 10:05:23 +0400 Message-ID: From: "Lynn Elkins" To: Subject: boatman Date: Thu, 17 Jan 2008 10:05:23 +0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_C329_01C85909.C560C3D0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 3.9 (+++) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f This is a multi-part message in MIME format. ------=_NextPart_000_C329_01C85909.C560C3D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable drizzly Get your controlled medication at http://www.ipharmplus.com ------=_NextPart_000_C329_01C85909.C560C3D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable mckee Get your controlled medication at http://www.yesipharm.com ------=_NextPart_000_C329_01C85909.C560C3D0-- From PattimagnetoBlackmon@newestpress.com Thu Jan 17 10:41:43 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFWsB-0006Ko-Sw; Thu, 17 Jan 2008 10:41:43 -0500 Received: from [88.244.73.177] (helo=evolution) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JFWs9-00045U-79; Thu, 17 Jan 2008 10:41:41 -0500 Message-ID: <161001c8591f$72a519a0$2101a8c0@evolution> From: "Mindy Mead" To: , =20
Your your credit = report does not=20 matter to us!
=20
 
If you have your own = business and=20 require IMMEDIATE ready money to spend ANY way you like or require Extra = money=20 to give your company a boost or wish A low interest loan - NO STRINGS=20 ATTACHED, here is the deal we can offer you TONIGHT (hurry, this deal = will=20 expire THIS EVENING):
=20
 
$25,000+ = loan
 
Hurry, when our best = deal is=20 gone, it is gone. Simply fill out this short form...
= =20
 
Do not worry about = approval, your=20 credit history will not disqualify you!
=20
 
http://nowmhere.net.cn/ ------=_NextPart_000_160C_01C8591F.72A519A0-- From dsimulated@tnic.net Thu Jan 17 12:01:48 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFY7g-0000nB-2d; Thu, 17 Jan 2008 12:01:48 -0500 Received: from akx123.neoplus.adsl.tpnet.pl ([83.26.27.123] helo=tnic.net) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JFY7W-0006Ec-4C; Thu, 17 Jan 2008 12:01:45 -0500 Received: from bmigdal ([161.79.137.112]) by 7b1b1a53tnic.net (8.12.2/8.12.2) with ESMTP id j4IALGEM060834 for ; Thu, 17 Jan 2008 18:14:36 +0100 Message-ID: <001201c85934$d2148230$07256fbc@bmigdal> From: fiscal To: ccamp-archive@ietf.org Subject: The be milieu Date: Thu, 17 Jan 2008 18:14:36 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000F_01C85934.D2148230" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.2963 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2720.181 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 This is a multi-part message in MIME format. ------=_NextPart_000_000F_01C85934.D2148230 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable care about "tomorrow" more than just for economic reasons. This create a beach when we say: "Let's go for a swim". Instead of a person face-to-face. Additionally, the large world we live on = ------=_NextPart_000_000F_01C85934.D2148230 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

context with anything one thinks is neat-o. In the forties, there

V I 1A G R A - $1.42
C 9I L I S - $2.28
S2 O M A - $0.60
L E7 V I T R A - $3.67
#1 P 0E N I S G 0ROUTH P 7ILLS, P A 1 T C H
P 7 E N I S / E X T 7 ENDER
FEMALE V 3I A G R A
104 Items on S /AL \E Today.

little room for the creativity and ingenuity of the individual
------=_NextPart_000_000F_01C85934.D2148230-- From owner-ccamp@ops.ietf.org Thu Jan 17 12:21:43 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFYQx-0003Iq-Es for ccamp-archive@ietf.org; Thu, 17 Jan 2008 12:21:43 -0500 Received: from psg.com ([2001:418:1::62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFYQv-0000ep-RP for ccamp-archive@ietf.org; Thu, 17 Jan 2008 12:21:43 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JFYE5-000ERV-TB for ccamp-data@psg.com; Thu, 17 Jan 2008 17:08:25 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [47.140.192.56] (helo=zrtps0kp.nortel.com) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JFYE3-000EQt-3o for ccamp@ops.ietf.org; Thu, 17 Jan 2008 17:08:24 +0000 Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m0HH8HL19148 for ; Thu, 17 Jan 2008 17:08: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: Moving forward with VCAT/LCAS... Date: Thu, 17 Jan 2008 12:08:15 -0500 Message-ID: <29D15BBCA340DA4D8146D38B4924FC7A10E4DFDD@zcarhxm0.corp.nortel.com> In-Reply-To: <015301c853fa$6174c0b0$0200a8c0@your029b8cecfe> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Moving forward with VCAT/LCAS... Thread-Index: AchT/D3n1O6MvMXwQymz43Q3TU1u/QFLk2cQ References: <4783B29F.2010405@grotto-networking.com> <29D15BBCA340DA4D8146D38B4924FC7A10C79C24@zcarhxm0.corp.nortel.com> <015301c853fa$6174c0b0$0200a8c0@your029b8cecfe> From: "Stephen Shew" To: Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Sorry about the delay in responding, I don't check this list daily. A connection can't exist outside of a call. However, if you mean can a server call (with associated connection) exist outside of a client (in this case VCAT) call, the answer is yes. The model I'm responding from assumes that a VCAT call contains only one VCG, and that it has a relationship with one or more server layer calls where those server layer calls contain a connection or connections. It's a more general model for inverse mux. The server layer call could exist ahead of time, and then be allocated to a client call. The client could also disassociate itself from a server layer call and it is an independent decision as to whether that server layer call then releases its connection(s) and terminates. If it stays up, it could be associated with a different client call at a later time. Stephen -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel Sent: January 10, 2008 21:34 To: ccamp@ops.ietf.org Subject: Re: Moving forward with VCAT/LCAS... Stephen, In this architecture, can a connection exist outside a call and then be designated as a connection that fulfils the service identified by the call? Thanks, Adrian ----- Original Message ----- From: "Stephen Shew" To: Sent: Thursday, January 10, 2008 3:04 PM Subject: RE: Moving forward with VCAT/LCAS... Greg, I support these requirements. In transport architecture, layers are separated and this allows a business separation of service. The relationship between the client layer (VCAT in this case) and server layer should be policy driven. That is, the setup/teardown of server layer LSPs in response to client layer requests, should not be automatically coded in a protocol/implementation, but be subject to a policy decision. An additional requirement that's similar to (a), would be to be able to use an existing LSP in response to a VCAT setup. Stephen -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Greg Bernstein Sent: January 8, 2008 12:28 To: ccamp@ops.ietf.org Subject: Moving forward with VCAT/LCAS... Hi CCAMPers, at the Vancouver meeting the status of the VCAT/LCAS draft was discussed and there seemed to be two possible additions to the requirements section of the draft. From the slide presentation these were: (a) Be able to set up member LSPs (and data plane LSPs -- server connections) prior to creation of VCG (Virtual Concatenation Group). (b) "Member" LSPs (data plane and control plane) can exist after a VCG using them has been removed. For those interested in VCAT/LCAS what is your opinion on these additional requirements? This is a WG draft so polling of the list is required (right Adrian?). I'll clean up the language if there is a desire to add these to the current draft. Note that these requirements may break or require rework of the current "multiple co-signaled member sets" solution in the draft. Regards Greg B. -- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=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 From owner-ccamp@ops.ietf.org Thu Jan 17 12:24:07 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFYTH-0003r2-Sl for ccamp-archive@ietf.org; Thu, 17 Jan 2008 12:24:07 -0500 Received: from psg.com ([2001:418:1::62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFYTH-0000hO-DS for ccamp-archive@ietf.org; Thu, 17 Jan 2008 12:24:07 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JFYNR-000Fp8-Ot for ccamp-data@psg.com; Thu, 17 Jan 2008 17:18:05 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [47.140.192.55] (helo=zrtps0kn.nortel.com) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JFYNP-000Fof-1q for ccamp@ops.ietf.org; Thu, 17 Jan 2008 17:18:04 +0000 Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m0HHHxm05730 for ; Thu, 17 Jan 2008 17:18:00 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: Moving forward with VCAT/LCAS... Date: Thu, 17 Jan 2008 12:17:59 -0500 Message-ID: <29D15BBCA340DA4D8146D38B4924FC7A10E4E010@zcarhxm0.corp.nortel.com> In-Reply-To: <005901c856e6$4a9429f0$6501a8c0@alnostro> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Moving forward with VCAT/LCAS... Thread-Index: AchW6HpMEE3z8pLDR6uJiaS5bLNJLwCQ7yHQ References: <005901c856e6$4a9429f0$6501a8c0@alnostro> From: "Stephen Shew" To: Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Alex, I assume that the "one step" case below is simply an optimization of the "loose coupling + policy" approach. That is, the policy is to teardown the server when the client no longer needs it. I think it would be a mistake to define this behaviour in a protocol without the ability to control whether the server layer is torn down when its association with the client layer is removed. Stephen -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Alex Conta Sent: January 14, 2008 14:47 To: ccamp@ops.ietf.org Subject: RE: Moving forward with VCAT/LCAS... Greg, =20 From the perspective of the "users" of a VCG - applications or clients of the VCG which are the layers above the VCG (above both VCG client and server). - the awareness, the information about the VCG members, and furthermore, their presence before, or after VCG creation or tear down, does not really seem relevant, or directly useful.=20 =20 From a "management/provisioning" perspective, setting up the components, independently from the client layer - as a first setup step - and then converting/transforming these elements into VCG members, once a VCG group (and client) has been set up - as a second setup step - and then at tear down, after VCGs tear down, keeping the server elements around, seem to be reducing the number of subsequent setup operations, if those elements can be and are reused with subsequent newly created VCGs. =20 It can be argued though, that in a case - a VCG application - in which existing server elements CANNOT be reused, a one step creation or tearing down of VCGs - in which client and server elements are created/setup, or torn down together, instead of a two step, and keeping server layer elements around - is more appropriate.=20 =20 So the preferred "default" behavior may depend on the type of VCG applications, and could be best left as a choice for the system developer to make.=20 =20 Regards, Alex Conta =20 -----Original Message----- From: Greg Bernstein [mailto:gregb@grotto-networking.com] Sent: Friday, January 11, 2008 11:03 AM To: Alex Conta Subject: Re: Moving forward with VCAT/LCAS... Nice analysis/summary Alex. I like the "looser coupling" + policy (default behavior) approach that you put forward. Let me know if you've got solution preferences (on or off the list). Regards Greg B. From owner-ccamp@ops.ietf.org Thu Jan 17 14:37:42 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFaYY-00072u-TQ for ccamp-archive@ietf.org; Thu, 17 Jan 2008 14:37:42 -0500 Received: from psg.com ([2001:418:1::62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFaYX-0004Ja-Cb for ccamp-archive@ietf.org; Thu, 17 Jan 2008 14:37:42 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JFaRr-0008xR-0J for ccamp-data@psg.com; Thu, 17 Jan 2008 19:30:47 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-202.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE, USER_IN_ALL_SPAM_TO,USER_IN_WHITELIST autolearn=no version=3.2.3 Received: from [156.154.24.139] (helo=ns4.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JFaRo-0008wv-Ez for ccamp@ops.ietf.org; Thu, 17 Jan 2008 19:30:45 +0000 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 9E6632AC8A; Thu, 17 Jan 2008 19:30:41 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1JFaRl-0000b6-D1; Thu, 17 Jan 2008 14:30:41 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce Cc: Internet Architecture Board , RFC Editor , ccamp mailing list , ccamp chair Subject: Document Action: 'Interworking Requirements to Support operation of MPLS-TE over GMPLS Networks' to Informational RFC Message-Id: Date: Thu, 17 Jan 2008 14:30:41 -0500 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d The IESG has approved the following document: - 'Interworking Requirements to Support operation of MPLS-TE over GMPLS Networks ' as an Informational RFC This document is the product of the Common Control and Measurement Plane Working Group. The IESG contact persons are Ross Callon and David Ward. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-mpls-gmpls-interwork-reqts-04.txt Technical Summary This informational document describes Service Provider requirements for operating MPLS-TE networks over GMPLS networks. Working Group Summary No dissent reported (see PROTO writeup by Adrian Farrel). Protocol Quality Ross Callon has reviewed this document for the IESG, and it has been updated based on my (mostly minor clarifying) comments. From sweetmiyu@t-one.net Thu Jan 17 16:25:06 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFcEU-000117-Q2 for ccamp-archive@ietf.org; Thu, 17 Jan 2008 16:25:06 -0500 Received: from [88.251.83.79] (helo=rdzbr) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JFcES-00064a-00 for ccamp-archive@ietf.org; Thu, 17 Jan 2008 16:25:04 -0500 Received: from aok ([189.97.213.115]) by rdzbr (8.13.4/8.13.4) with SMTP id m0HLRDFW015021; Thu, 17 Jan 2008 23:27:13 +0200 Message-ID: <478FC7AA.8010304@t-one.net> Date: Thu, 17 Jan 2008 23:24:58 +0200 From: User-Agent: Thunderbird 1.5.0.13 (Windows/20070809) MIME-Version: 1.0 To: ccamp-archive@ietf.org Subject: I Love Thee Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 A Toast My Love http://24.171.140.213/ From JavierexceedGarrett@eurekalert.org Thu Jan 17 16:58:49 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFcl7-00051h-Rp; Thu, 17 Jan 2008 16:58:49 -0500 Received: from pool-71-255-47-220.syrcny.east.verizon.net ([71.255.47.220] helo=ryan.domainnotset.invalid) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JFcl7-0006rn-FI; Thu, 17 Jan 2008 16:58:49 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host76143496.eurekalert.org (8.13.1/8.13.1) with SMTP id KPMnL1Rf36.356159.bSv.FaZ.0280950638487 for ; Thu, 17 Jan 2008 15:57:52 +0600 Message-ID: <1a3101c85954$2306eb00$4101a8c0@Ryan> From: "Darryl Morrison" To: Subject: piecewise Date: Thu, 17 Jan 2008 15:57:52 +0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_1A2D_01C85954.2306EB00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 3.0 (+++) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f This is a multi-part message in MIME format. ------=_NextPart_000_1A2D_01C85954.2306EB00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable orbit Get your controlled medication at http://www.yesipharm.com ------=_NextPart_000_1A2D_01C85954.2306EB00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable plaque Get your controlled medication at http://www.ipharmplus.com ------=_NextPart_000_1A2D_01C85954.2306EB00-- From RonbootStanley@driverzone.com Thu Jan 17 16:59:09 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFclR-0005aO-UT for ccamp-archive@megatron.ietf.org; Thu, 17 Jan 2008 16:59:09 -0500 Received: from pool-71-255-47-220.syrcny.east.verizon.net ([71.255.47.220] helo=ryan.domainnotset.invalid) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JFclP-0006s6-Gh for ccamp-archive@megatron.ietf.org; Thu, 17 Jan 2008 16:59:07 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host62961791.driverzone.com (8.13.1/8.13.1) with SMTP id FrfYLtDw45.192719.JJk.VtM.9430187235862 for ; Thu, 17 Jan 2008 15:57:52 +0600 Message-ID: <1d4f01c85954$2db7e310$4101a8c0@Ryan> From: "Neil George" To: Subject: formosa Date: Thu, 17 Jan 2008 15:57:52 +0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_1D4B_01C85954.2DB7E310" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 3.0 (+++) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f This is a multi-part message in MIME format. ------=_NextPart_000_1D4B_01C85954.2DB7E310 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable chateau Get your controlled medication at http://www.yesipharm.com ------=_NextPart_000_1D4B_01C85954.2DB7E310 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable boot Get your controlled medication at http://www.yesipharm.com ------=_NextPart_000_1D4B_01C85954.2DB7E310-- From owner-ccamp@ops.ietf.org Thu Jan 17 17:12:04 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFcxw-0005p4-LP for ccamp-archive@ietf.org; Thu, 17 Jan 2008 17:12:04 -0500 Received: from psg.com ([2001:418:1::62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFcxn-0007go-5D for ccamp-archive@ietf.org; Thu, 17 Jan 2008 17:12:04 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JFcmv-0005ZM-Qy for ccamp-data@psg.com; Thu, 17 Jan 2008 22:00:41 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE, RDNS_NONE autolearn=no version=3.2.3 Received: from [216.82.254.243] (helo=mail203.messagelabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JFcmn-0005YS-MB for ccamp@ops.ietf.org; Thu, 17 Jan 2008 22:00:37 +0000 X-VirusChecked: Checked X-Env-Sender: dbrungard@att.com X-Msg-Ref: server-10.tower-203.messagelabs.com!1200607229!725437!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 11047 invoked from network); 17 Jan 2008 22:00:30 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-10.tower-203.messagelabs.com with AES256-SHA encrypted SMTP; 17 Jan 2008 22:00:30 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m0HM0TN9019081; Thu, 17 Jan 2008 17:00:30 -0500 Received: from OCCLUST04EVS1.ugd.att.com (ocst07.ugd.att.com [135.38.164.12]) by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m0HM0Mqx019003; Thu, 17 Jan 2008 17:00:22 -0500 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_01C85954.5B0F5017" Subject: Draft Liaison Response "Response to Liaison on GMPLS Signaling for VCAT/LCAS" Date: Thu, 17 Jan 2008 16:00:20 -0600 Message-ID: <449B2580D802A443A923DABF3EAB82AF100C1B8A@OCCLUST04EVS1.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft Liaison Response "Response to Liaison on GMPLS Signaling for VCAT/LCAS" Thread-Index: AchZVFowqiu/zB1tTPaCDHj9ua2p4w== From: "BRUNGARD, DEBORAH A, ATTLABS" To: Cc: "Adrian Farrel" , "Ross Callon" , "David Ward" Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 8f671485bda3f2f1be548f998883cfbd This is a multi-part message in MIME format. ------_=_NextPart_001_01C85954.5B0F5017 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable CCAMP, Here's a proposed response to ITU's Liaison: https://datatracker.ietf.org/liaison/371/ Any comments? Thanks, Deborah and Adrian =3D=3D=3D=3D Title: Response to Liaison on GMPLS Signaling for VCAT/LCAS Purpose: For Action Body: The CCAMP Working Group thanks you for your liaison of September 2007 (Q12-14 Interim meeting - LS 005). Here are our responses to the questions in your liaison: Your Question 1: We provide here further clarification regarding our previous comment re protocol extensibility to encompass technologies other than SONET/SDH. An example technology of interest to the community was provided regarding the usage of virtually concatenated ODUs for carriage of IEEE 802.3 HSSG proposed 100 Gbit/s over an existing OTN infrastructure. How this is accomplished is not defined at this time and might not be using VCAT. A technology neutral approach (i.e., one not dependent upon VCAT over SONET/SDH-unique parameters) would avoid the need for developing a series of specialized solutions. Our response: As we noted previously, it is certainly our intention that functionality and any protocol extensions that we develop should be easily extensible to support other than SONET/SDH technology, especially technologies covered by GMPLS (e.g. OTN). This is the basis of GMPLS and GMPLS call functionality development. If you have identified any specific concerns with the current approach, we would appreciate your input. Your Question 2: VCAT group signaling relates closely to multi-layer call modeling, and it is our understanding that the draft is only addressing the constituent server layer call. We plan to perform further work to clarify the interlayer call relationship in terms of the ASON multilayer "call supporting call construct". Our response: Noted. We look forward to further communication from you. Your Question 3: We agree that connections are not moved between calls; the ASON "call supporting calls" construct is consistent with not moving connections between calls. Rec. G.7041 and G.7042 are only concerned with membership of the VCAT group, and not with the use of a member that has been removed (it is assumed to simply go back into the pool of resources, where it can be drawn upon for other purposes). Thus G.7041 and G.7042 do not support the direct movement of a connection from one VCAT group to another. Changing the association of a server layer call/connection to a VCAT group does not necessarily result in removal/deletion of that call/connection. Our response: Noted. Your Question 4: We appreciate your clarification of the use of a single call. However we suggest that you do not preclude extension to use multiple calls. This is useful for example in diverse routing applications. Our response: As noted in our previous liaison, the call construct as proposed in this draft is used to coordinate the (single type) server layer connections for the VCAT functionality. This does not preclude use of RFC 4974 in support of G.8080 call functionality. To ensure that we understand correctly your request, can you provide additional information regarding using multiple calls in support of diverse routing applications? Your Question 5: We understand that this draft is only addressing the constituent server layer call; i.e., not the ASON multilayer call supporting call construct. However, we suggest that you do not preclude extensions to use a call in the VCAT layer. Our response: As noted above, this is not precluded. We look forward to future communication from you as you progress this work. Your Question 6: We understand that GMPLS only supports the IP address format, and that the actual addresses may be different in each layer. We believe it would be useful to clarify the difference between addresses used in regards to delivering messages to a control component, and identifiers used for the forwarding plane resources themselves. Our response: Please refer to RFC 4990. This draft does not modify existing procedures. If you have any questions with regard to GMPLS addressing, we welcome informal dialogue on the CCAMP exploder and, of course, you may also ask via Liaison. Your Question 7: Thank you for the clarification which confirms that the VCAT layer Call Controllers are assumed to be adjacent from a control plane perspective. Our response: Noted. To ensure that we understand your question on "direct signalling connectivity" and "adjacent", to be precise, it is assumed that the Call Controllers can exchange call control messages. This does not require that they be adjacent. Your Question 8: Thank you for the clarification. Our response: Noted. Your Question 9: Based upon your observation, we view that a protocol independent definition of the call ID should be abstracted from G.7713.2, where it is expressed in protocol specific terms; the most appropriate Recommendation for this definition would be G.7713. Our response: Thank you for the clarification. Your Question 10: Your interpretation of G.8080 is correct regarding E-NNI reference points and adjacent call controllers. There is no reference to RSVP sessions in G.8080; it was used as an example of the consequence of using different protocols in different domains. It is our understanding from the discussions that concatenated GMPLS RSVP-TE connections (homogenous signaling protocol) that are part of the same end-to-end network connection do not need to change the session object, and policy could be applied at a transit (inter-domain) hop. Please confirm that our understanding is correct. Our response: Your understanding is correct that even though one session is used, policy may be applied by any processing node (manager) of the call message, and RFC4974 supports multiple call managers along the path between ingress and egress. Please refer to RFC 4974. Note, the RSVP signaling protocol model allows for the application of local policy by any processing node of the request (regardless if a connection or call). The latest version of this work can be found at: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-vcat-lcas-03. txt We welcome any further comments. Best regards, Adrian Farrel and Deborah Brungard IETF CCAMP working group co-chairs Attachment(s): No document has been attached =20 ------_=_NextPart_001_01C85954.5B0F5017 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

CCAMP,

Here's a proposed=20 response to ITU's Liaison:

https://datatracker.ie= tf.org/liaison/371/

Any=20 comments?

Thanks,

Deborah and=20 Adrian

=3D=3D=3D=3D

Title: Response to Liaison on GMPLS Signaling for=20 VCAT/LCAS

Purpose: For Action

Body:

The = CCAMP Working=20 Group thanks you for your liaison of September 2007 (Q12-14 Interim = meeting - LS=20 005).

Here = are our=20 responses to the questions in your liaison:

Your=20 Question 1: We=20 provide here further clarification regarding our previous comment re = protocol=20 extensibility to encompass technologies other than SONET/SDH.  An example technology of = interest to the=20 community was provided regarding the usage of virtually concatenated = ODUs for=20 carriage of IEEE 802.3 HSSG proposed 100 Gbit/s over an existing OTN=20 infrastructure.  How this = is=20 accomplished is not defined at this time and might not be using VCAT. A=20 technology neutral approach (i.e., one not dependent upon VCAT over=20 SONET/SDH-unique parameters) would avoid the need for developing a = series of=20 specialized solutions.

Our = response: As we=20 noted previously, it is certainly our intention that functionality and = any=20 protocol extensions that we develop should be easily extensible to = support other=20 than SONET/SDH technology, especially technologies covered by GMPLS = (e.g. OTN).=20 This is the basis of GMPLS and GMPLS call functionality development. If = you have=20 identified any specific concerns with the current approach, we would = appreciate=20 your input.

Your Question=20 2:  VCAT group signaling = relates=20 closely to multi-layer call modeling, and it is our understanding that = the draft=20 is only addressing the constituent server layer call.   We plan to perform = further work to=20 clarify the interlayer call relationship in terms of the ASON multilayer = “call=20 supporting call construct”.

Our=20 response: Noted. We look forward to further communication from=20 you.

Your=20 Question 3:   We = agree that=20 connections are not moved between calls; the ASON “call supporting = calls”=20 construct is consistent with not moving connections between calls.  Rec. G.7041 and G.7042 are = only=20 concerned with membership of the VCAT group, and not with the use of a = member=20 that has been removed (it is assumed to simply go back into the pool of=20 resources, where it can be drawn upon for other purposes).  Thus G.7041 and G.7042 do not = support=20 the direct movement of a connection from one VCAT group to another. = Changing the=20 association of a server layer call/connection to a VCAT group does not=20 necessarily result in removal/deletion of that=20 call/connection.

Our=20 response: Noted.

Your Question=20 4:  We appreciate your = clarification=20 of the use of a single call. However we suggest that you do not preclude = extension to use multiple calls. This is useful for example in diverse = routing=20 applications.

=

Our=20 response: As=20 noted in our previous liaison, the call construct as proposed in this = draft is=20 used to coordinate the (single type) server layer connections for the = VCAT=20 functionality. This does not preclude use of RFC 4974 in support of = G.8080 call=20 functionality. To ensure that we understand correctly your request, can = you=20 provide additional information regarding using multiple calls in support = of=20 diverse routing=20 applications?

Your Question=20 5:  We understand that = this draft is=20 only addressing the constituent server layer call; i.e., not the ASON = multilayer=20 call supporting call construct. However, we suggest that you do not = preclude=20 extensions to use a call in the VCAT=20 layer.

Our=20 response: As noted above, this is not precluded. We look forward to = future=20 communication from you as you progress this=20 work.

Your Question=20 6:  We understand that = GMPLS only=20 supports the IP address format, and that the actual addresses may be = different=20 in each layer.  We believe = it would=20 be useful to clarify the difference between addresses used in regards to = delivering messages to a control component, and identifiers used for the = forwarding plane resources=20 themselves.

Our=20 response: Please=20 refer to RFC 4990. This draft does not modify existing procedures. If = you have=20 any questions with regard to GMPLS addressing, we welcome informal = dialogue on=20 the CCAMP exploder and, of course, you may also ask via=20 Liaison.

Your=20 Question=20 7:  Thank you for the = clarification=20 which confirms that the VCAT layer Call Controllers are assumed to be = adjacent=20 from a control plane=20 perspective.

Our=20 response: Noted. To ensure that we understand your question on "direct=20 signalling connectivity" and "adjacent", to be precise, it is assumed = that the=20 Call Controllers can exchange call control messages. This does not = require that=20 they be=20 adjacent.<= /SPAN>

Your=20 Question=20 8:  Thank you for the=20 clarification.

Our=20 response:=20 Noted.

Your=20 Question=20 9:  Based upon your = observation, we=20 view that a protocol independent definition of the call ID should be = abstracted=20 from G.7713.2, where it is expressed in protocol specific terms; the = most=20 appropriate Recommendation for this definition would be=20 G.7713.

Our=20 response: Thank you for the=20 clarification.

Your=20 Question=20 10:  Your interpretation = of G.8080=20 is correct regarding E-NNI reference points and adjacent call = controllers.  There is no reference to RSVP = sessions=20 in G.8080; it was used as an example of the consequence of using = different=20 protocols in different domains.  = It=20 is our understanding from the discussions that concatenated GMPLS = RSVP-TE=20 connections (homogenous signaling protocol) that are part of the same = end-to-end=20 network connection do not need to change the session object, and policy = could be=20 applied at a transit (inter-domain) hop.  Please confirm that our = understanding is=20 correct.

Our=20 response: Your=20 understanding is correct that even though one session is used, policy = may be=20 applied by any processing node (manager) of the call message, = and=20 RFC4974 supports multiple call managers along the path between ingress = and=20 egress. Please refer to RFC 4974. Note, the RSVP signaling protocol = model allows=20 for the application of local policy by any processing node of the=20 request (regardless if a connection or=20 call).

The latest = version of this=20 work can be found at:

http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-vc= at-lcas-03.txt

We = welcome any=20 further comments.

Best regards,

Adrian Farrel and=20 Deborah Brungard

IETF CCAMP=20 working group co-chairs

Attachment(s):=20 No document has been attached

 

 ------_=_NextPart_001_01C85954.5B0F5017-- From philtero48@pegasuscrossing.com Thu Jan 17 17:28:42 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFdE2-00087O-3x for ccamp-archive@megatron.ietf.org; Thu, 17 Jan 2008 17:28:42 -0500 Received: from [88.239.39.98] (helo=[88.239.39.98]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFdDf-0007WA-I4 for ccamp-archive@megatron.ietf.org; Thu, 17 Jan 2008 17:28:39 -0500 Received: from [88.239.39.98] by mxvm3.mail.yahoo.com; Fri, 18 Jan 2008 00:28:19 +0200 From: "Christina Mcleod" To: Subject: SashaPhallusCapacious Date: Fri, 18 Jan 2008 00:28:19 +0200 Message-ID: <01c85969$062b5380$6227ef58@philtero48> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Importance: Normal X-Spam-Score: 3.0 (+++) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 AlvaPenisPuffy http://www.farstes.com From Karolannehermed@RIMO.COM.BR Thu Jan 17 19:06:51 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFel1-00084e-DH for ccamp-archive@ietf.org; Thu, 17 Jan 2008 19:06:51 -0500 Received: from [195.137.253.188] (helo=[195.137.253.188]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFekz-0001P2-Sv for ccamp-archive@ietf.org; Thu, 17 Jan 2008 19:06:50 -0500 Received: from RECEPTION1 ([115.153.37.50]:7626 "EHLO RECEPTION1" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by [195.137.253.188] with ESMTP id S22VTNWFUYUMPUOW (ORCPT ); Fri, 18 Jan 2008 02:07:20 +0200 Message-ID: Date: Fri, 18 Jan 2008 02:06:47 +0200 From: "Karolanne hermed" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: ccamp-archive@ietf.org Subject: sumlefpa Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Good evening ccamp-archive Be really proud, that you are da Man! http://coverhuman.com Karolanne hermed From KylahSchommer@district2council.org Thu Jan 17 22:52:13 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFiH7-0004zb-7n for ccamp-archive@ietf.org; Thu, 17 Jan 2008 22:52:13 -0500 Received: from [202.131.1.12] (helo=[202.131.1.12]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFiH6-0005pt-Ch for ccamp-archive@ietf.org; Thu, 17 Jan 2008 22:52:12 -0500 Received: from khanaa ([190.198.32.136] helo=khanaa) by [202.131.1.12] ( sendmail 8.13.3/8.13.1) with esmtpa id 1iGFkF-000ZLD-TI for ccamp-archive@ietf.org; Fri, 18 Jan 2008 11:50:15 +0800 Message-ID: Date: Fri, 18 Jan 2008 11:49:41 +0800 From: "Kylah Schommer" User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: ccamp-archive@ietf.org Subject: akcmtrof Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 2.6 (++) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Day dreaming of ladies awing at your peak of perfection. Make it
happen with VPX|_ now! http://racingslur.com/
From AnniebarreMadison@nysun.com Fri Jan 18 00:08:54 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFjTK-0007vu-2U; Fri, 18 Jan 2008 00:08:54 -0500 Received: from [201.116.152.60] (helo=intel) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JFjTH-0007LJ-E2; Fri, 18 Jan 2008 00:08:51 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host21929071.nysun.com (8.13.1/8.13.1) with SMTP id DAYpU4XA75.245889.Ffn.MpI.1325852923215 for ; Thu, 17 Jan 2008 22:08:22 +0700 Message-ID: From: "Robin Blanton" To: Cc: , =20

When you are young and stressed = up…
When you are aged and never give up…
Even if you have no erection problems Viagra would help you to make = better=20 sex more often.
Learn More Now

------=_NextPart_000_A6C0_01C85990.3164A020-- From ikcrazy@cniweb.net Fri Jan 18 01:28:27 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFkiI-0007lV-KV; Fri, 18 Jan 2008 01:28:26 -0500 Received: from 200-85-197-35.bk3-dsl.surnet.cl ([200.85.197.35] helo=cniweb.net) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JFkiE-0000yo-QH; Fri, 18 Jan 2008 01:28:23 -0500 Received: from MECHE ([68.184.64.233]:16649 "HELO MECHE" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by 23c555c8cniweb.net with ESMTP id 50319E43792CB5 (ORCPT ); Fri, 18 Jan 2008 03:28:28 -0400 Message-ID: <001301c85982$30f98aa0$0194126c@MECHE> From: Stevie Pickens To: ccamp-archive@ietf.org Subject: my rail Date: Fri, 18 Jan 2008 03:28:28 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0010_01C85982.30F98AA0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.2969 X-Mimeole: Produced By Microsoft MimeOLE V6.00.3790.2962 X-Spam-Score: 1.7 (+) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 This is a multi-part message in MIME format. ------=_NextPart_000_0010_01C85982.30F98AA0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable meaning were put in situations where they had to pretend that great technological advancements and now we're at a threshold. be growth, a= nd if you like expanding your mind and being lets ------=_NextPart_000_0010_01C85982.30F98AA0 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable

is that each individual is different and will react to virtual

Proven method for a bi/gg er pe \nis?

As Seen On T V

Ov /er 791,000 Men aro /und the world are already sat \isfied
Gain 2+ Inc /hes In Len /gth
Inc \rease Your Pe /nis Wid /th (Gir \th) By u/p-to 24%
100% S \afe To Take, With NO Side Effe /cts
N o Pu \mps! N o Su \rgery! N o Exe \rcises!

affected the fields of Cybernetics, Virtual Reality, artificial
------=_NextPart_000_0010_01C85982.30F98AA0-- From insectivoresd0@suryani.net Fri Jan 18 07:26:47 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFqJ5-0005xt-83 for ccamp-archive@megatron.ietf.org; Fri, 18 Jan 2008 07:26:47 -0500 Received: from fj043.net117104038.thn.ne.jp ([117.104.38.43] helo=cintia-fg7moko0.thn.ne.jp) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFqJ3-0001mH-RY for ccamp-archive@megatron.ietf.org; Fri, 18 Jan 2008 07:26:46 -0500 Received: from [117.104.38.43] by mx1.biz.mail.yahoo.com; Fri, 18 Jan 2008 21:58:04 +0900 From: "Dwight Huffman" To: Subject: BurtErectileorganBulky Date: Fri, 18 Jan 2008 21:58:04 +0900 Message-ID: <01c85a1d$33b83200$2b266875@insectivoresd0> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal X-Spam-Score: 2.9 (++) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 CarsonMountainousPenis http://manningss.com From serengetis6@vrieling-beilen.com Fri Jan 18 07:51:23 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFqgt-0003Wx-4V for ccamp-archive@megatron.ietf.org; Fri, 18 Jan 2008 07:51:23 -0500 Received: from [195.201.130.9] (helo=comp.new-star.local) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFqgr-0002FM-Oz for ccamp-archive@megatron.ietf.org; Fri, 18 Jan 2008 07:51:22 -0500 Received: from [195.201.130.9] by mail01.wxs.nl; Fri, 18 Jan 2008 15:51:20 +0300 From: "Noreen Heath" To: Subject: CockMan-sizedCurtis Date: Fri, 18 Jan 2008 15:51:20 +0300 Message-ID: <01c859e9$f7d14c00$0982c9c3@serengetis6> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal X-Spam-Score: 3.0 (+++) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 PlumpingShlongDoreen http://www.fiutitd.com From Austin.Miller@organami.com Fri Jan 18 13:49:06 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFwH4-0007WH-1F for ccamp-archive@ietf.org; Fri, 18 Jan 2008 13:49:06 -0500 Received: from ip-89-102-98-231.karneval.cz ([89.102.98.231] helo=doma-48cbe9fbe5.chello.upc.cz) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFwH0-00077T-SQ for ccamp-archive@ietf.org; Fri, 18 Jan 2008 13:49:03 -0500 Received: from [89.102.98.231] by mail.organami.com; Fri, 17 Jan 2008 20:02:15 +0100 Date: Fri, 17 Jan 2008 20:02:15 +0100 From: "Curtis Cochran" X-Mailer: The Bat! (v2.10.01) Educational Reply-To: Austin.Miller@organami.com X-Priority: 3 (Normal) Message-ID: <203818012.37969893914315@organami.com> To: ccamp-archive@ietf.org Subject: To: l ccamp-archive j MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------25FF84016E1DAE1" X-Spam-Score: 2.4 (++) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 ------------25FF84016E1DAE1 Content-Type: text/plain; charset=Windows-1252 Content-Transfer-Encoding: 7bit Christmas Man's POWER CHARGE viagra + cialis 10 + 10 = 74.95 20 + 20 = 127.95 30 + 30 = 162.95 20 % discount Time Limited Offer ORDER NOW! ------------25FF84016E1DAE1 Content-Type: text/html; charset=Windows-1252 Content-Transfer-Encoding: 7bit Christmas Man's POWER CHARGE
viagra + cialis
10 + 10 = 74.95
20 + 20 = 127.95
30 + 30 = 162.95
20 % discount
Time Limited Offer
ORDER NOW! ------------25FF84016E1DAE1-- From EmersonawfulDotson@mngop.com Fri Jan 18 13:55:34 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFwNJ-00018y-Is; Fri, 18 Jan 2008 13:55:33 -0500 Received: from [151.23.136.37] (helo=xpmodu) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JFwNH-0007HZ-Af; Fri, 18 Jan 2008 13:55:33 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host25433821.mngop.com (8.13.1/8.13.1) with SMTP id 4EEIKo8z03.526969.17N.0Wz.3983181631194 for ; Fri, 18 Jan 2008 19:57:04 -0100 Message-ID: <44f9001c85a03$f3aafc10$0201a8c0@xpmodu> From: "Danial Nolan" To: Subject: Hi Date: Fri, 18 Jan 2008 19:57:04 -0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_44F8C_01C85A03.F3AAFC10" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d This is a multi-part message in MIME format. ------=_NextPart_000_44F8C_01C85A03.F3AAFC10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable When you are young and stressed up… When you are aged and never give up… Even if you have no erection problems Viagra would help you to make = better sex more often. Learn More Now ------=_NextPart_000_44F8C_01C85A03.F3AAFC10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20

When you are young and stressed = up…
When you are aged and never give up…
Even if you have no erection problems Viagra would help you to make = better=20 sex more often.
Learn More Now

------=_NextPart_000_44F8C_01C85A03.F3AAFC10-- From McVeigh@CS.McGill.CA Fri Jan 18 15:55:36 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFyFU-0005cg-Bc for ccamp-archive@ietf.org; Fri, 18 Jan 2008 15:55:36 -0500 Received: from [88.87.86.28] (helo=host-86-75.elsv-v.ru) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JFyFT-0004CB-En for ccamp-archive@ietf.org; Fri, 18 Jan 2008 15:55:36 -0500 Received: from comp ([199.114.197.137] helo=comp) by host-86-75.elsv-v.ru ( sendmail 8.13.3/8.13.1) with esmtpa id 1DGeqh-000TZU-CK for ccamp-archive@ietf.org; Fri, 18 Jan 2008 23:55:47 +0300 Message-ID: <8DC780AE.F6D4AE7B@CS.McGill.CA> Date: Fri, 18 Jan 2008 23:55:35 +0300 From: "lubomila McVeigh" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: ccamp-archive@ietf.org Subject: uotaunis Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 2.1 (++) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Regards ccamp-archive You’re Gettin’ a Wood! http://outexcite.com lubomila McVeigh From owner-ccamp@ops.ietf.org Fri Jan 18 16:45:48 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JFz24-0007jg-4Z for ccamp-archive@ietf.org; Fri, 18 Jan 2008 16:45:48 -0500 Received: from psg.com ([2001:418:1::62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JFz23-00077S-Fw for ccamp-archive@ietf.org; Fri, 18 Jan 2008 16:45:48 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JFytr-0005kU-Eb for ccamp-data@psg.com; Fri, 18 Jan 2008 21:37:19 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [216.82.250.83] (helo=mail120.messagelabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JFyto-0005jT-Rq for ccamp@ops.ietf.org; Fri, 18 Jan 2008 21:37:18 +0000 X-VirusChecked: Checked X-Env-Sender: dbrungard@att.com X-Msg-Ref: server-15.tower-120.messagelabs.com!1200692232!3053560!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 3859 invoked from network); 18 Jan 2008 21:37:12 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-15.tower-120.messagelabs.com with AES256-SHA encrypted SMTP; 18 Jan 2008 21:37:12 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m0ILbBIj007158 for ; Fri, 18 Jan 2008 16:37:11 -0500 Received: from OCCLUST04EVS1.ugd.att.com (ocst07.ugd.att.com [135.38.164.12]) by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m0ILb5px007117 for ; Fri, 18 Jan 2008 16:37:06 -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: FW: Internet-Drafts Submission Cutoff Dates for the 71st IETF Meeting in Philadelphia, PA, USA Date: Fri, 18 Jan 2008 15:37:04 -0600 Message-ID: <449B2580D802A443A923DABF3EAB82AF100C23FE@OCCLUST04EVS1.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Internet-Drafts Submission Cutoff Dates for the 71st IETF Meeting in Philadelphia, PA, USA Thread-Index: AchZj3z1Jh0Sq67wRFC4lRiYhD6W4gAipcIw From: "BRUNGARD, DEBORAH A, ATTLABS" To: Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 FYI - dates for submitting drafts. -----Original Message----- From: ietf-secretariat@ietf.org [mailto:ietf-secretariat@ietf.org]=20 Sent: Friday, January 18, 2008 12:00 AM To: ietf-announce@ietf.org Subject: Internet-Drafts Submission Cutoff Dates for the 71st IETF Meeting in Philadelphia, PA, USA=20 There are two (2) Internet-Draft cutoff dates for the 71st=20 IETF Meeting in Philadelphia, PA, USA: February 18th: Cutoff Date for Initial (i.e., version -00)=20 Internet-Draft Submissions=20 All initial Internet-Drafts (version -00) must be submitted by Monday,=20 February 18th at 9:00 AM ET (14:00 UTC/GMT).The only exception is for version -00 WG drafts that replace existing non-WG drafts. Such drafts may be submitted until the cutoff date for version -01 and higher drafts. As always, all initial submissions with a filename beginning with=20 "draft-ietf" must be approved by the appropriate WG Chair before they=20 can be processed or announced. The Secretariat would appreciate=20 receiving WG Chair approval by Monday, February 11th at 9:00 AM ET (14:00 UTC/GMT). February (14:00 UTC/GMT): Cutoff Date for Revised (i.e., version -01 and higher)=20 Internet-Draft Submissions=20 All revised Internet-Drafts (version -01 and higher) must be submitted=20 by Monday, February 25th at 9:00 AM ET (14:00 UTC/GMT). Initial and revised Internet-Drafts received after their respective=20 cutoff dates will not be made available in the Internet-Drafts=20 directory or announced until on or after Monday, March 10th at 9:00=20 AM ET (13:00 UTC/GMT), when Internet-Draft posting resumes. Please do not wait until=20 the last minute to submit. The Secretariat encourages you to submit your Internet-Drafts via the=20 Internet-Draft Submission Tool (IDST) https://datatracker.ietf.org/idst/upload.cgi.=20 If you are unable to do so, then you may still submit your Internet- Drafts manually by sending them to internet-drafts@ietf.org. If you=20 are submitting a version -00 WG draft that replaces non-WG draft, then=20 you must submit it manually as the current IDST cannot handle=20 replacements. Please be sure to state that one draft replaces another=20 in the cover note that accompanies your submission. Also, please note=20 that the IDST will not accept drafts submitted after their respective=20 cutoff dates. Thank you for your understanding and cooperation. If you have any=20 questions or concerns, then please send a message to=20 internet-drafts@ietf.org. The IETF Secretariat FYI: The Internet-Draft cutoff dates as well as other significant dates for the 71st IETF Meeting can be found at http://www.ietf.org/meetings/71-cutoff_dates.html. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce From velvetieroen921@protectgard.com Fri Jan 18 19:18:30 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JG1Pp-0004zN-VP for ccamp-archive@ietf.org; Fri, 18 Jan 2008 19:18:30 -0500 Received: from h60.156.146.64.coastaccess.com ([64.146.156.60] helo=Weatherly.cablerocket.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JG1Po-0000Ct-RS for ccamp-archive@ietf.org; Fri, 18 Jan 2008 19:18:29 -0500 Received: from [64.146.156.60] by INBOUND.PROTECTGARD.COM.NETSOLMAIL.NET; Fri, 18 Jan 2008 16:18:28 -0800 From: "Nickolas Lovell" To: Subject: FuckstickBouffantMervin Date: Fri, 18 Jan 2008 16:18:28 -0800 Message-ID: <01c859ed$c22e6200$3c9c9240@velvetieroen921> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.2300 Importance: Normal X-Spam-Score: 4.9 (++++) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 DickWhoppingFrancesca http://www.malittlepony.com From Hinshaw@leather.colorado.edu Fri Jan 18 20:49:56 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JG2qK-0001PN-CP for ccamp-archive@megatron.ietf.org; Fri, 18 Jan 2008 20:49:56 -0500 Received: from [88.255.196.90] (helo=[88.255.196.90]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JG2qJ-0003pf-MO for ccamp-archive@megatron.ietf.org; Fri, 18 Jan 2008 20:49:56 -0500 Received: from atraksiyon ([180.181.50.65]:14772 "EHLO atraksiyon" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by [88.255.196.90] with ESMTP id S22DSVJESIUASOFB (ORCPT ); Sat, 19 Jan 2008 03:50:16 +0200 Message-ID: <26A19F3B.25309B45@leather.colorado.edu> Date: Sat, 19 Jan 2008 03:49:55 +0200 From: "maximiano Hinshaw" User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: ccamp-archive@megatron.ietf.org Subject: itardano Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 2.6 (++) X-Scan-Signature: 08e48e05374109708c00c6208b534009 All the chicks will dig your giant dick! http://www.vlouet.com/
From Riipinenynsi@Ldschurch.org Sat Jan 19 07:32:17 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGCrx-0004nV-Si for ccamp-archive@ietf.org; Sat, 19 Jan 2008 07:32:17 -0500 Received: from [201.79.96.244] (helo=20179096244.user.veloxzone.com.br) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JGCrw-0001U9-ER for ccamp-archive@ietf.org; Sat, 19 Jan 2008 07:32:17 -0500 Received: from jogos ([124.105.103.33] helo=jogos) by 20179096244.user.veloxzone.com.br ( sendmail 8.13.3/8.13.1) with esmtpa id 1ugsLa-000TJU-ER for ccamp-archive@ietf.org; Sat, 19 Jan 2008 10:32:35 -0200 Message-ID: <000c01c85a97$521c5850$f4604fc9@jogos> From: "Borvonwit Riipinen" To: Subject: elihpoxo Date: Sat, 19 Jan 2008 10:32:14 -0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C85A86.8E938850" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 2.1 (++) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 ------=_NextPart_000_0005_01C85A86.8E938850 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Good night ccamp-archive We work harder, so you don't have to http://possibledegree.com Borvonwit Riipinen ------=_NextPart_000_0005_01C85A86.8E938850 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Good night ccamp-archive
We work harder, so you don't have = to
http://possibledegree.com
Borvonwit Riipinen
------=_NextPart_000_0005_01C85A86.8E938850-- From Vicsaiiluf@infratech.com.au Sat Jan 19 08:57:37 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGECX-0001t2-Ra for ccamp-archive@ietf.org; Sat, 19 Jan 2008 08:57:37 -0500 Received: from [85.97.161.241] (helo=dsl.dynamic8597161241.ttnet.net.tr) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JGECW-0003Jj-B8 for ccamp-archive@ietf.org; Sat, 19 Jan 2008 08:57:36 -0500 Received: by 10.20.87.163 with SMTP id UOkaFYBKQRkzj; Sat, 19 Jan 2008 15:57:38 +0200 (GMT) Received: by 192.168.68.230 with SMTP id wAtYJwNUCweyfZ.4564071687110; Sat, 19 Jan 2008 15:57:36 +0200 (GMT) Message-ID: <9FB1DFE4.D92343C3@infratech.com.au> Date: Sat, 19 Jan 2008 15:57:33 +0200 From: "Parbhu Vicsai" User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: ccamp-archive@ietf.org Subject: leanlimb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 4.5 (++++) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Have a cannon in your pants the size of a howitzer http://www.flakouts.com/
From guillermoiacona@clarionhotelliffeyvalley.com Sat Jan 19 12:08:10 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGHAw-0004CL-45 for ccamp-archive@ietf.org; Sat, 19 Jan 2008 12:08:10 -0500 Received: from [88.227.171.2] (helo=yhfuinx) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JGHAv-0007hu-Ci for ccamp-archive@ietf.org; Sat, 19 Jan 2008 12:08:09 -0500 Received: (qmail 2049 invoked from network); Sat, 19 Jan 2008 19:08:05 +0200 Received: from unknown (HELO qaf) (98.125.142.31) by yhfuinx with SMTP; Sat, 19 Jan 2008 19:08:05 +0200 Message-ID: <47922E75.1080307@clarionhotelliffeyvalley.com> Date: Sat, 19 Jan 2008 19:08:05 +0200 From: User-Agent: Thunderbird 1.5.0.13 (Windows/20070809) MIME-Version: 1.0 To: ccamp-archive@ietf.org Subject: Bright colors of your night life! Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 080119-0, 19/01/2008), Outbound message X-Antivirus-Status: Clean X-Spam-Score: 0.1 (/) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 Suck it and see http://xpavxx.endfeel.com From lillian@ws.lukoil.com Sat Jan 19 13:39:08 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGIay-0002Af-Th for ccamp-archive@ietf.org; Sat, 19 Jan 2008 13:39:08 -0500 Received: from host158-165-static.24-87-b.business.telecomitalia.it ([87.24.165.158]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JGIay-0001kw-8e for ccamp-archive@ietf.org; Sat, 19 Jan 2008 13:39:08 -0500 Message-ID: <000901c85aca$035692c3$3fdbcdb0@yelvgn> From: "lambert@navsys.com|dns1.xspedius.net|207.191.50.10|dns4.xspedius.net|206.222.97.82|oracle.navsys.com|216.253.86.196" To: Subject: Managers needed Date: Sat, 19 Jan 2008 16:51:50 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C85ACA.03561FEE" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 This is a multi-part message in MIME format. ------=_NextPart_000_0006_01C85ACA.03561FEE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 Part-time job in USA. =20 =20 =20 =20 =20 http://hkids-europe.org/job.php =20 =20 =20 =20 =20 =20 =20 ------=_NextPart_000_0006_01C85ACA.03561FEE Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable


=20

Part-time=20 job in USA.

http://hkids-europe.org/job.php
------=_NextPart_000_0006_01C85ACA.03561FEE-- From jewelnewellic@unilever.com Sat Jan 19 14:02:17 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGIxN-0006OJ-9S; Sat, 19 Jan 2008 14:02:17 -0500 Received: from [77.205.32.11] (helo=szsti.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JGIxL-0002Fw-Jz; Sat, 19 Jan 2008 14:02:17 -0500 Reply-To: "Jewel Newell" Date: Sat, 19 Jan 2008 13:46:25 -0700 In-Reply-To: From: "Jewel Newell" Subject: Look Rich withRolexOmegaBreitling, 90% Off Original Price lj0s9b10esugf2i3i0f1 To: ieprep@ietf.org Bcc: hubmib-bounces@ietf.org, ccamp-archive@ietf.org, ldap-dir-bounces@ietf.org X-Sender: Sender: Message-ID: <1200775585.5934@unilever.com> Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 8bit X-Spam-Score: 0.3 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 ** We add 100 Latest Arrival 2008 models Watches ** /// Safe & guaranteed shopping \\\ /// Inquiries answered in 24 hours \\\ /// Over 1360 Models to choose from \\\ Swiss QualityReplica Many World famous LUXURY BRANDS Free 1 year Warranty on all Watches http://Shereeil73.googlepages.com From JerrycircumpolarBaker@thepokerchronicles.com Sat Jan 19 17:20:58 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGM3e-0006mi-2C; Sat, 19 Jan 2008 17:20:58 -0500 Received: from [88.238.100.115] (helo=hallabay) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JGM3d-0006Tv-FF; Sat, 19 Jan 2008 17:20:57 -0500 Message-ID: <6ccc01c85ae9$84aeff00$eeeea8c0@hallabay> From: "Matthew Hernandez" To: , =20
Your credit score = doesn't matter=20 to us!
=20
 
If you have your own = business and=20 need IMMEDIATE money to spend ANY way you like or want Extra money to = give your=20 business a boost or require A low interest loan - NO STRINGS ATTACHED, = here is=20 best deal we can offer you THIS NIGHT (hurry, this deal will expire=20 NOW):
=20
 
$51,000+ = loan
 
Hurry, when best deal = is gone, it=20 is gone. Simply fill out this quick form...
=20
 
Don't worry about = approval, your=20 credit score will not disqualify you!
=20
 
http://grandplaceb.net.cn/
------=_NextPart_000_6CC8_01C85AE9.84AEFF00-- From Mingli-daicos@bwin.com.tw Sun Jan 20 01:51:46 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGU1y-00083E-Dh for ccamp-archive@ietf.org; Sun, 20 Jan 2008 01:51:46 -0500 Received: from [207.112.6.250] (helo=[207.112.6.250]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JGU1x-0001er-UW for ccamp-archive@ietf.org; Sun, 20 Jan 2008 01:51:46 -0500 Received: from Yemifas ([137.143.91.7] helo=Yemifas) by [207.112.6.250] ( sendmail 8.13.3/8.13.1) with esmtpa id 1OkpTK-000TLZ-Vv for ccamp-archive@ietf.org; Sun, 20 Jan 2008 01:52:01 -0500 Message-ID: <000a01c85b30$ec5c7820$fa0670cf@Yemifas> From: "Mingli daicos" To: Subject: izostele Date: Sun, 20 Jan 2008 01:51:46 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C85B07.03867020" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 ------=_NextPart_000_0005_01C85B07.03867020 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hello ccamp-archive Helping geezers score since 1999 http://arrangepiece.com Mingli daicos ------=_NextPart_000_0005_01C85B07.03867020 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
hello ccamp-archive
Helping geezers score since 1999
http://arrangepiece.com
Mingli daicos
------=_NextPart_000_0005_01C85B07.03867020-- From zgsystemic@hudsonrci.com Sun Jan 20 03:37:26 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGVgE-0001Bj-Ep for ccamp-archive@ietf.org; Sun, 20 Jan 2008 03:37:26 -0500 Received: from [218.26.12.30] (helo=hudsonrci.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JGVgA-00041t-Ql for ccamp-archive@ietf.org; Sun, 20 Jan 2008 03:37:24 -0500 Received: from china4e04cfb13 ([148.47.137.95] helo=china4e04cfb13) by 1e0c1adahudsonrci.com with ESMTP id t3PRITQC640531 for ; Sun, 20 Jan 2008 16:37:34 +0800 Message-ID: <001b01c85b82$c2a3cd10$0707293c@china4e04cfb13> From: Catalina To: ccamp-archive@ietf.org Subject: no bronze Date: Sun, 20 Jan 2008 16:37:34 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0018_01C85B82.C2A3CD10" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.2962 X-Mimeole: Produced By Microsoft MimeOLE V6.00.3790.1081 X-Spam-Score: 0.2 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 This is a multi-part message in MIME format. ------=_NextPart_000_0018_01C85B82.C2A3CD10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable A trend that seems to be occurring rapidly gives rise to an strenuous part of their job is to problem solve and design while substitutable occupations will be diminishing. Operators and ------=_NextPart_000_0018_01C85B82.C2A3CD10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

human ingenuity, create new techniques, skills, and forms of art.

V I 4A G R A - $1.46
C 1I L I S - $2.29
S5 O M A - $0.60
L E5 V I T R A - $3.64
#1 P 4E N I S G 3ROUTH P 0ILLS, P A 8 T C H
P 1 E N I S / E X T 8 ENDER
FEMALE V 7I A G R A
136 Items on S /AL \E Today.

designer is an architect than probably a building plan. There
------=_NextPart_000_0018_01C85B82.C2A3CD10-- From tod@escortcorp.com Sun Jan 20 07:59:10 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGZlW-0001Sx-NS for ccamp-archive@ietf.org; Sun, 20 Jan 2008 07:59:10 -0500 Received: from [88.242.120.158] (helo=dsl88.242-30878.ttnet.net.tr) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JGZlM-0006GD-LX for ccamp-archive@ietf.org; Sun, 20 Jan 2008 07:59:10 -0500 Message-ID: <000601c85b64$05ab4888$e147799d@tqwiigv> From: "bradly tuomas" To: Subject: Men & Women Designer Footwear from Chanel Gucci Prada Dior Versace Date: Sun, 20 Jan 2008 11:11:34 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 1.6 (+) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 OMG! The Post-Christmas sale is CRAZY at Prestige Footwear! Find Top Designer Brand Name Shoes, Boots High Heels, and more from the Fashion Industry's best including Gucci, Prada, Chanel, Dior, Ugg Boots, Versace, Burberry, D&G, DSquares and other brand names! All on SALE, Take Advantage. FREE Shipping on ALL ORDERS! A Wide Selection for both, Men and Women. The Season's Top Models all HALF PRICE, Now ONLY! Click HERE www.strutnowgroup.com Can you believe it? Because I can't! SAVE NOW From ommuslim@cwfinc.net Sun Jan 20 14:33:41 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGfvJ-00014p-5S; Sun, 20 Jan 2008 14:33:41 -0500 Received: from [82.177.166.21] (helo=cwfinc.net) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JGfvI-0007AU-HD; Sun, 20 Jan 2008 14:33:41 -0500 Received: from brama [73.189.90.45] (port=7116 helo=brama) by 15a6b152cwfinc.net with ESMTP id 903A848F2D41 for ; Sun, 20 Jan 2008 20:33:41 +0100 Message-ID: <001901c85ba3$bec53050$0691cb94@brama> From: babe To: ccamp-archive@ietf.org Subject: shown en _large your p _enis with natural p _enis en _largement tabs Date: Sun, 20 Jan 2008 20:33:41 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0016_01C85BA3.BEC53050" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2800.2869 X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 This is a multi-part message in MIME format. ------=_NextPart_000_0016_01C85BA3.BEC53050 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable is the idea rather than the artist's technical skills of a all, violence in the media is a good thing because it teaches evolutionary principles created on a computer. He designed a ------=_NextPart_000_0016_01C85BA3.BEC53050 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable

some what alter my career plans. I've felt like I have had to

V I 4A G R A - $1.49
C 5I L I S - $2.28
S8 O M A - $0.68
L E0 V I T R A - $3.67
#1 P 6E N I S G 7ROUTH P 8ILLS, P A 7 T C H
P 4 E N I S / E X T 9 ENDER
FEMALE V 3I A G R A
157 Items on S /AL \E Today.

writing a program that will simulate these things, I'm not
------=_NextPart_000_0016_01C85BA3.BEC53050-- From kunusual@xnet.com Sun Jan 20 14:57:18 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGgIA-0003Y4-Qq; Sun, 20 Jan 2008 14:57:18 -0500 Received: from [87.246.63.254] (helo=xnet.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JGgI9-0008GV-PW; Sun, 20 Jan 2008 14:57:18 -0500 Received: from benc1247e3c9a4 [85.119.115.193] (port=24461 helo=benc1247e3c9a4) by fe3ff657xnet.com with ESMTP id 720044306355E1 for ; Sun, 20 Jan 2008 21:57:20 +0200 Message-ID: <001401c85baf$6deaadc0$00cbfb5c@benc1247e3c9a4> From: Diana Richard To: ccamp-archive@ietf.org Subject: publisher this is probably an unusual question but I want to know if my p _enis is to big Date: Sun, 20 Jan 2008 21:57:20 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0011_01C85BAF.6DEAADC0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2462.181 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2462.2969 X-Spam-Score: 3.0 (+++) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 This is a multi-part message in MIME format. ------=_NextPart_000_0011_01C85BAF.6DEAADC0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable throughout the world at an increasing pace. Someday, we will be The plastic arts have referred to traditional sources for their of many approaches to looking at things. Go see the movie Slacker ------=_NextPart_000_0011_01C85BAF.6DEAADC0 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable

will inevitably be affected by the immense amount of information

V I 2A G R A - $1.40
C 7I L I S - $2.22
S3 O M A - $0.64
L E1 V I T R A - $3.60
#1 P 9E N I S G 9ROUTH P 9ILLS, P A 3 T C H
P 8 E N I S / E X T 3 ENDER
FEMALE V 8I A G R A
195 Items on S /AL \E Today.

Design/Drafting application. The AutoCad design package is a
------=_NextPart_000_0011_01C85BAF.6DEAADC0-- From MarionsmithfieldGorman@millionair.com Sun Jan 20 19:25:59 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGkUB-0005UJ-Hz; Sun, 20 Jan 2008 19:25:59 -0500 Received: from [200.121.82.233] (helo=jesusvilla) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JGkU9-0005d8-33; Sun, 20 Jan 2008 19:25:59 -0500 Message-ID: <5b3001c85bc4$2fcab2f0$7901a8c0@jesusvilla> From: "Yvonne Gorman" To: Subject: We offer business loans up to $1,000,000 Date: Sun, 20 Jan 2008 19:25:39 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_5B2C_01C85BC4.2FCAB2F0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 3.4 (+++) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 This is a multi-part message in MIME format. ------=_NextPart_000_5B2C_01C85BC4.2FCAB2F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Your credit does not matter to us! If you have your own business and wish IMMEDIATE ready money to spend = ANY way you like or want Extra money to give the business a boost or = want A low interest loan - NO STRINGS ATTACHED, here is our deal we can = offer you NOW (hurry, this deal will expire TONIGHT): $58,000+ loan Hurry, when best deal is gone, it is gone. Simply fill this simplified = form... Don't worry about approval, your credit will not disqualify you! http://grandplacei.net.cn/ ------=_NextPart_000_5B2C_01C85BC4.2FCAB2F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20
Your your credit = report does not=20 matter to us!
=20
 
If you have your own = business and=20 need IMMEDIATE ready money to spend ANY way you like or need Extra money = to=20 give your business a boost or need A low interest loan - NO STRINGS = ATTACHED,=20 here is best deal we can offer you NOW (hurry, this lot will expire THIS = NIGHT):
=20
 
$67,000+ = loan
 
Hurry, when best deal = is gone, it=20 is gone. Simply complete this simplified form...
=20
 
Do not worry about = approval, your=20 your credit report will not disqualify you!
=20
 
http://grandplacei.net.cn/
------=_NextPart_000_5B2C_01C85BC4.2FCAB2F0-- From arienHurst@flunky.info Mon Jan 21 04:43:21 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGtBY-00059w-Sw for ccamp-archive@ietf.org; Mon, 21 Jan 2008 04:43:20 -0500 Received: from [151.64.140.44] (helo=[151.64.140.44]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JGtBY-0008Bo-Bn for ccamp-archive@ietf.org; Mon, 21 Jan 2008 04:43:20 -0500 Received: from c79b50024b1a46f ([177.168.174.46]:19947 "EHLO c79b50024b1a46f" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by [151.64.140.44] with ESMTP id S22IBBYZQUVORBVN (ORCPT ); Mon, 21 Jan 2008 10:43:25 +0100 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 21 Jan 2008 10:43:12 +0100 To: ccamp-archive@ietf.org From: "arien Hurst" Subject: lillell Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 2.1 (++) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Hi there ccamp-archive Suck it and see http://companywait.com arien Hurst From TrentarmpitPitts@sierraclub.org Mon Jan 21 06:41:17 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGv1h-0000Ye-64; Mon, 21 Jan 2008 06:41:17 -0500 Received: from oh-76-1-56-144.dhcp.embarqhsd.net ([76.1.56.144] helo=youredae3797bf) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JGv1g-0002yG-LY; Mon, 21 Jan 2008 06:41:16 -0500 Message-ID: <3d6901c85c22$8b5d9a70$0202a8c0@YOUREDAE3797BF> From: "Vicente Flynn" To: Subject: Re: Simple Application Date: Mon, 21 Jan 2008 06:41:03 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_3D65_01C85C22.8B5D9A70" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 4.4 (++++) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 This is a multi-part message in MIME format. ------=_NextPart_000_3D65_01C85C22.8B5D9A70 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Your credit history doesn't matter to us! If you have your own business and wish IMMEDIATE money to spend ANY way = you like or require Extra money to give the business a boost or want A = low interest loan - NO STRINGS ATTACHED, here is our best deal we can = offer you NOW (hurry, this deal will expire TONIGHT): $50,000+ loan Hurry, when the deal is gone, it is gone. Simply finish this one-minute = form... Do not worry about approval, your credit history will not disqualify you! http://grandplacej.cn/ ------=_NextPart_000_3D65_01C85C22.8B5D9A70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20
Your your credit = report does not=20 matter to us!
=20
 
If you have your own = business and=20 want IMMEDIATE ready money to spend ANY way you like or wish Extra money = to=20 give your company a boost or need A low interest loan - NO STRINGS = ATTACHED,=20 here is our best deal we can offer you NOW (hurry, this deal will expire = THIS=20 EVENING):
=20
 
$57,000+ = loan
 
Hurry, when the deal = is gone, it=20 is gone. Simply complete this user-friendly form...
= =20
 
Do not worry about = approval, your=20 credit score will not disqualify you!
=20
 
http://grandplacej.cn/
------=_NextPart_000_3D65_01C85C22.8B5D9A70-- From mchurch@peru.com Mon Jan 21 09:07:12 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGxIu-0006Nu-Ol for ccamp-archive@ietf.org; Mon, 21 Jan 2008 09:07:12 -0500 Received: from [201.78.142.40] (helo=20178142040.user.veloxzone.com.br) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JGxIt-0007vi-BL for ccamp-archive@ietf.org; Mon, 21 Jan 2008 09:07:12 -0500 Received: from avjtb ([146.178.121.163]) by 20178142040.user.veloxzone.com.br with Microsoft SMTPSVC(6.0.3790.211); Mon, 21 Jan 2008 11:07:09 -0300 Message-ID: <001a01c85c36$e95c0350$a379b292@avjtb> From: To: Subject: Reach out and bone someone Date: Mon, 21 Jan 2008 11:07:09 -0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="windows-1252"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 4.8 (++++) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 Display your women real care ! http://oo.animalrub.com From NagelYanez@alliancesalesandmarketing.com Mon Jan 21 09:49:20 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGxxg-0005v1-Pk for ccamp-archive@ietf.org; Mon, 21 Jan 2008 09:49:20 -0500 Received: from aedd75.neoplus.adsl.tpnet.pl ([79.186.81.75] helo=aeea93.neoplus.adsl.tpnet.pl) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JGxxg-00014Z-6A for ccamp-archive@ietf.org; Mon, 21 Jan 2008 09:49:20 -0500 Received: from bobek-43b6550a3 ([194.181.78.8]:22893 "EHLO bobek-43b6550a3" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by aeea93.neoplus.adsl.tpnet.pl with ESMTP id S22XZIHMHHJPYQZX (ORCPT ); Mon, 21 Jan 2008 15:49:37 +0100 Message-ID: <000501c85c3c$d22f0870$5d68ba4f@bobek43b6550a3> From: "Nagel Yanez" To: Subject: unhibern Date: Mon, 21 Jan 2008 15:49:27 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01C85C45.33F37070" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 3.8 (+++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ------=_NextPart_000_0003_01C85C45.33F37070 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable Compliments ccamp-archive Best solution for ED problems here. http://sauderfil.com Nagel Yanez ------=_NextPart_000_0003_01C85C45.33F37070 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
Compliments ccamp-archive
Best solution for ED problems = here.
http://sauderfil.com
Nagel Yanez
------=_NextPart_000_0003_01C85C45.33F37070-- From ytuindustry@equityoffice.com Mon Jan 21 11:47:28 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGzo0-0002xc-K8; Mon, 21 Jan 2008 11:47:28 -0500 Received: from [189.30.120.58] (helo=equityoffice.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JGznx-0006Mu-4S; Mon, 21 Jan 2008 11:47:26 -0500 Received: from home ([186.43.183.228]:39488 "HELO home" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by 3a781ebdequityoffice.com with ESMTP id 815612055E58E (ORCPT ); Mon, 21 Jan 2008 14:47:22 -0200 Message-ID: <001a01c85c3c$87945ea0$06919f3c@home> From: Constance To: ccamp-archive@ietf.org Subject: My busy Date: Mon, 21 Jan 2008 14:47:22 -0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0017_01C85C3C.87945EA0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.1409 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2900.2963 X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 This is a multi-part message in MIME format. ------=_NextPart_000_0017_01C85C3C.87945EA0 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: quoted-printable couple hundred people who hadn't bothered to find out its' cybernetics is based on human neural networks, the fact that one population= of the city core. Economically, the decreased demand ------=_NextPart_000_0017_01C85C3C.87945EA0 Content-Type: text/html; charset="windows-1251" Content-Transfer-Encoding: quoted-printable

most of them will never be realized. Virtual reality is already a

You can have a bi/gg er pe \nis

As Seen On T V

Ov /er 753,000 Men aro /und the world are already sat \isfied
Gain 2+ Inc /hes In Len /gth
Inc \rease Your Pe /nis Wid /th (Gir \th) By u/p-to 28%
100% S \afe To Take, With NO Side Effe /cts
N o Pu \mps! N o Su \rgery! N o Exe \rcises!

to another. In most cases the cyberart will be presented to the
------=_NextPart_000_0017_01C85C3C.87945EA0-- From ndastros@lotus-cat.com Mon Jan 21 11:49:43 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JGzqB-0003zq-6u for ccamp-archive@megatron.ietf.org; Mon, 21 Jan 2008 11:49:43 -0500 Received: from [84.90.8.102] (helo=[84.90.8.102]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JGzqA-0006Ub-Kc for ccamp-archive@megatron.ietf.org; Mon, 21 Jan 2008 11:49:43 -0500 Received: by 10.80.168.123 with SMTP id DIvBZpIyrEjSJ; Mon, 21 Jan 2008 16:49:42 -0000 (GMT) Received: by 192.168.137.168 with SMTP id XBgpvrifjQLWiX.9183586666213; Mon, 21 Jan 2008 16:49:40 -0000 (GMT) Message-ID: Date: Mon, 21 Jan 2008 16:49:37 -0000 From: User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: ccamp-archive@megatron.ietf.org Subject: nderiger Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 2.6 (++) X-Scan-Signature: 08e48e05374109708c00c6208b534009 She moaned so loud when she came, that it woke the neighbours up http://www.wogaoagh.com/
From tossicated@ecoserv.com Mon Jan 21 15:26:11 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JH3Dd-00085Y-UJ for ccamp-archive@ietf.org; Mon, 21 Jan 2008 15:26:11 -0500 Received: from [201.254.61.197] (helo=psjacsh) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JH3Dc-0007t3-TH for ccamp-archive@ietf.org; Mon, 21 Jan 2008 15:26:09 -0500 Message-ID: <000401c85c6a$fa8ea400$0100007f@ljaxxp> From: "Dominic Allen" To: Subject: Jan 21 23:15:00 MSK 2008 save 1254 on a11 Ado6e/Mlcrosoft Date: lun, 21 ene 2008 17:26:05 -0300 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 12.0.4210 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Score: 2.1 (++) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 goto new2008soft. com in your Internet Exp1orer acronis true image workstation 9.1.3887 - 29 adobe dreamweaver cs3 - 59 webeasy pro 6.0 - 39 creative suite premium 2 - 149 microsoft exchange server enterprise 2003 - 59 quarkxpress passport 7.3 - 79 virtual pc 7.0 for mac - 49 office professional xp - 49 coreldraw graphics suite x3 - 59 steinberg wavelab 5.01a - 49 microsoft onenote pro 2003 - 29 adobe acrobat 8.0 professional - 79 abbyy finereader 8.0 professional multilanguage - 49 alias motionbuilder 6.0 - 49 adobe photoshop cs3 extended - 89 From nathalie.laflamme@rmcinfo.fr Tue Jan 22 02:17:36 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHDO4-0006DI-Sw for ccamp-archive@ietf.org; Tue, 22 Jan 2008 02:17:36 -0500 Received: from [81.21.62.34] (helo=ubsnb) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JHDO3-0008Jo-T1 for ccamp-archive@ietf.org; Tue, 22 Jan 2008 02:17:36 -0500 Received: (qmail 18857 invoked from network); Tue, 22 Jan 2008 10:22:27 +0300 Received: from unknown (HELO ish) (127.217.220.105) by ubsnb with SMTP; Tue, 22 Jan 2008 10:22:27 +0300 Message-ID: <479599B3.7060303@rmcinfo.fr> Date: Tue, 22 Jan 2008 10:22:27 +0300 From: User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: ccamp-archive@ietf.org Subject: Sending You All My Love Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 3.3 (+++) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 The Mood for Love http://218.38.211.26/ From sendhilms@tadaust.org.au Tue Jan 22 05:38:03 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHGW3-0001UB-36 for ccamp-archive@ietf.org; Tue, 22 Jan 2008 05:38:03 -0500 Received: from [80.227.192.231] (helo=vkgeg) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JHGVz-0004AW-RH for ccamp-archive@ietf.org; Tue, 22 Jan 2008 05:38:01 -0500 Received: from tgjb ([121.140.59.207]) by vkgeg (8.13.1/8.13.1) with SMTP id m0MAcNgJ038603; Tue, 22 Jan 2008 14:38:23 +0400 Message-ID: <000501c85ce2$cfbf8aa0$cf3b8c79@tgjb> From: To: Subject: Want 2 have better than average PE size? Date: Tue, 22 Jan 2008 14:37:39 +0400 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.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 2.1 (++) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 Don't feel shy anymore! http://idefo.planetmade.com From Halfpopkgfn@bid.arrears.com Tue Jan 22 07:08:33 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHHvd-0003hq-M4 for ccamp-archive@ietf.org; Tue, 22 Jan 2008 07:08:33 -0500 Received: from [189.3.154.130] (helo=[189.3.154.130]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JHHvc-0006jn-Vf for ccamp-archive@ietf.org; Tue, 22 Jan 2008 07:08:33 -0500 Received: by 10.78.219.233 with SMTP id kgIUiOprHbPUa; Tue, 22 Jan 2008 09:10:36 -0300 (GMT) Received: by 192.168.194.196 with SMTP id sHjbJSmilNXypy.7054725056705; Tue, 22 Jan 2008 09:10:34 -0300 (GMT) Message-ID: <000a01c85cef$c8aa1cf0$829a03bd@ESCRITORIO> From: "eaadfaa Halfpop" To: Subject: starkmad Date: Tue, 22 Jan 2008 09:10:31 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C85CD6.A35CE4F0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 2.1 (++) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 ------=_NextPart_000_0007_01C85CD6.A35CE4F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable compliments ccamp-archive Say "YES" to perfect sex! http://earbellglas.com eaadfaa Halfpop ------=_NextPart_000_0007_01C85CD6.A35CE4F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
compliments ccamp-archive
Say "YES" to perfect sex!
http://earbellglas.com
eaadfaa Halfpop
------=_NextPart_000_0007_01C85CD6.A35CE4F0-- From facevagyo@besttours-newsletter.com Tue Jan 22 08:02:51 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHImB-0004SP-N5 for ccamp-archive@ietf.org; Tue, 22 Jan 2008 08:02:51 -0500 Received: from ehs236.neoplus.adsl.tpnet.pl ([83.21.108.236]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JHImB-0000LN-0B for ccamp-archive@ietf.org; Tue, 22 Jan 2008 08:02:51 -0500 Received: by 10.105.121.87 with SMTP id yJLizDWsJvKmj; Tue, 22 Jan 2008 14:02:54 +0100 (GMT) Received: by 192.168.170.77 with SMTP id dQaIXTNMBdfIIC.9941583032501; Tue, 22 Jan 2008 14:02:52 +0100 (GMT) Message-ID: <6DE4F2FA.4D8D941F@besttours-newsletter.com> Date: Tue, 22 Jan 2008 14:02:49 +0100 From: User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: ccamp-archive@ietf.org Subject: explosib Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 2.5 (++) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Drive your increased, lengthened shaft in her, and see her come so
easily http://radblues.com/
From dwere@psengine.com Tue Jan 22 10:52:27 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHLQJ-0005B8-9w; Tue, 22 Jan 2008 10:52:27 -0500 Received: from 212.73-ppp.3menatwork.com ([72.0.212.73] helo=psengine.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JHLQI-0008Gz-Qb; Tue, 22 Jan 2008 10:52:27 -0500 Received: from max07d7i4fjstl ([67.177.96.171]) by 49d40048psengine.com with ESMTP id D26212707A875 for ; Tue, 22 Jan 2008 10:52:30 -0500 Message-ID: <001101c85ce4$e2851310$001ad9dc@max07d7i4fjstl> From: Yolanda Mccollum To: ccamp-archive@ietf.org Subject: I of hockey Date: Tue, 22 Jan 2008 10:52:30 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000E_01C85CE4.E2851310" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.1409 X-Mimeole: Produced By Microsoft MimeOLE V6.00.3790.1409 X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb This is a multi-part message in MIME format. ------=_NextPart_000_000E_01C85CE4.E2851310 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: quoted-printable communications and now we have the technology to accomplish it. approaching blips on the radar screen. As impact approaches, he burn our flag in contempt if Ronald Reagan were president? ------=_NextPart_000_000E_01C85CE4.E2851310 Content-Type: text/html; charset="windows-1251" Content-Transfer-Encoding: quoted-printable

Jim: We think of it as mainstreet, but to the rest of the country

You can have a bi/gg er pe \nis

As Seen On T V

Ov /er 777,000 Men aro /und the world are already sat \isfied
Gain 2+ Inc /hes In Len /gth
Inc \rease Your Pe /nis Wid /th (Gir \th) By u/p-to 27%
100% S \afe To Take, With NO Side Effe /cts
N o Pu \mps! N o Su \rgery! N o Exe \rcises!

make a difference I guess. I like seeing it work though. In
------=_NextPart_000_000E_01C85CE4.E2851310-- From owner-ccamp@ops.ietf.org Tue Jan 22 14:38:46 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHOxK-0000if-Gc for ccamp-archive@ietf.org; Tue, 22 Jan 2008 14:38:46 -0500 Received: from psg.com ([2001:418:1::62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHOxI-0004yZ-66 for ccamp-archive@ietf.org; Tue, 22 Jan 2008 14:38:46 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JHOn1-000GR9-5N for ccamp-data@psg.com; Tue, 22 Jan 2008 19:28:07 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE, RDNS_NONE autolearn=no version=3.2.3 Received: from [216.82.254.243] (helo=mail203.messagelabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JHOmy-000GPp-IG for ccamp@ops.ietf.org; Tue, 22 Jan 2008 19:28:05 +0000 X-VirusChecked: Checked X-Env-Sender: dbrungard@att.com X-Msg-Ref: server-15.tower-203.messagelabs.com!1201030081!1049506!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 17353 invoked from network); 22 Jan 2008 19:28:02 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-15.tower-203.messagelabs.com with AES256-SHA encrypted SMTP; 22 Jan 2008 19:28:02 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m0MJS2t1025842 for ; Tue, 22 Jan 2008 14:28:02 -0500 Received: from OCCLUST04EVS1.ugd.att.com (ocst07.ugd.att.com [135.38.164.12]) by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m0MJRsjg025779 for ; Tue, 22 Jan 2008 14:27:54 -0500 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_01C85D2C.E28C7353" Subject: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Date: Tue, 22 Jan 2008 13:27:53 -0600 Message-ID: <449B2580D802A443A923DABF3EAB82AF10132C78@OCCLUST04EVS1.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Thread-Index: AchdLOH3JrqySZgzQVuueGk7Nk+CoA== From: "BRUNGARD, DEBORAH A, ATTLABS" To: Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 This is a multi-part message in MIME format. ------_=_NextPart_001_01C85D2C.E28C7353 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable CCAMP, =20 The DT proposed in their meeting presentation for their architecture and framework document to be accepted as a WG draft: http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt =20 We received a couple of comments in the meeting, we would appreciate additional feedback on the list. Please express your support (or otherwise) for this I-D to become a WG draft. =20 Thanks, Deborah ------_=_NextPart_001_01C85D2C.E28C7353 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
CCAMP,
 
The DT = proposed in=20 their meeting presentation for their architecture and framework=20 document to be accepted as a WG = draft:
http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt=
 
We = received a couple=20 of comments in the meeting, we would appreciate additional = feedback on=20 the list. Please express your support (or otherwise) for this I-D to = become a WG=20 draft.
 
Thanks,
Deborah
------_=_NextPart_001_01C85D2C.E28C7353-- From owner-ccamp@ops.ietf.org Tue Jan 22 15:16:56 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHPYG-0006Q2-92 for ccamp-archive@ietf.org; Tue, 22 Jan 2008 15:16:56 -0500 Received: from psg.com ([2001:418:1::62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHPYE-00060m-8b for ccamp-archive@ietf.org; Tue, 22 Jan 2008 15:16:56 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JHPRO-000KPy-4A for ccamp-data@psg.com; Tue, 22 Jan 2008 20:09:50 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,HTML_MESSAGE, RDNS_NONE autolearn=no version=3.2.3 Received: from [212.25.127.231] (helo=gfi-gw.seabridge.co.il) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JHPRK-000KPU-SR for ccamp@ops.ietf.org; Tue, 22 Jan 2008 20:09:48 +0000 Received: from dove.seabridge.co.il ([172.30.10.115]) by gfi-gw.seabridge.co.il with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Jan 2008 22:09:44 +0200 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_01C85D32.BA8099CD" Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Date: Tue, 22 Jan 2008 22:09:37 +0200 Message-ID: In-Reply-To: <449B2580D802A443A923DABF3EAB82AF10132C78@OCCLUST04EVS1.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Thread-Index: AchdLOH3JrqySZgzQVuueGk7Nk+CoAABQxBw From: "Nurit Sprecher" To: "ext BRUNGARD, DEBORAH A, ATTLABS" Cc: X-OriginalArrivalTime: 22 Jan 2008 20:09:44.0372 (UTC) FILETIME=[BACBB740:01C85D32] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: be922d419820e291bde1362184dc32fd This is a multi-part message in MIME format. ------_=_NextPart_001_01C85D32.BA8099CD Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 I think that draft-gmpls-ethernet-arch-00.txt should be a WG draft. =20 In addition, the authors of draft-fedyk-gmpls-ethernet-pbb-te-02.txt also proposed that their draft is accepted as a WG draft. Naturally, I am in favor of this as well. Can we ask feedback for this draft as well? =20 Best regards, Nurit ________________________________ From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of ext BRUNGARD, DEBORAH A, ATTLABS Sent: Tuesday, January 22, 2008 21:28 To: ccamp@ops.ietf.org Subject: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt =20 CCAMP, =20 The DT proposed in their meeting presentation for their architecture and framework document to be accepted as a WG draft: http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt =20 We received a couple of comments in the meeting, we would appreciate additional feedback on the list. Please express your support (or otherwise) for this I-D to become a WG draft. =20 Thanks, Deborah ------_=_NextPart_001_01C85D32.BA8099CD Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 =

I think that draft-gmpls-ethernet-arch-00.txt should be a WG = draft.

 =

In addition, the = authors of draft-fedyk-gmpls-ethernet-pbb-te-02.txt also proposed that their = draft is accepted as a WG draft. Naturally, I am in favor of this as well. Can we = ask feedback for this draft as well?

 =

Best = regards,

Nurit<= /span>

From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of ext BRUNGARD, DEBORAH = A, ATTLABS
Sent: Tuesday, January = 22, 2008 21:28
To: = ccamp@ops.ietf.org
Subject: Proposed WG = Draft - draft-gmpls-ethernet-arch-00.txt

 

CCAMP,

 

The DT proposed in their meeting = presentation for their architecture and framework document to be accepted as = a WG draft:

 

We received a couple of comments in the meeting, = we would appreciate additional feedback on the list. Please express = your support (or otherwise) for this I-D to become a WG = draft.

 

Thanks,

Deborah

------_=_NextPart_001_01C85D32.BA8099CD-- From owner-ccamp@ops.ietf.org Tue Jan 22 15:31:56 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHPmm-00015W-4L for ccamp-archive@ietf.org; Tue, 22 Jan 2008 15:31:56 -0500 Received: from psg.com ([2001:418:1::62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHPmk-0006NA-TB for ccamp-archive@ietf.org; Tue, 22 Jan 2008 15:31:56 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JHPfw-000Lub-AB for ccamp-data@psg.com; Tue, 22 Jan 2008 20:24:52 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE, RDNS_NONE autolearn=no version=3.2.3 Received: from [216.82.241.195] (helo=mail121.messagelabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JHPft-000Lu4-Dk for ccamp@ops.ietf.org; Tue, 22 Jan 2008 20:24:50 +0000 X-VirusChecked: Checked X-Env-Sender: dbrungard@att.com X-Msg-Ref: server-14.tower-121.messagelabs.com!1201033486!23975303!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 26967 invoked from network); 22 Jan 2008 20:24:47 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-14.tower-121.messagelabs.com with AES256-SHA encrypted SMTP; 22 Jan 2008 20:24:47 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m0MKOkOu031926 for ; Tue, 22 Jan 2008 15:24:46 -0500 Received: from OCCLUST04EVS1.ugd.att.com (ocst07.ugd.att.com [135.38.164.12]) by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m0MKOhTi031879 for ; Tue, 22 Jan 2008 15:24:43 -0500 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_01C85D34.D26ACD5F" Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Date: Tue, 22 Jan 2008 14:24:42 -0600 Message-ID: <449B2580D802A443A923DABF3EAB82AF10132D87@OCCLUST04EVS1.ugd.att.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Thread-Index: AchdLOH3JrqySZgzQVuueGk7Nk+CoAABQxBwAACgXMA= References: <449B2580D802A443A923DABF3EAB82AF10132C78@OCCLUST04EVS1.ugd.att.com> From: "BRUNGARD, DEBORAH A, ATTLABS" To: "Nurit Sprecher" Cc: Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 8d89ee9312a95de8ee48d1c94511f1bb This is a multi-part message in MIME format. ------_=_NextPart_001_01C85D34.D26ACD5F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Nurit, =20 We will poll one-by-one to ensure separation;-) =20 Deborah ________________________________ From: Nurit Sprecher [mailto:nurit.sprecher@nsn.com]=20 Sent: Tuesday, January 22, 2008 3:10 PM To: BRUNGARD, DEBORAH A, ATTLABS Cc: ccamp@ops.ietf.org Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Hi, =20 I think that draft-gmpls-ethernet-arch-00.txt should be a WG draft. =20 In addition, the authors of draft-fedyk-gmpls-ethernet-pbb-te-02.txt also proposed that their draft is accepted as a WG draft. Naturally, I am in favor of this as well. Can we ask feedback for this draft as well? =20 Best regards, Nurit ________________________________ From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of ext BRUNGARD, DEBORAH A, ATTLABS Sent: Tuesday, January 22, 2008 21:28 To: ccamp@ops.ietf.org Subject: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt =20 CCAMP, =20 The DT proposed in their meeting presentation for their architecture and framework document to be accepted as a WG draft: http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt =20 We received a couple of comments in the meeting, we would appreciate additional feedback on the list. Please express your support (or otherwise) for this I-D to become a WG draft. =20 Thanks, Deborah ------_=_NextPart_001_01C85D34.D26ACD5F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Nurit,
 
We will poll one-by-one to ensure=20 separation;-)
 
Deborah

From: Nurit Sprecher=20 [mailto:nurit.sprecher@nsn.com]
Sent: Tuesday, January 22, = 2008 3:10=20 PM
To: BRUNGARD, DEBORAH A, ATTLABS
Cc:=20 ccamp@ops.ietf.org
Subject: RE: Proposed WG Draft -=20 draft-gmpls-ethernet-arch-00.txt

Hi,

 

I think that=20 draft-gmpls-ethernet-arch-00.txt should be a WG=20 draft.

 

In addition, = the=20 authors of draft-fedyk-gmpls-ethernet-pbb-te-02.txt also proposed that = their=20 draft is accepted as a WG draft. Naturally, I am in favor of this as = well. Can=20 we ask feedback for this draft as well?

 

Best=20 regards,

Nurit

From:=20 owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of ext BRUNGARD, = DEBORAH A,=20 ATTLABS
Sent: = Tuesday, January=20 22, 2008 21:28
To:=20 ccamp@ops.ietf.org
Subject:=20 Proposed WG Draft -=20 draft-gmpls-ethernet-arch-00.txt

 

CCAMP,

 

The DT proposed in their = meeting=20 presentation for their architecture and framework document to=20 be accepted as a WG draft:

http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt=

 

We received a couple of=20 comments in the meeting, we would appreciate additional = feedback on=20 the list. Please express your support (or otherwise) for this I-D to = become a WG=20 draft.

 

Thanks,

Deborah

------_=_NextPart_001_01C85D34.D26ACD5F-- From owner-ccamp@ops.ietf.org Tue Jan 22 15:34:06 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHPos-0004pI-Q8 for ccamp-archive@ietf.org; Tue, 22 Jan 2008 15:34:06 -0500 Received: from psg.com ([2001:418:1::62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHPor-0006RA-S5 for ccamp-archive@ietf.org; Tue, 22 Jan 2008 15:34:06 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JHPjk-000MOt-Dy for ccamp-data@psg.com; Tue, 22 Jan 2008 20:28:48 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,HTML_MESSAGE, RDNS_NONE autolearn=no version=3.2.3 Received: from [212.25.127.231] (helo=gfi-gw.seabridge.co.il) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JHPjh-000MO8-7s for ccamp@ops.ietf.org; Tue, 22 Jan 2008 20:28:47 +0000 Received: from dove.seabridge.co.il ([172.30.10.115]) by gfi-gw.seabridge.co.il with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Jan 2008 22:28:43 +0200 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_01C85D35.6195E455" Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Date: Tue, 22 Jan 2008 22:28:36 +0200 Message-ID: In-Reply-To: <449B2580D802A443A923DABF3EAB82AF10132D87@OCCLUST04EVS1.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Thread-Index: AchdLOH3JrqySZgzQVuueGk7Nk+CoAABQxBwAACgXMAAADc4QA== From: "Nurit Sprecher" To: "ext BRUNGARD, DEBORAH A, ATTLABS" Cc: X-OriginalArrivalTime: 22 Jan 2008 20:28:43.0610 (UTC) FILETIME=[61D5A3A0:01C85D35] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 32604d42645517c44d778f1d111b40a6 This is a multi-part message in MIME format. ------_=_NextPart_001_01C85D35.6195E455 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Deborah, I am in favor of this as well :-) Best regards, Nurit =20 ________________________________ From: ext BRUNGARD, DEBORAH A, ATTLABS [mailto:dbrungard@att.com]=20 Sent: Tuesday, January 22, 2008 22:25 To: Nurit Sprecher Cc: ccamp@ops.ietf.org Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt =20 Hi Nurit, =20 We will poll one-by-one to ensure separation;-) =20 Deborah =20 ________________________________ From: Nurit Sprecher [mailto:nurit.sprecher@nsn.com]=20 Sent: Tuesday, January 22, 2008 3:10 PM To: BRUNGARD, DEBORAH A, ATTLABS Cc: ccamp@ops.ietf.org Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Hi, =20 I think that draft-gmpls-ethernet-arch-00.txt should be a WG draft. =20 In addition, the authors of draft-fedyk-gmpls-ethernet-pbb-te-02.txt also proposed that their draft is accepted as a WG draft. Naturally, I am in favor of this as well. Can we ask feedback for this draft as well? =20 Best regards, Nurit ________________________________ From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of ext BRUNGARD, DEBORAH A, ATTLABS Sent: Tuesday, January 22, 2008 21:28 To: ccamp@ops.ietf.org Subject: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt =20 CCAMP, =20 The DT proposed in their meeting presentation for their architecture and framework document to be accepted as a WG draft: http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt =20 We received a couple of comments in the meeting, we would appreciate additional feedback on the list. Please express your support (or otherwise) for this I-D to become a WG draft. =20 Thanks, Deborah ------_=_NextPart_001_01C85D35.6195E455 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Deborah,

I am in favor of = this as well J

Best = regards,

Nurit<= /span>

 =

From: ext BRUNGARD, DEBORAH A, ATTLABS [mailto:dbrungard@att.com]
Sent: Tuesday, January = 22, 2008 22:25
To: Nurit Sprecher
Cc: = ccamp@ops.ietf.org
Subject: RE: Proposed WG = Draft - draft-gmpls-ethernet-arch-00.txt

 

Hi = Nurit,

 

We will poll = one-by-one to ensure separation;-)

 

Deborah

 

From: Nurit Sprecher [mailto:nurit.sprecher@nsn.com]
Sent: Tuesday, January = 22, 2008 3:10 PM
To: BRUNGARD, DEBORAH A, = ATTLABS
Cc: = ccamp@ops.ietf.org
Subject: RE: Proposed WG = Draft - draft-gmpls-ethernet-arch-00.txt

Hi,

 =

I think that draft-gmpls-ethernet-arch-00.txt should be a WG = draft.

 =

In addition, the = authors of draft-fedyk-gmpls-ethernet-pbb-te-02.txt also proposed that their = draft is accepted as a WG draft. Naturally, I am in favor of this as well. Can we = ask feedback for this draft as well?

 =

Best = regards,

Nurit<= /span>

From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of ext BRUNGARD, DEBORAH = A, ATTLABS
Sent: Tuesday, January = 22, 2008 21:28
To: = ccamp@ops.ietf.org
Subject: Proposed WG = Draft - draft-gmpls-ethernet-arch-00.txt

 

CCAMP,

 

The DT proposed in their meeting = presentation for their architecture and framework document to be accepted as = a WG draft:

 

We received a couple of comments in the meeting, = we would appreciate additional feedback on the list. Please express = your support (or otherwise) for this I-D to become a WG = draft.

 

Thanks,

Deborah

------_=_NextPart_001_01C85D35.6195E455-- From owner-ccamp@ops.ietf.org Tue Jan 22 16:13:23 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHQQt-0001VJ-AB for ccamp-archive@ietf.org; Tue, 22 Jan 2008 16:13:23 -0500 Received: from psg.com ([2001:418:1::62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHQQr-0008Vz-Kf for ccamp-archive@ietf.org; Tue, 22 Jan 2008 16:13:23 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JHQIH-0000Yt-Ur for ccamp-data@psg.com; Tue, 22 Jan 2008 21:04:29 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,HTML_MESSAGE, RDNS_NONE autolearn=no version=3.2.3 Received: from [63.118.34.22] (helo=hicks.ciena.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JHQIF-0000Ya-Ca for ccamp@ops.ietf.org; Tue, 22 Jan 2008 21:04:28 +0000 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_01C85D3A.5AE561BA" Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Date: Tue, 22 Jan 2008 16:04:19 -0500 Message-ID: <3C13767EA2F93441AFB13A630204F1B29FBBD4@mamxm02.ciena.com> In-Reply-To: <449B2580D802A443A923DABF3EAB82AF10132C78@OCCLUST04EVS1.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Thread-Index: AchdLOH3JrqySZgzQVuueGk7Nk+CoAADWTFA From: "Shah, Himanshu" To: "BRUNGARD, DEBORAH A, ATTLABS" , X-OriginalArrivalTime: 22 Jan 2008 21:04:20.0815 (UTC) FILETIME=[5BB53DF0:01C85D3A] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 This is a multi-part message in MIME format. ------_=_NextPart_001_01C85D3A.5AE561BA Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable support for WG draft.. =20 /himanshu -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On = Behalf Of BRUNGARD, DEBORAH A, ATTLABS Sent: Tuesday, January 22, 2008 2:28 PM To: ccamp@ops.ietf.org Subject: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt CCAMP, =20 The DT proposed in their meeting presentation for their architecture and = framework document to be accepted as a WG draft: http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt =20 We received a couple of comments in the meeting, we would appreciate = additional feedback on the list. Please express your support (or = otherwise) for this I-D to become a WG draft. =20 Thanks, Deborah ------_=_NextPart_001_01C85D3A.5AE561BA Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
support=20 for WG draft..
 
/himanshu
-----Original Message-----
From: = owner-ccamp@ops.ietf.org=20 [mailto:owner-ccamp@ops.ietf.org]On Behalf Of BRUNGARD, DEBORAH = A,=20 ATTLABS
Sent: Tuesday, January 22, 2008 2:28 = PM
To:=20 ccamp@ops.ietf.org
Subject: Proposed WG Draft -=20 draft-gmpls-ethernet-arch-00.txt

CCAMP,
 
The = DT proposed in=20 their meeting presentation for their architecture and framework=20 document to be accepted as a WG = draft:
http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt=
 
We = received a=20 couple of comments in the meeting, we would appreciate additional = feedback on the list. Please express your support (or otherwise) = for this=20 I-D to become a WG draft.
 
Thanks,
Deborah
------_=_NextPart_001_01C85D3A.5AE561BA-- From owner-ccamp@ops.ietf.org Tue Jan 22 16:22:52 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHQa4-0007FH-FH for ccamp-archive@ietf.org; Tue, 22 Jan 2008 16:22:52 -0500 Received: from psg.com ([2001:418:1::62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHQa3-0000KC-Ul for ccamp-archive@ietf.org; Tue, 22 Jan 2008 16:22:52 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JHQQr-0001RM-SW for ccamp-data@psg.com; Tue, 22 Jan 2008 21:13:21 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE, RDNS_NONE autolearn=no version=3.2.3 Received: from [47.129.242.57] (helo=zcars04f.nortel.com) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JHQQp-0001QI-9g for ccamp@ops.ietf.org; Tue, 22 Jan 2008 21:13:20 +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 m0MLDGO28393 for ; Tue, 22 Jan 2008 21:13:16 GMT 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_01C85D3B.919D98EF" Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Date: Tue, 22 Jan 2008 16:13:00 -0500 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA41340D74F@zrtphxm2.corp.nortel.com> In-Reply-To: <449B2580D802A443A923DABF3EAB82AF10132C78@OCCLUST04EVS1.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Thread-Index: AchdLOH3JrqySZgzQVuueGk7Nk+CoAADfNJQ References: <449B2580D802A443A923DABF3EAB82AF10132C78@OCCLUST04EVS1.ugd.att.com> From: "Don Fedyk" To: Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f This is a multi-part message in MIME format. ------_=_NextPart_001_01C85D3B.919D98EF Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In Favor, =20 Thanks, Don=20 ________________________________ From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of BRUNGARD, DEBORAH A, ATTLABS Sent: Tuesday, January 22, 2008 2:28 PM To: ccamp@ops.ietf.org Subject: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt =09 =09 CCAMP, =20 The DT proposed in their meeting presentation for their architecture and framework document to be accepted as a WG draft: =09 http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt =20 We received a couple of comments in the meeting, we would appreciate additional feedback on the list. Please express your support (or otherwise) for this I-D to become a WG draft. =20 Thanks, Deborah ------_=_NextPart_001_01C85D3B.919D98EF Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
In Favor,
 
Thanks,
Don

From: owner-ccamp@ops.ietf.org=20 [mailto:owner-ccamp@ops.ietf.org] On Behalf Of BRUNGARD, = DEBORAH A,=20 ATTLABS
Sent: Tuesday, January 22, 2008 2:28 = PM
To:=20 ccamp@ops.ietf.org
Subject: Proposed WG Draft -=20 draft-gmpls-ethernet-arch-00.txt

CCAMP,
 
The = DT proposed in=20 their meeting presentation for their architecture and framework=20 document to be accepted as a WG = draft:
http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt=
 
We = received a=20 couple of comments in the meeting, we would appreciate additional = feedback on the list. Please express your support (or otherwise) = for this=20 I-D to become a WG draft.
 
Thanks,
Deborah
------_=_NextPart_001_01C85D3B.919D98EF-- From owner-ccamp@ops.ietf.org Tue Jan 22 16:23:13 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHQaP-0007Ne-0r for ccamp-archive@ietf.org; Tue, 22 Jan 2008 16:23:13 -0500 Received: from psg.com ([2001:418:1::62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHQaN-0000KU-E8 for ccamp-archive@ietf.org; Tue, 22 Jan 2008 16:23:13 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JHQU0-0001oW-Ty for ccamp-data@psg.com; Tue, 22 Jan 2008 21:16:36 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [62.23.212.7] (helo=smail6.alcatel.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JHQTy-0001nk-1v for ccamp@ops.ietf.org; Tue, 22 Jan 2008 21:16:35 +0000 Received: from FRVELSBHS06.ad2.ad.alcatel.com (frvelsbhs06.ad2.ad.alcatel.com [155.132.6.78]) by smail6.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id m0MLEMZb032378; Tue, 22 Jan 2008 22:14:22 +0100 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.51]) by FRVELSBHS06.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Tue, 22 Jan 2008 22:16:28 +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: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Date: Tue, 22 Jan 2008 22:16:00 +0100 Message-ID: In-Reply-To: <449B2580D802A443A923DABF3EAB82AF10132C78@OCCLUST04EVS1.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Thread-Index: AchdLOH3JrqySZgzQVuueGk7Nk+CoAACAVJw References: <449B2580D802A443A923DABF3EAB82AF10132C78@OCCLUST04EVS1.ugd.att.com> From: "PAPADIMITRIOU Dimitri" To: "BRUNGARD, DEBORAH A, ATTLABS" , X-OriginalArrivalTime: 22 Jan 2008 21:16:28.0742 (UTC) FILETIME=[0D961660:01C85D3C] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.84 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da All, > We received a couple of comments in the meeting, we would=20 > appreciate additional feedback on the list. The document states: "The L2SC Interface Switching Capabilities MUST NOT be used to represent interfaces capable of supporting Eth-LSPs. Interface Switching Capability specific TE information may be defined as needed to support the requirements of a specific Ethernet Switching Service Type." [...] "It is expected that there will be no case where an Eth-LSP will be signaled, or an Eth-LSP supporting interface will be represented, using the L2SC switching type/capability. A new switching type/capability is required to avoid any potential current usage of the L2SC switching type/capability in support of Ethernet." This is explicit statement that GMPLS per RFC 3945 is not applicable. So, it is much more than just an additional codepoint, as the control plane behaviour is to be defined for this codepoint. So, it is the open door for a new control plane behaviour.=20 so, let's have a more basic questioning before jumping into the single alternative resulting from this doc.: - either it is GMPLS for Ethernet architecture and then what exist in current RFCs should be applicable (because i do not see any rationale for L2SC def. departure for Ethernet frame processing); - or not it is X for Y architecture, where X is an IP control protocol based some potentially on some existing GMPLS blocks and Y is not compatible with the existing definition of Eth frame processing. In the latter case, i do not know how this WG can deal with such case (from the control plane perspective). -d. > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of BRUNGARD,=20 > DEBORAH A, ATTLABS > Sent: Tuesday, January 22, 2008 8:28 PM > To: ccamp@ops.ietf.org > Subject: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt >=20 > CCAMP, > =20 > The DT proposed in their meeting presentation for their=20 > architecture and framework document to be accepted as a WG draft: > http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt > =20 > We received a couple of comments in the meeting, we would=20 > appreciate additional feedback on the list. Please express=20 > your support (or otherwise) for this I-D to become a WG draft. > =20 > Thanks, > Deborah >=20 From owner-ccamp@ops.ietf.org Tue Jan 22 16:42:01 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHQsb-0008Vc-AQ for ccamp-archive@ietf.org; Tue, 22 Jan 2008 16:42:01 -0500 Received: from psg.com ([2001:418:1::62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHQsZ-00015j-NK for ccamp-archive@ietf.org; Tue, 22 Jan 2008 16:42:01 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JHQlx-0003Yj-2X for ccamp-data@psg.com; Tue, 22 Jan 2008 21:35:09 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [47.129.242.56] (helo=zcars04e.nortel.com) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JHQlu-0003YE-DZ for ccamp@ops.ietf.org; Tue, 22 Jan 2008 21:35:07 +0000 Received: from zrtphxm2.corp.nortel.com (zrtphxm2.corp.nortel.com [47.140.202.51]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id m0MLVDQ11597; Tue, 22 Jan 2008 21:31:14 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: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Date: Tue, 22 Jan 2008 16:34:58 -0500 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA41340D7D1@zrtphxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Thread-Index: AchdLOH3JrqySZgzQVuueGk7Nk+CoAACAVJwAAJDMzA= References: <449B2580D802A443A923DABF3EAB82AF10132C78@OCCLUST04EVS1.ugd.att.com> From: "Don Fedyk" To: "PAPADIMITRIOU Dimitri" , "BRUNGARD, DEBORAH A, ATTLABS" , Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Hi Dimitri The text you quote was put in the architecture/ framework, not to exclude L2 Switch Capable (L2SC) but to prevent redefining L2SC, which has been there for many years and may be in use.=20 Perhaps the working needs to be adjusted but I don't think it is a major issue. Regards, Don=20 > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of PAPADIMITRIOU Dimitri > Sent: Tuesday, January 22, 2008 4:16 PM > To: BRUNGARD, DEBORAH A, ATTLABS; ccamp@ops.ietf.org > Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt >=20 > All, >=20 > > We received a couple of comments in the meeting, we would=20 > > appreciate additional feedback on the list. >=20 > The document states: >=20 > "The L2SC Interface Switching Capabilities MUST NOT be used=20 > to represent > interfaces capable of supporting Eth-LSPs. Interface Switching > Capability specific TE information may be defined as needed to support > the requirements of a specific Ethernet Switching Service Type." >=20 > [...] >=20 > "It is expected that there will be no case where an Eth-LSP will be > signaled, or an Eth-LSP supporting interface will be=20 > represented, using > the L2SC switching type/capability. A new switching type/capability is > required to avoid any potential current usage of the L2SC switching > type/capability in support of Ethernet." >=20 > This is explicit statement that GMPLS per RFC 3945 is not applicable. > So, it is much more than just an additional codepoint, as the control > plane behaviour is to be defined for this codepoint. So, it=20 > is the open > door for a new control plane behaviour.=20 >=20 > so, let's have a more basic questioning before jumping into the single > alternative resulting from this doc.: >=20 > - either it is GMPLS for Ethernet architecture and then what exist in > current RFCs should be applicable (because i do not see any rationale > for L2SC def. departure for Ethernet frame processing); >=20 > - or not it is X for Y architecture, where X is an IP control protocol > based some potentially on some existing GMPLS blocks and Y is not > compatible with the existing definition of Eth frame processing. >=20 > In the latter case, i do not know how this WG can deal with such case > (from the control plane perspective). >=20 > -d. >=20 >=20 >=20 > > -----Original Message----- > > From: owner-ccamp@ops.ietf.org=20 > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of BRUNGARD,=20 > > DEBORAH A, ATTLABS > > Sent: Tuesday, January 22, 2008 8:28 PM > > To: ccamp@ops.ietf.org > > Subject: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt > >=20 > > CCAMP, > > =20 > > The DT proposed in their meeting presentation for their=20 > > architecture and framework document to be accepted as a WG draft: > > http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt > > =20 > > We received a couple of comments in the meeting, we would=20 > > appreciate additional feedback on the list. Please express=20 > > your support (or otherwise) for this I-D to become a WG draft. > > =20 > > Thanks, > > Deborah > >=20 >=20 >=20 From owner-ccamp@ops.ietf.org Tue Jan 22 16:58:02 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHR86-0006FM-11 for ccamp-archive@ietf.org; Tue, 22 Jan 2008 16:58:02 -0500 Received: from psg.com ([2001:418:1::62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHR84-0001PE-Vz for ccamp-archive@ietf.org; Tue, 22 Jan 2008 16:58:02 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JHR0g-0005g6-7R for ccamp-data@psg.com; Tue, 22 Jan 2008 21:50:22 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,MISSING_MID, RDNS_NONE autolearn=no version=3.2.3 Received: from [216.104.42.195] (helo=esc91.midphase.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JHR0d-0005fj-Dl for ccamp@ops.ietf.org; Tue, 22 Jan 2008 21:50:20 +0000 Received: from esc91.midphase.com ([216.104.33.66] helo=LC2.labn.net) by esc91.midphase.com with esmtpa (Exim 4.68) (envelope-from ) id 1JHR0W-0006B8-PR; Tue, 22 Jan 2008 16:50:12 -0500 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 22 Jan 2008 16:50:25 -0500 To: "Don Fedyk" From: Lou Berger Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Cc: "PAPADIMITRIOU Dimitri" , "BRUNGARD, DEBORAH A, ATTLABS" , In-Reply-To: <34B3EAA5B3066A42914D28C5ECF5FEA41340D7D1@zrtphxm2.corp.nor tel.com> References: <449B2580D802A443A923DABF3EAB82AF10132C78@OCCLUST04EVS1.ugd.att.com> <34B3EAA5B3066A42914D28C5ECF5FEA41340D7D1@zrtphxm2.corp.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - esc91.midphase.com X-AntiAbuse: Original Domain - ops.ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-Source: X-Source-Args: X-Source-Dir: Sender: owner-ccamp@ops.ietf.org Precedence: bulk Message-Id: X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Don, I agree 100%. Furthermore there is no statement in the draft that 3945 doesn't apply, in fact it explicitly says just the opposite. The reason for the statement in question is simply as you say, and to ensure full ETH-LSP definition and interoperable operation a new switching type/capability is required. It's really not such a bid deal or major change. Lou At 04:34 PM 1/22/2008, Don Fedyk wrote: >Hi Dimitri > >The text you quote was put in the architecture/ framework, not to >exclude L2 Switch Capable (L2SC) but to prevent redefining L2SC, which >has been there for many years and may be in use. > >Perhaps the working needs to be adjusted but I don't think it is a major >issue. > >Regards, >Don > > > -----Original Message----- > > From: owner-ccamp@ops.ietf.org > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of PAPADIMITRIOU Dimitri > > Sent: Tuesday, January 22, 2008 4:16 PM > > To: BRUNGARD, DEBORAH A, ATTLABS; ccamp@ops.ietf.org > > Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt > > > > All, > > > > > We received a couple of comments in the meeting, we would > > > appreciate additional feedback on the list. > > > > The document states: > > > > "The L2SC Interface Switching Capabilities MUST NOT be used > > to represent > > interfaces capable of supporting Eth-LSPs. Interface Switching > > Capability specific TE information may be defined as needed to support > > the requirements of a specific Ethernet Switching Service Type." > > > > [...] > > > > "It is expected that there will be no case where an Eth-LSP will be > > signaled, or an Eth-LSP supporting interface will be > > represented, using > > the L2SC switching type/capability. A new switching type/capability is > > required to avoid any potential current usage of the L2SC switching > > type/capability in support of Ethernet." > > > > This is explicit statement that GMPLS per RFC 3945 is not applicable. > > So, it is much more than just an additional codepoint, as the control > > plane behaviour is to be defined for this codepoint. So, it > > is the open > > door for a new control plane behaviour. > > > > so, let's have a more basic questioning before jumping into the single > > alternative resulting from this doc.: > > > > - either it is GMPLS for Ethernet architecture and then what exist in > > current RFCs should be applicable (because i do not see any rationale > > for L2SC def. departure for Ethernet frame processing); > > > > - or not it is X for Y architecture, where X is an IP control protocol > > based some potentially on some existing GMPLS blocks and Y is not > > compatible with the existing definition of Eth frame processing. > > > > In the latter case, i do not know how this WG can deal with such case > > (from the control plane perspective). > > > > -d. > > > > > > > > > -----Original Message----- > > > From: owner-ccamp@ops.ietf.org > > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of BRUNGARD, > > > DEBORAH A, ATTLABS > > > Sent: Tuesday, January 22, 2008 8:28 PM > > > To: ccamp@ops.ietf.org > > > Subject: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt > > > > > > CCAMP, > > > > > > The DT proposed in their meeting presentation for their > > > architecture and framework document to be accepted as a WG draft: > > > http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt > > > > > > We received a couple of comments in the meeting, we would > > > appreciate additional feedback on the list. Please express > > > your support (or otherwise) for this I-D to become a WG draft. > > > > > > Thanks, > > > Deborah > > > > > > > From owner-ccamp@ops.ietf.org Tue Jan 22 16:58:58 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHR90-0006Tg-K0 for ccamp-archive@ietf.org; Tue, 22 Jan 2008 16:58:58 -0500 Received: from psg.com ([2001:418:1::62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHR8y-0001Qf-Mb for ccamp-archive@ietf.org; Tue, 22 Jan 2008 16:58:58 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JHR3o-00067v-Kt for ccamp-data@psg.com; Tue, 22 Jan 2008 21:53:36 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [62.23.212.27] (helo=smail5.alcatel.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JHR3l-000677-J4 for ccamp@ops.ietf.org; Tue, 22 Jan 2008 21:53:35 +0000 Received: from FRVELSBHS07.ad2.ad.alcatel.com (frvelsbhs07.ad2.ad.alcatel.com [155.132.6.79]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id m0MLk3LB013849; Tue, 22 Jan 2008 22:46:03 +0100 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.51]) by FRVELSBHS07.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Tue, 22 Jan 2008 22:53:23 +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: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Date: Tue, 22 Jan 2008 22:52:55 +0100 Message-ID: In-Reply-To: <34B3EAA5B3066A42914D28C5ECF5FEA41340D7D1@zrtphxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Thread-Index: AchdLOH3JrqySZgzQVuueGk7Nk+CoAACAVJwAAJDMzAAAET6AA== References: <449B2580D802A443A923DABF3EAB82AF10132C78@OCCLUST04EVS1.ugd.att.com> <34B3EAA5B3066A42914D28C5ECF5FEA41340D7D1@zrtphxm2.corp.nortel.com> From: "PAPADIMITRIOU Dimitri" To: "Don Fedyk" , "BRUNGARD, DEBORAH A, ATTLABS" , X-OriginalArrivalTime: 22 Jan 2008 21:53:23.0206 (UTC) FILETIME=[35827A60:01C85D41] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Don, then two things are missing that this new xSC is not resulting in a control plane departing from RFC 3945 and this xSC is not part overlapping with L2SC.=20 you are thus in the alternative: GMPLS for Y architecture, where Y is not compatible with the existing definition of Eth frame processing per L2SC ? is that correct. thanks, -d. =20 > -----Original Message----- > From: Don Fedyk [mailto:dwfedyk@nortel.com]=20 > Sent: Tuesday, January 22, 2008 10:35 PM > To: PAPADIMITRIOU Dimitri; BRUNGARD, DEBORAH A, ATTLABS;=20 > ccamp@ops.ietf.org > Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt >=20 > Hi Dimitri >=20 > The text you quote was put in the architecture/ framework, not to > exclude L2 Switch Capable (L2SC) but to prevent redefining L2SC, which > has been there for many years and may be in use.=20 >=20 > Perhaps the working needs to be adjusted but I don't think it=20 > is a major > issue. >=20 > Regards, > Don=20 >=20 > > -----Original Message----- > > From: owner-ccamp@ops.ietf.org=20 > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of PAPADIMITRIOU Dimitri > > Sent: Tuesday, January 22, 2008 4:16 PM > > To: BRUNGARD, DEBORAH A, ATTLABS; ccamp@ops.ietf.org > > Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt > >=20 > > All, > >=20 > > > We received a couple of comments in the meeting, we would=20 > > > appreciate additional feedback on the list. > >=20 > > The document states: > >=20 > > "The L2SC Interface Switching Capabilities MUST NOT be used=20 > > to represent > > interfaces capable of supporting Eth-LSPs. Interface Switching > > Capability specific TE information may be defined as needed=20 > to support > > the requirements of a specific Ethernet Switching Service Type." > >=20 > > [...] > >=20 > > "It is expected that there will be no case where an Eth-LSP will be > > signaled, or an Eth-LSP supporting interface will be=20 > > represented, using > > the L2SC switching type/capability. A new switching=20 > type/capability is > > required to avoid any potential current usage of the L2SC switching > > type/capability in support of Ethernet." > >=20 > > This is explicit statement that GMPLS per RFC 3945 is not=20 > applicable. > > So, it is much more than just an additional codepoint, as=20 > the control > > plane behaviour is to be defined for this codepoint. So, it=20 > > is the open > > door for a new control plane behaviour.=20 > >=20 > > so, let's have a more basic questioning before jumping into=20 > the single > > alternative resulting from this doc.: > >=20 > > - either it is GMPLS for Ethernet architecture and then=20 > what exist in > > current RFCs should be applicable (because i do not see any=20 > rationale > > for L2SC def. departure for Ethernet frame processing); > >=20 > > - or not it is X for Y architecture, where X is an IP=20 > control protocol > > based some potentially on some existing GMPLS blocks and Y is not > > compatible with the existing definition of Eth frame processing. > >=20 > > In the latter case, i do not know how this WG can deal with=20 > such case > > (from the control plane perspective). > >=20 > > -d. > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: owner-ccamp@ops.ietf.org=20 > > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of BRUNGARD,=20 > > > DEBORAH A, ATTLABS > > > Sent: Tuesday, January 22, 2008 8:28 PM > > > To: ccamp@ops.ietf.org > > > Subject: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt > > >=20 > > > CCAMP, > > > =20 > > > The DT proposed in their meeting presentation for their=20 > > > architecture and framework document to be accepted as a WG draft: > > >=20 > http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt > > > =20 > > > We received a couple of comments in the meeting, we would=20 > > > appreciate additional feedback on the list. Please express=20 > > > your support (or otherwise) for this I-D to become a WG draft. > > > =20 > > > Thanks, > > > Deborah > > >=20 > >=20 > >=20 >=20 From owner-ccamp@ops.ietf.org Tue Jan 22 17:21:15 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHRUZ-0005zl-KK for ccamp-archive@ietf.org; Tue, 22 Jan 2008 17:21:15 -0500 Received: from psg.com ([2001:418:1::62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHRUY-0001uf-Nv for ccamp-archive@ietf.org; Tue, 22 Jan 2008 17:21:15 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JHRLl-0008PE-GU for ccamp-data@psg.com; Tue, 22 Jan 2008 22:12:09 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [64.208.49.27] (helo=smail5.alcatel.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JHRLi-0008Op-K3 for ccamp@ops.ietf.org; Tue, 22 Jan 2008 22:12:08 +0000 Received: from FRVELSBHS07.ad2.ad.alcatel.com (frvelsbhs07.ad2.ad.alcatel.com [155.132.6.79]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id m0MM4TMe017518; Tue, 22 Jan 2008 23:04:29 +0100 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.51]) by FRVELSBHS07.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Tue, 22 Jan 2008 23:11: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: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Date: Tue, 22 Jan 2008 23:11:21 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Thread-Index: AchdQOk1q100BH0uRjeUnZJetJe7CQAAOPUQ References: <449B2580D802A443A923DABF3EAB82AF10132C78@OCCLUST04EVS1.ugd.att.com> <34B3EAA5B3066A42914D28C5ECF5FEA41340D7D1@zrtphxm2.corp.nortel.com> From: "PAPADIMITRIOU Dimitri" To: "Lou Berger" , "Don Fedyk" Cc: "BRUNGARD, DEBORAH A, ATTLABS" , X-OriginalArrivalTime: 22 Jan 2008 22:11:50.0003 (UTC) FILETIME=[C9364C30:01C85D43] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Lou what i am concerned with: is that the doc extends applicability of GMPLS to Ethernet by excluding GMPLS for Ethernet per RFC 3945 ? does that make sense ? what's needed instead of hiding behind terms is to state GMPLS for Y, where Y includes the set of Ethernet-based techno's under development at places as indicated in the doc itself. instead of inducing by a title such as "GMPLS for Ethernet" that this doc supersedes any previous work in that space. -d. =20 > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Lou Berger > Sent: Tuesday, January 22, 2008 10:50 PM > To: Don Fedyk > Cc: PAPADIMITRIOU Dimitri; BRUNGARD, DEBORAH A, ATTLABS;=20 > ccamp@ops.ietf.org > Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt >=20 > Don, > I agree 100%. Furthermore there is no statement in the=20 > draft that 3945 doesn't apply, in fact it explicitly says just the=20 > opposite. The reason for the statement in question is simply as you=20 > say, and to ensure full ETH-LSP definition and interoperable=20 > operation a new switching type/capability is required. >=20 > It's really not such a bid deal or major change. >=20 > Lou >=20 > At 04:34 PM 1/22/2008, Don Fedyk wrote: > >Hi Dimitri > > > >The text you quote was put in the architecture/ framework, not to > >exclude L2 Switch Capable (L2SC) but to prevent redefining=20 > L2SC, which > >has been there for many years and may be in use. > > > >Perhaps the working needs to be adjusted but I don't think=20 > it is a major > >issue. > > > >Regards, > >Don > > > > > -----Original Message----- > > > From: owner-ccamp@ops.ietf.org > > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of=20 > PAPADIMITRIOU Dimitri > > > Sent: Tuesday, January 22, 2008 4:16 PM > > > To: BRUNGARD, DEBORAH A, ATTLABS; ccamp@ops.ietf.org > > > Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt > > > > > > All, > > > > > > > We received a couple of comments in the meeting, we would > > > > appreciate additional feedback on the list. > > > > > > The document states: > > > > > > "The L2SC Interface Switching Capabilities MUST NOT be used > > > to represent > > > interfaces capable of supporting Eth-LSPs. Interface Switching > > > Capability specific TE information may be defined as=20 > needed to support > > > the requirements of a specific Ethernet Switching Service Type." > > > > > > [...] > > > > > > "It is expected that there will be no case where an=20 > Eth-LSP will be > > > signaled, or an Eth-LSP supporting interface will be > > > represented, using > > > the L2SC switching type/capability. A new switching=20 > type/capability is > > > required to avoid any potential current usage of the L2SC=20 > switching > > > type/capability in support of Ethernet." > > > > > > This is explicit statement that GMPLS per RFC 3945 is not=20 > applicable. > > > So, it is much more than just an additional codepoint, as=20 > the control > > > plane behaviour is to be defined for this codepoint. So, it > > > is the open > > > door for a new control plane behaviour. > > > > > > so, let's have a more basic questioning before jumping=20 > into the single > > > alternative resulting from this doc.: > > > > > > - either it is GMPLS for Ethernet architecture and then=20 > what exist in > > > current RFCs should be applicable (because i do not see=20 > any rationale > > > for L2SC def. departure for Ethernet frame processing); > > > > > > - or not it is X for Y architecture, where X is an IP=20 > control protocol > > > based some potentially on some existing GMPLS blocks and Y is not > > > compatible with the existing definition of Eth frame processing. > > > > > > In the latter case, i do not know how this WG can deal=20 > with such case > > > (from the control plane perspective). > > > > > > -d. > > > > > > > > > > > > > -----Original Message----- > > > > From: owner-ccamp@ops.ietf.org > > > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of BRUNGARD, > > > > DEBORAH A, ATTLABS > > > > Sent: Tuesday, January 22, 2008 8:28 PM > > > > To: ccamp@ops.ietf.org > > > > Subject: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt > > > > > > > > CCAMP, > > > > > > > > The DT proposed in their meeting presentation for their > > > > architecture and framework document to be accepted as a=20 > WG draft: > > > >=20 > http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt > > > > > > > > We received a couple of comments in the meeting, we would > > > > appreciate additional feedback on the list. Please express > > > > your support (or otherwise) for this I-D to become a WG draft. > > > > > > > > Thanks, > > > > Deborah > > > > > > > > > > >=20 >=20 >=20 From owner-ccamp@ops.ietf.org Tue Jan 22 17:33:23 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHRgJ-0003B7-H7 for ccamp-archive@ietf.org; Tue, 22 Jan 2008 17:33:23 -0500 Received: from psg.com ([2001:418:1::62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHRgH-0002BC-Ln for ccamp-archive@ietf.org; Tue, 22 Jan 2008 17:33:23 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JHRbD-0009z6-BK for ccamp-data@psg.com; Tue, 22 Jan 2008 22:28:07 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,MISSING_MID, RDNS_NONE autolearn=no version=3.2.3 Received: from [216.104.42.195] (helo=esc91.midphase.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JHRbA-0009yQ-8y for ccamp@ops.ietf.org; Tue, 22 Jan 2008 22:28:05 +0000 Received: from esc91.midphase.com ([216.104.33.66] helo=LC2.labn.net) by esc91.midphase.com with esmtpa (Exim 4.68) (envelope-from ) id 1JHRb2-0007UO-5i; Tue, 22 Jan 2008 17:27:56 -0500 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 22 Jan 2008 17:28:08 -0500 To: "PAPADIMITRIOU Dimitri" From: Lou Berger Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Cc: "Lou Berger" ,"Don Fedyk" , "BRUNGARD, DEBORAH A, ATTLABS" , In-Reply-To: References: <449B2580D802A443A923DABF3EAB82AF10132C78@OCCLUST04EVS1.ugd.att.com> <34B3EAA5B3066A42914D28C5ECF5FEA41340D7D1@zrtphxm2.corp.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - esc91.midphase.com X-AntiAbuse: Original Domain - ops.ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-Source: X-Source-Args: X-Source-Dir: Sender: owner-ccamp@ops.ietf.org Precedence: bulk Message-Id: X-Spam-Score: 0.0 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 I have no objection to adding "Updates: 3945" to the document header and matching 3945's category. Lou At 05:11 PM 1/22/2008, PAPADIMITRIOU Dimitri wrote: >Lou > >what i am concerned with: is that the doc extends applicability of GMPLS >to Ethernet by excluding GMPLS for Ethernet per RFC 3945 ? does that >make sense ? > >what's needed instead of hiding behind terms is to state GMPLS for Y, >where Y includes the set of Ethernet-based techno's under development at >places as indicated in the doc itself. instead of inducing by a title >such as "GMPLS for Ethernet" that this doc supersedes any previous work >in that >space. > >-d. > > > > > > -----Original Message----- > > From: owner-ccamp@ops.ietf.org > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Lou Berger > > Sent: Tuesday, January 22, 2008 10:50 PM > > To: Don Fedyk > > Cc: PAPADIMITRIOU Dimitri; BRUNGARD, DEBORAH A, ATTLABS; > > ccamp@ops.ietf.org > > Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt > > > > Don, > > I agree 100%. Furthermore there is no statement in the > > draft that 3945 doesn't apply, in fact it explicitly says just the > > opposite. The reason for the statement in question is simply as you > > say, and to ensure full ETH-LSP definition and interoperable > > operation a new switching type/capability is required. > > > > It's really not such a bid deal or major change. > > > > Lou > > > > At 04:34 PM 1/22/2008, Don Fedyk wrote: > > >Hi Dimitri > > > > > >The text you quote was put in the architecture/ framework, not to > > >exclude L2 Switch Capable (L2SC) but to prevent redefining > > L2SC, which > > >has been there for many years and may be in use. > > > > > >Perhaps the working needs to be adjusted but I don't think > > it is a major > > >issue. > > > > > >Regards, > > >Don > > > > > > > -----Original Message----- > > > > From: owner-ccamp@ops.ietf.org > > > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of > > PAPADIMITRIOU Dimitri > > > > Sent: Tuesday, January 22, 2008 4:16 PM > > > > To: BRUNGARD, DEBORAH A, ATTLABS; ccamp@ops.ietf.org > > > > Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt > > > > > > > > All, > > > > > > > > > We received a couple of comments in the meeting, we would > > > > > appreciate additional feedback on the list. > > > > > > > > The document states: > > > > > > > > "The L2SC Interface Switching Capabilities MUST NOT be used > > > > to represent > > > > interfaces capable of supporting Eth-LSPs. Interface Switching > > > > Capability specific TE information may be defined as > > needed to support > > > > the requirements of a specific Ethernet Switching Service Type." > > > > > > > > [...] > > > > > > > > "It is expected that there will be no case where an > > Eth-LSP will be > > > > signaled, or an Eth-LSP supporting interface will be > > > > represented, using > > > > the L2SC switching type/capability. A new switching > > type/capability is > > > > required to avoid any potential current usage of the L2SC > > switching > > > > type/capability in support of Ethernet." > > > > > > > > This is explicit statement that GMPLS per RFC 3945 is not > > applicable. > > > > So, it is much more than just an additional codepoint, as > > the control > > > > plane behaviour is to be defined for this codepoint. So, it > > > > is the open > > > > door for a new control plane behaviour. > > > > > > > > so, let's have a more basic questioning before jumping > > into the single > > > > alternative resulting from this doc.: > > > > > > > > - either it is GMPLS for Ethernet architecture and then > > what exist in > > > > current RFCs should be applicable (because i do not see > > any rationale > > > > for L2SC def. departure for Ethernet frame processing); > > > > > > > > - or not it is X for Y architecture, where X is an IP > > control protocol > > > > based some potentially on some existing GMPLS blocks and Y is not > > > > compatible with the existing definition of Eth frame processing. > > > > > > > > In the latter case, i do not know how this WG can deal > > with such case > > > > (from the control plane perspective). > > > > > > > > -d. > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: owner-ccamp@ops.ietf.org > > > > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of BRUNGARD, > > > > > DEBORAH A, ATTLABS > > > > > Sent: Tuesday, January 22, 2008 8:28 PM > > > > > To: ccamp@ops.ietf.org > > > > > Subject: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt > > > > > > > > > > CCAMP, > > > > > > > > > > The DT proposed in their meeting presentation for their > > > > > architecture and framework document to be accepted as a > > WG draft: > > > > > > > http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt > > > > > > > > > > We received a couple of comments in the meeting, we would > > > > > appreciate additional feedback on the list. Please express > > > > > your support (or otherwise) for this I-D to become a WG draft. > > > > > > > > > > Thanks, > > > > > Deborah > > > > > > > > > > > > > > > > > > > From owner-ccamp@ops.ietf.org Tue Jan 22 17:54:37 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHS0r-0002Om-6d for ccamp-archive@ietf.org; Tue, 22 Jan 2008 17:54:37 -0500 Received: from psg.com ([2001:418:1::62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHS0o-0002jG-QM for ccamp-archive@ietf.org; Tue, 22 Jan 2008 17:54:37 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JHRs7-000BSf-VZ for ccamp-data@psg.com; Tue, 22 Jan 2008 22:45:35 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [64.208.49.5] (helo=smail6.alcatel.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JHRs4-000BSK-KN for ccamp@ops.ietf.org; Tue, 22 Jan 2008 22:45:34 +0000 Received: from FRVELSBHS04.ad2.ad.alcatel.com (frvelsbhs04.ad2.ad.alcatel.com [155.132.6.76]) by smail6.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id m0MMhAdO007766; Tue, 22 Jan 2008 23:43:10 +0100 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.51]) by FRVELSBHS04.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Tue, 22 Jan 2008 23:45:17 +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: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Date: Tue, 22 Jan 2008 23:44:49 +0100 Message-ID: In-Reply-To: <200801222228.m0MMRxVa004316@mailgate4.alcatel.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Thread-Index: AchdRg0gQbG+sqB3QeGKnEMmTkpUoAAACQTQ References: <449B2580D802A443A923DABF3EAB82AF10132C78@OCCLUST04EVS1.ugd.att.com> <34B3EAA5B3066A42914D28C5ECF5FEA41340D7D1@zrtphxm2.corp.nortel.com> <200801222228.m0MMRxVa004316@mailgate4.alcatel.fr> From: "PAPADIMITRIOU Dimitri" To: "Lou Berger" Cc: "Don Fedyk" , "BRUNGARD, DEBORAH A, ATTLABS" , X-OriginalArrivalTime: 22 Jan 2008 22:45:17.0444 (UTC) FILETIME=[75BD7C40:01C85D48] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.84 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7 thus the question is whether or not to ask for a change CCAMP "common control" in DCAMP "differentiated control" per technology ?=20 we never have had a techno inducing a base building block change (GMPLS being a generalisation of MPLS-TE). i'm afraid that generalized LSP, generalized LSR, generalized label, etc. per GMPLS arch (RFC 3945) would simply be unapplicable as known today and thus the corr. base protocol specs unapplicable. at the end the term "GMPLS" would be emptied of any real substance. it's a choice but let's ask the questions from the right perspective. -d.=20 > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net]=20 > Sent: Tuesday, January 22, 2008 11:28 PM > To: PAPADIMITRIOU Dimitri > Cc: Lou Berger; Don Fedyk; BRUNGARD, DEBORAH A, ATTLABS;=20 > ccamp@ops.ietf.org > Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt >=20 > I have no objection to adding "Updates: 3945" to the document header=20 > and matching 3945's category. >=20 > Lou >=20 > At 05:11 PM 1/22/2008, PAPADIMITRIOU Dimitri wrote: > >Lou > > > >what i am concerned with: is that the doc extends=20 > applicability of GMPLS > >to Ethernet by excluding GMPLS for Ethernet per RFC 3945 ? does that > >make sense ? > > > >what's needed instead of hiding behind terms is to state GMPLS for Y, > >where Y includes the set of Ethernet-based techno's under=20 > development at > >places as indicated in the doc itself. instead of inducing by a title > >such as "GMPLS for Ethernet" that this doc supersedes any=20 > previous work > >in that > >space. > > > >-d. > > > > > > > > > > > -----Original Message----- > > > From: owner-ccamp@ops.ietf.org > > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Lou Berger > > > Sent: Tuesday, January 22, 2008 10:50 PM > > > To: Don Fedyk > > > Cc: PAPADIMITRIOU Dimitri; BRUNGARD, DEBORAH A, ATTLABS; > > > ccamp@ops.ietf.org > > > Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt > > > > > > Don, > > > I agree 100%. Furthermore there is no statement in the > > > draft that 3945 doesn't apply, in fact it explicitly says just the > > > opposite. The reason for the statement in question is=20 > simply as you > > > say, and to ensure full ETH-LSP definition and interoperable > > > operation a new switching type/capability is required. > > > > > > It's really not such a bid deal or major change. > > > > > > Lou > > > > > > At 04:34 PM 1/22/2008, Don Fedyk wrote: > > > >Hi Dimitri > > > > > > > >The text you quote was put in the architecture/ framework, not to > > > >exclude L2 Switch Capable (L2SC) but to prevent redefining > > > L2SC, which > > > >has been there for many years and may be in use. > > > > > > > >Perhaps the working needs to be adjusted but I don't think > > > it is a major > > > >issue. > > > > > > > >Regards, > > > >Don > > > > > > > > > -----Original Message----- > > > > > From: owner-ccamp@ops.ietf.org > > > > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of > > > PAPADIMITRIOU Dimitri > > > > > Sent: Tuesday, January 22, 2008 4:16 PM > > > > > To: BRUNGARD, DEBORAH A, ATTLABS; ccamp@ops.ietf.org > > > > > Subject: RE: Proposed WG Draft -=20 > draft-gmpls-ethernet-arch-00.txt > > > > > > > > > > All, > > > > > > > > > > > We received a couple of comments in the meeting, we would > > > > > > appreciate additional feedback on the list. > > > > > > > > > > The document states: > > > > > > > > > > "The L2SC Interface Switching Capabilities MUST NOT be used > > > > > to represent > > > > > interfaces capable of supporting Eth-LSPs. Interface Switching > > > > > Capability specific TE information may be defined as > > > needed to support > > > > > the requirements of a specific Ethernet Switching=20 > Service Type." > > > > > > > > > > [...] > > > > > > > > > > "It is expected that there will be no case where an > > > Eth-LSP will be > > > > > signaled, or an Eth-LSP supporting interface will be > > > > > represented, using > > > > > the L2SC switching type/capability. A new switching > > > type/capability is > > > > > required to avoid any potential current usage of the L2SC > > > switching > > > > > type/capability in support of Ethernet." > > > > > > > > > > This is explicit statement that GMPLS per RFC 3945 is not > > > applicable. > > > > > So, it is much more than just an additional codepoint, as > > > the control > > > > > plane behaviour is to be defined for this codepoint. So, it > > > > > is the open > > > > > door for a new control plane behaviour. > > > > > > > > > > so, let's have a more basic questioning before jumping > > > into the single > > > > > alternative resulting from this doc.: > > > > > > > > > > - either it is GMPLS for Ethernet architecture and then > > > what exist in > > > > > current RFCs should be applicable (because i do not see > > > any rationale > > > > > for L2SC def. departure for Ethernet frame processing); > > > > > > > > > > - or not it is X for Y architecture, where X is an IP > > > control protocol > > > > > based some potentially on some existing GMPLS blocks=20 > and Y is not > > > > > compatible with the existing definition of Eth frame=20 > processing. > > > > > > > > > > In the latter case, i do not know how this WG can deal > > > with such case > > > > > (from the control plane perspective). > > > > > > > > > > -d. > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: owner-ccamp@ops.ietf.org > > > > > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of BRUNGARD, > > > > > > DEBORAH A, ATTLABS > > > > > > Sent: Tuesday, January 22, 2008 8:28 PM > > > > > > To: ccamp@ops.ietf.org > > > > > > Subject: Proposed WG Draft -=20 > draft-gmpls-ethernet-arch-00.txt > > > > > > > > > > > > CCAMP, > > > > > > > > > > > > The DT proposed in their meeting presentation for their > > > > > > architecture and framework document to be accepted as a > > > WG draft: > > > > > > > > >=20 > http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt > > > > > > > > > > > > We received a couple of comments in the meeting, we would > > > > > > appreciate additional feedback on the list. Please express > > > > > > your support (or otherwise) for this I-D to become=20 > a WG draft. > > > > > > > > > > > > Thanks, > > > > > > Deborah > > > > > > > > > > > > > > > > > > > > > > > > > >=20 >=20 From owner-ccamp@ops.ietf.org Tue Jan 22 19:17:25 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHTIz-0005TQ-Ph for ccamp-archive@ietf.org; Tue, 22 Jan 2008 19:17:25 -0500 Received: from psg.com ([2001:418:1::62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHTIx-0004OJ-OJ for ccamp-archive@ietf.org; Tue, 22 Jan 2008 19:17:25 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JHTAr-000JFX-Gk for ccamp-data@psg.com; Wed, 23 Jan 2008 00:09:01 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,MISSING_MID, RDNS_NONE autolearn=no version=3.2.3 Received: from [216.104.42.195] (helo=esc91.midphase.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JHTAo-000JFG-Gg for ccamp@ops.ietf.org; Wed, 23 Jan 2008 00:08:59 +0000 Received: from esc91.midphase.com ([216.104.33.66] helo=LC2.labn.net) by esc91.midphase.com with esmtpa (Exim 4.68) (envelope-from ) id 1JHTAL-00055K-IG; Tue, 22 Jan 2008 19:08:29 -0500 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 22 Jan 2008 19:08:41 -0500 To: "PAPADIMITRIOU Dimitri" From: Lou Berger Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Cc: "Lou Berger" ,"Don Fedyk" , "BRUNGARD, DEBORAH A, ATTLABS" , In-Reply-To: References: <449B2580D802A443A923DABF3EAB82AF10132C78@OCCLUST04EVS1.ugd.att.com> <34B3EAA5B3066A42914D28C5ECF5FEA41340D7D1@zrtphxm2.corp.nortel.com> <200801222228.m0MMRxVa004316@mailgate4.alcatel.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - esc91.midphase.com X-AntiAbuse: Original Domain - ops.ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-Source: X-Source-Args: X-Source-Dir: Sender: owner-ccamp@ops.ietf.org Precedence: bulk Message-Id: X-Spam-Score: 0.0 (/) X-Scan-Signature: cdb443e3957ca9b4c5b55e78cfcf4b26 We've always had different switching type/capability in GMPLS. Nothing new here. L2SC was always underspecified (e.g., covers both ATM and Ether), is currently used by some for different purposes, and doesn't allow unique identification of switching capabilities of an interface. I *really* don't see the unique identification of an interface's Ethernet switching function as any different from what is done for today for the other types or as any big deal or change in GMPLS direction or architecture. but, that's just my perspective. Lou At 05:44 PM 1/22/2008, PAPADIMITRIOU Dimitri wrote: >thus the question is whether or not to ask for a change CCAMP "common >control" in DCAMP "differentiated control" per technology ? > >we never have had a techno inducing a base building block change (GMPLS >being a generalisation of MPLS-TE). i'm afraid that generalized LSP, >generalized LSR, generalized label, etc. per GMPLS arch (RFC 3945) would >simply be unapplicable as known today and thus the corr. base protocol >specs unapplicable. at the end the term "GMPLS" would be emptied of any >real substance. > >it's a choice but let's ask the questions from the right perspective. > >-d. > > > -----Original Message----- > > From: Lou Berger [mailto:lberger@labn.net] > > Sent: Tuesday, January 22, 2008 11:28 PM > > To: PAPADIMITRIOU Dimitri > > Cc: Lou Berger; Don Fedyk; BRUNGARD, DEBORAH A, ATTLABS; > > ccamp@ops.ietf.org > > Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt > > > > I have no objection to adding "Updates: 3945" to the document header > > and matching 3945's category. > > > > Lou > > > > At 05:11 PM 1/22/2008, PAPADIMITRIOU Dimitri wrote: > > >Lou > > > > > >what i am concerned with: is that the doc extends > > applicability of GMPLS > > >to Ethernet by excluding GMPLS for Ethernet per RFC 3945 ? does that > > >make sense ? > > > > > >what's needed instead of hiding behind terms is to state GMPLS for Y, > > >where Y includes the set of Ethernet-based techno's under > > development at > > >places as indicated in the doc itself. instead of inducing by a title > > >such as "GMPLS for Ethernet" that this doc supersedes any > > previous work > > >in that > > >space. > > > > > >-d. > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: owner-ccamp@ops.ietf.org > > > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Lou Berger > > > > Sent: Tuesday, January 22, 2008 10:50 PM > > > > To: Don Fedyk > > > > Cc: PAPADIMITRIOU Dimitri; BRUNGARD, DEBORAH A, ATTLABS; > > > > ccamp@ops.ietf.org > > > > Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt > > > > > > > > Don, > > > > I agree 100%. Furthermore there is no statement in the > > > > draft that 3945 doesn't apply, in fact it explicitly says just the > > > > opposite. The reason for the statement in question is > > simply as you > > > > say, and to ensure full ETH-LSP definition and interoperable > > > > operation a new switching type/capability is required. > > > > > > > > It's really not such a bid deal or major change. > > > > > > > > Lou > > > > > > > > At 04:34 PM 1/22/2008, Don Fedyk wrote: > > > > >Hi Dimitri > > > > > > > > > >The text you quote was put in the architecture/ framework, not to > > > > >exclude L2 Switch Capable (L2SC) but to prevent redefining > > > > L2SC, which > > > > >has been there for many years and may be in use. > > > > > > > > > >Perhaps the working needs to be adjusted but I don't think > > > > it is a major > > > > >issue. > > > > > > > > > >Regards, > > > > >Don > > > > > > > > > > > -----Original Message----- > > > > > > From: owner-ccamp@ops.ietf.org > > > > > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of > > > > PAPADIMITRIOU Dimitri > > > > > > Sent: Tuesday, January 22, 2008 4:16 PM > > > > > > To: BRUNGARD, DEBORAH A, ATTLABS; ccamp@ops.ietf.org > > > > > > Subject: RE: Proposed WG Draft - > > draft-gmpls-ethernet-arch-00.txt > > > > > > > > > > > > All, > > > > > > > > > > > > > We received a couple of comments in the meeting, we would > > > > > > > appreciate additional feedback on the list. > > > > > > > > > > > > The document states: > > > > > > > > > > > > "The L2SC Interface Switching Capabilities MUST NOT be used > > > > > > to represent > > > > > > interfaces capable of supporting Eth-LSPs. Interface Switching > > > > > > Capability specific TE information may be defined as > > > > needed to support > > > > > > the requirements of a specific Ethernet Switching > > Service Type." > > > > > > > > > > > > [...] > > > > > > > > > > > > "It is expected that there will be no case where an > > > > Eth-LSP will be > > > > > > signaled, or an Eth-LSP supporting interface will be > > > > > > represented, using > > > > > > the L2SC switching type/capability. A new switching > > > > type/capability is > > > > > > required to avoid any potential current usage of the L2SC > > > > switching > > > > > > type/capability in support of Ethernet." > > > > > > > > > > > > This is explicit statement that GMPLS per RFC 3945 is not > > > > applicable. > > > > > > So, it is much more than just an additional codepoint, as > > > > the control > > > > > > plane behaviour is to be defined for this codepoint. So, it > > > > > > is the open > > > > > > door for a new control plane behaviour. > > > > > > > > > > > > so, let's have a more basic questioning before jumping > > > > into the single > > > > > > alternative resulting from this doc.: > > > > > > > > > > > > - either it is GMPLS for Ethernet architecture and then > > > > what exist in > > > > > > current RFCs should be applicable (because i do not see > > > > any rationale > > > > > > for L2SC def. departure for Ethernet frame processing); > > > > > > > > > > > > - or not it is X for Y architecture, where X is an IP > > > > control protocol > > > > > > based some potentially on some existing GMPLS blocks > > and Y is not > > > > > > compatible with the existing definition of Eth frame > > processing. > > > > > > > > > > > > In the latter case, i do not know how this WG can deal > > > > with such case > > > > > > (from the control plane perspective). > > > > > > > > > > > > -d. > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: owner-ccamp@ops.ietf.org > > > > > > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of BRUNGARD, > > > > > > > DEBORAH A, ATTLABS > > > > > > > Sent: Tuesday, January 22, 2008 8:28 PM > > > > > > > To: ccamp@ops.ietf.org > > > > > > > Subject: Proposed WG Draft - > > draft-gmpls-ethernet-arch-00.txt > > > > > > > > > > > > > > CCAMP, > > > > > > > > > > > > > > The DT proposed in their meeting presentation for their > > > > > > > architecture and framework document to be accepted as a > > > > WG draft: > > > > > > > > > > > > > http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt > > > > > > > > > > > > > > We received a couple of comments in the meeting, we would > > > > > > > appreciate additional feedback on the list. Please express > > > > > > > your support (or otherwise) for this I-D to become > > a WG draft. > > > > > > > > > > > > > > Thanks, > > > > > > > Deborah > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From johndin@med.cmu.ac.th Tue Jan 22 21:59:15 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHVpb-0004xE-2r for ccamp-archive@ietf.org; Tue, 22 Jan 2008 21:59:15 -0500 Received: from [58.232.120.145] (helo=wfliasc) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JHVpY-0003iR-7w for ccamp-archive@ietf.org; Tue, 22 Jan 2008 21:59:12 -0500 Received: from ggigw ([213.66.220.138]) by wfliasc (8.13.2/8.13.2) with SMTP id m0N33aGR027750; Wed, 23 Jan 2008 12:03:36 +0900 Message-ID: <4796AD7E.3000804@med.cmu.ac.th> Date: Wed, 23 Jan 2008 11:59:10 +0900 From: User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: ccamp-archive@ietf.org Subject: A Toast My Love Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 When I'm With You http://69.229.114.27/ From Jaosn.Kibbee@apo-we.de Tue Jan 22 23:49:48 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHXYa-0005pE-DP for ccamp-archive@ietf.org; Tue, 22 Jan 2008 23:49:48 -0500 Received: from host166-26-dynamic.13-87-r.retail.telecomitalia.it ([87.13.26.166] helo=host166-167-dynamic.15-87-r.retail.telecomitalia.it) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JHXYX-0006oF-LC for ccamp-archive@ietf.org; Tue, 22 Jan 2008 23:49:47 -0500 Received: from espanico ([189.147.26.183] helo=espanico) by host127-107-static.4-79-b.business.telecomitalia.it ( sendmail 8.13.3/8.13.1) with esmtpa id 1XWhcz-000RWJ-IY for ccamp-archive@ietf.org; Wed, 23 Jan 2008 05:49:52 -0200 Message-ID: <000901c85d94$7d7965b0$7f6b044f@espanico> From: "Jaosn Kibbee" To: Subject: angegane Date: Wed, 23 Jan 2008 05:49:32 -0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C85D83.B9F306B0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 2.1 (++) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 ------=_NextPart_000_0009_01C85D83.B9F306B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Greeting ccamp-archive the quicker pecker upper http://deravforest.com Jaosn Kibbee ------=_NextPart_000_0009_01C85D83.B9F306B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Greeting ccamp-archive
the quicker pecker upper
http://deravforest.com
Jaosn Kibbee
------=_NextPart_000_0009_01C85D83.B9F306B0-- From ngkallenxfqa@allthingspublishing.com Wed Jan 23 01:31:45 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHZ9E-0003b9-W9 for ccamp-archive@megatron.ietf.org; Wed, 23 Jan 2008 01:31:45 -0500 Received: from [213.154.211.196] (helo=211-196.static.alkar.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JHZ9E-00016r-Bz for ccamp-archive@megatron.ietf.org; Wed, 23 Jan 2008 01:31:44 -0500 Received: from GB ([164.180.98.185]:1481 "EHLO GB" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by 211-196.static.alkar.net with ESMTP id S22DXZCTXWRWUMQM (ORCPT ); Wed, 23 Jan 2008 09:32:11 +0300 Message-ID: <852E429B.2D62E0D5@allthingspublishing.com> Date: Wed, 23 Jan 2008 09:31:39 +0300 From: User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: ccamp-archive@megatron.ietf.org Subject: nfreries Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 4.5 (++++) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Make her moan louder and come faster when you've increased size http://www.beekeeni.com/
From ademMacrae@www.media3.net Wed Jan 23 04:22:24 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHboO-0006A4-4G for ccamp-archive@ietf.org; Wed, 23 Jan 2008 04:22:24 -0500 Received: from host101-102-dynamic.11-87-r.retail.telecomitalia.it ([87.11.102.101]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JHboN-0007JN-EK for ccamp-archive@ietf.org; Wed, 23 Jan 2008 04:22:23 -0500 Received: by 10.105.140.109 with SMTP id rpKKBDxyKluUu; Wed, 23 Jan 2008 10:22:31 +0100 (GMT) Received: by 192.168.221.207 with SMTP id bzNoowcrLAjXVE.6054158351582; Wed, 23 Jan 2008 10:22:29 +0100 (GMT) Message-ID: <000a01c85da1$78381bc0$65660b57@nomea6481dbe30> From: "adem Macrae" To: Subject: orgne-mr Date: Wed, 23 Jan 2008 10:22:26 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C85DA9.D9FC83C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 ------=_NextPart_000_0004_01C85DA9.D9FC83C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Greeting ccamp-archive You Love to Fly, and It Shows! http://earbellglas.com adem Macrae ------=_NextPart_000_0004_01C85DA9.D9FC83C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Greeting ccamp-archive
You Love to Fly, and It Shows!
http://earbellglas.com
adem Macrae
------=_NextPart_000_0004_01C85DA9.D9FC83C0-- From owner-ccamp@ops.ietf.org Wed Jan 23 05:06:25 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHcUz-0001ef-9b for ccamp-archive@ietf.org; Wed, 23 Jan 2008 05:06:25 -0500 Received: from psg.com ([2001:418:1::62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHcUx-0001zj-Gp for ccamp-archive@ietf.org; Wed, 23 Jan 2008 05:06:25 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JHcI2-000Bu5-PW for ccamp-data@psg.com; Wed, 23 Jan 2008 09:53:02 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE, RDNS_NONE autolearn=no version=3.2.3 Received: from [193.180.251.62] (helo=mailgw4.ericsson.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JHcHw-000BsR-Ki for ccamp@ops.ietf.org; Wed, 23 Jan 2008 09:52:58 +0000 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 579CA213D6; Wed, 23 Jan 2008 10:52:51 +0100 (CET) X-AuditID: c1b4fb3e-ae5efbb0000007e1-66-47970e73a2d6 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 3E812213D5; Wed, 23 Jan 2008 10:52:51 +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, 23 Jan 2008 10:52:51 +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_01C85DA5.B712FDC4" Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Date: Wed, 23 Jan 2008 10:52:50 +0100 Message-ID: <53CCFDD6E346CB43994852666C210E91026246AE@esealmw116.eemea.ericsson.se> In-Reply-To: <449B2580D802A443A923DABF3EAB82AF10132C78@OCCLUST04EVS1.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Thread-Index: AchdLOH3JrqySZgzQVuueGk7Nk+CoAAeLaiw References: <449B2580D802A443A923DABF3EAB82AF10132C78@OCCLUST04EVS1.ugd.att.com> From: "Attila Takacs" To: "BRUNGARD, DEBORAH A, ATTLABS" , X-OriginalArrivalTime: 23 Jan 2008 09:52:51.0005 (UTC) FILETIME=[B785DED0:01C85DA5] X-Brightmail-Tracker: AAAAAA== Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -1.0 (-) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 This is a multi-part message in MIME format. ------_=_NextPart_001_01C85DA5.B712FDC4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In favor. Attila ________________________________ From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of BRUNGARD, DEBORAH A, ATTLABS Sent: Tuesday, January 22, 2008 8:28 PM To: ccamp@ops.ietf.org Subject: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt =09 =09 CCAMP, =20 The DT proposed in their meeting presentation for their architecture and framework document to be accepted as a WG draft: =09 http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt =20 We received a couple of comments in the meeting, we would appreciate additional feedback on the list. Please express your support (or otherwise) for this I-D to become a WG draft. =20 Thanks, Deborah ------_=_NextPart_001_01C85DA5.B712FDC4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
In=20 favor.
Attila

From: owner-ccamp@ops.ietf.org=20 [mailto:owner-ccamp@ops.ietf.org] On Behalf Of BRUNGARD, = DEBORAH A,=20 ATTLABS
Sent: Tuesday, January 22, 2008 8:28 = PM
To:=20 ccamp@ops.ietf.org
Subject: Proposed WG Draft -=20 draft-gmpls-ethernet-arch-00.txt

CCAMP,
 
The = DT proposed in=20 their meeting presentation for their architecture and framework=20 document to be accepted as a WG = draft:
http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt=
 
We = received a=20 couple of comments in the meeting, we would appreciate additional = feedback on the list. Please express your support (or otherwise) = for this=20 I-D to become a WG draft.
 
Thanks,
Deborah
------_=_NextPart_001_01C85DA5.B712FDC4-- From owner-ccamp@ops.ietf.org Wed Jan 23 07:47:09 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHf0X-0006p7-DH for ccamp-archive@ietf.org; Wed, 23 Jan 2008 07:47:09 -0500 Received: from psg.com ([2001:418:1::62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHf0U-0006eT-M7 for ccamp-archive@ietf.org; Wed, 23 Jan 2008 07:47:09 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JHeqX-0000P2-4D for ccamp-data@psg.com; Wed, 23 Jan 2008 12:36:49 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [194.192.15.188] (helo=dkcphmx24.softcom.dk) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JHeqR-0000OP-73 for ccamp@ops.ietf.org; Wed, 23 Jan 2008 12:36:47 +0000 Received: from gw.imc.kth.se (193.10.152.67) by dkcphmx24.softcom.dk (envelope-from ) with ESMTP. tag msg.1201091799.492746.32134 (Processed in 0.16347 secs); 23 Jan 2008 12:36:39 -0000 X-SoftScan-Status: clean Received: from DOMAIN1-MTA by mail1.imc.kth.se with Novell_GroupWise; Wed, 23 Jan 2008 13:36:38 +0100 Message-Id: <479742C4.6F67.00AA.0@acreo.se> X-Mailer: Novell GroupWise Internet Agent 7.0.1 Date: Wed, 23 Jan 2008 13:36:05 +0100 From: "Anders Gavler" To: "DEBORAH A ATTLABS BRUNGARD" , Subject: Re: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt References: <449B2580D802A443A923DABF3EAB82AF10132C78@OCCLUST04EVS1.ugd.att.com> In-Reply-To: <449B2580D802A443A923DABF3EAB82AF10132C78@OCCLUST04EVS1.ugd.att.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=__Part290FF4A5.1__=" Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -1.0 (-) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part290FF4A5.1__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline In favor of this! Anders Gavler Acreo AB Electrum 236 SE - 164 40 Kista Phone: +46 8 632 77 29 Homepage: http://www.acreo.se >>> "BRUNGARD, DEBORAH A, ATTLABS" 2008-01-22 20:27 >>> CCAMP, The DT proposed in their meeting presentation for their architecture and framework document to be accepted as a WG draft: http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt We received a couple of comments in the meeting, we would appreciate additional feedback on the list. Please express your support (or otherwise) for this I-D to become a WG draft. Thanks, Deborah --=__Part290FF4A5.1__= Content-Type: text/plain; name="Anders Gavler1.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Anders Gavler1.vcf" BEGIN:VCARD VERSION:2.1 X-GWTYPE:USER FN:Anders Gavler TEL;WORK:08-6327729 EMAIL;WORK;PREF;NGW:Anders.Gavler@acreo.se N:Gavler;Anders END:VCARD BEGIN:VCARD VERSION:2.1 X-GWTYPE:USER FN:Anders Gavler TEL;WORK:08-6327729 EMAIL;WORK;PREF;NGW:Anders.Gavler@acreo.se N:Gavler;Anders END:VCARD BEGIN:VCARD VERSION:2.1 X-GWTYPE:USER FN:Anders Gavler TEL;WORK:08-6327729 EMAIL;WORK;PREF;NGW:Anders.Gavler@acreo.se N:Gavler;Anders END:VCARD BEGIN:VCARD VERSION:2.1 X-GWTYPE:USER FN:Anders Gavler TEL;WORK:08-6327729 EMAIL;WORK;PREF;NGW:Anders.Gavler@acreo.se N:Gavler;Anders END:VCARD --=__Part290FF4A5.1__=-- From owner-ccamp@ops.ietf.org Wed Jan 23 08:38:58 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHfog-0002wW-7W for ccamp-archive@ietf.org; Wed, 23 Jan 2008 08:38:58 -0500 Received: from psg.com ([2001:418:1::62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHfoe-0007bB-8v for ccamp-archive@ietf.org; Wed, 23 Jan 2008 08:38:58 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JHfgH-0005z3-HS for ccamp-data@psg.com; Wed, 23 Jan 2008 13:30:17 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,HTML_MESSAGE, RDNS_NONE autolearn=no version=3.2.3 Received: from [198.24.6.3] (helo=imr2.ericy.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JHfgE-0005yc-Qg for ccamp@ops.ietf.org; Wed, 23 Jan 2008 13:30:16 +0000 Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id m0NDU9IQ008486; Wed, 23 Jan 2008 07:30:09 -0600 Received: from eusrcmw720.eamcs.ericsson.se ([138.85.77.20]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Jan 2008 07:30:09 -0600 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_01C85DC4.129C2CE7" Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Date: Wed, 23 Jan 2008 07:30:08 -0600 Message-ID: <8ECB099B6E0A044695BD93961F3498820682D379@eusrcmw720.eamcs.ericsson.se> In-Reply-To: <449B2580D802A443A923DABF3EAB82AF10132C78@OCCLUST04EVS1.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Thread-Index: AchdLOH3JrqySZgzQVuueGk7Nk+CoAAlyQFg References: <449B2580D802A443A923DABF3EAB82AF10132C78@OCCLUST04EVS1.ugd.att.com> From: "David Sinicrope" To: "BRUNGARD, DEBORAH A, ATTLABS" , X-OriginalArrivalTime: 23 Jan 2008 13:30:09.0326 (UTC) FILETIME=[12F7C4E0:01C85DC4] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 This is a multi-part message in MIME format. ------_=_NextPart_001_01C85DC4.129C2CE7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support for WG draft. ________________________________ From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of BRUNGARD, DEBORAH A, ATTLABS Sent: Tuesday, January 22, 2008 2:28 PM To: ccamp@ops.ietf.org Subject: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt CCAMP, =20 The DT proposed in their meeting presentation for their architecture and framework document to be accepted as a WG draft: http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt =20 We received a couple of comments in the meeting, we would appreciate additional feedback on the list. Please express your support (or otherwise) for this I-D to become a WG draft. =20 Thanks, Deborah ------_=_NextPart_001_01C85DC4.129C2CE7 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Support for WG draft.

From: owner-ccamp@ops.ietf.org=20 [mailto:owner-ccamp@ops.ietf.org] On Behalf Of BRUNGARD, DEBORAH = A,=20 ATTLABS
Sent: Tuesday, January 22, 2008 2:28 PM
To:=20 ccamp@ops.ietf.org
Subject: Proposed WG Draft -=20 draft-gmpls-ethernet-arch-00.txt

CCAMP,
 
The DT = proposed in=20 their meeting presentation for their architecture and framework=20 document to be accepted as a WG = draft:
http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt=
 
We = received a couple=20 of comments in the meeting, we would appreciate additional = feedback on=20 the list. Please express your support (or otherwise) for this I-D to = become a WG=20 draft.
 
Thanks,
Deborah
------_=_NextPart_001_01C85DC4.129C2CE7-- From owner-ccamp@ops.ietf.org Wed Jan 23 09:58:59 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHh47-00081F-FM for ccamp-archive@ietf.org; Wed, 23 Jan 2008 09:58:59 -0500 Received: from psg.com ([2001:418:1::62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHh45-000125-5f for ccamp-archive@ietf.org; Wed, 23 Jan 2008 09:58:59 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JHgtU-000GTr-Cc for ccamp-data@psg.com; Wed, 23 Jan 2008 14:48:00 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE, RDNS_NONE autolearn=no version=3.2.3 Received: from [47.140.192.56] (helo=zrtps0kp.nortel.com) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JHgtR-000GSE-6z for ccamp@ops.ietf.org; Wed, 23 Jan 2008 14:47:58 +0000 Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m0NElmd18861; Wed, 23 Jan 2008 14:47:48 GMT 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_01C85DCE.E3F56E52" Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Date: Wed, 23 Jan 2008 09:47:48 -0500 Message-ID: <085091CB2CA14E4B8B163FFC37C84E9D1355B715@zcarhxm0.corp.nortel.com> In-Reply-To: <449B2580D802A443A923DABF3EAB82AF10132C78@OCCLUST04EVS1.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Thread-Index: AchdLOH3JrqySZgzQVuueGk7Nk+CoAAogWTA References: <449B2580D802A443A923DABF3EAB82AF10132C78@OCCLUST04EVS1.ugd.att.com> From: "Hamid Ould-Brahim" To: "BRUNGARD, DEBORAH A, ATTLABS" , Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e This is a multi-part message in MIME format. ------_=_NextPart_001_01C85DCE.E3F56E52 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In favor. =20 Hamid. ________________________________ From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of BRUNGARD, DEBORAH A, ATTLABS Sent: Tuesday, January 22, 2008 2:28 PM To: ccamp@ops.ietf.org Subject: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt =09 =09 CCAMP, =20 The DT proposed in their meeting presentation for their architecture and framework document to be accepted as a WG draft: =09 http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt =20 We received a couple of comments in the meeting, we would appreciate additional feedback on the list. Please express your support (or otherwise) for this I-D to become a WG draft. =20 Thanks, Deborah ------_=_NextPart_001_01C85DCE.E3F56E52 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
In favor.
 
Hamid.

From: owner-ccamp@ops.ietf.org=20 [mailto:owner-ccamp@ops.ietf.org] On Behalf Of BRUNGARD, = DEBORAH A,=20 ATTLABS
Sent: Tuesday, January 22, 2008 2:28 = PM
To:=20 ccamp@ops.ietf.org
Subject: Proposed WG Draft -=20 draft-gmpls-ethernet-arch-00.txt

CCAMP,
 
The = DT proposed in=20 their meeting presentation for their architecture and framework=20 document to be accepted as a WG = draft:
http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt=
 
We = received a=20 couple of comments in the meeting, we would appreciate additional = feedback on the list. Please express your support (or otherwise) = for this=20 I-D to become a WG draft.
 
Thanks,
Deborah
------_=_NextPart_001_01C85DCE.E3F56E52-- From owner-ccamp@ops.ietf.org Wed Jan 23 10:21:01 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHhPR-0007yw-Jr for ccamp-archive@ietf.org; Wed, 23 Jan 2008 10:21:01 -0500 Received: from psg.com ([2001:418:1::62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHhPP-0001je-PY for ccamp-archive@ietf.org; Wed, 23 Jan 2008 10:21:01 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JHhHq-000JPO-LC for ccamp-data@psg.com; Wed, 23 Jan 2008 15:13:10 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE, RDNS_NONE autolearn=no version=3.2.3 Received: from [66.226.64.2] (helo=pro.abac.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JHhHn-000JP4-R1 for ccamp@ops.ietf.org; Wed, 23 Jan 2008 15:13:09 +0000 Received: from [192.168.0.131] (c-71-202-41-42.hsd1.ca.comcast.net [71.202.41.42]) (authenticated bits=0) by pro.abac.com (8.14.1/8.14.1) with ESMTP id m0NFCsbO071323 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Jan 2008 07:12:59 -0800 (PST) (envelope-from gregb@grotto-networking.com) Message-ID: <47975978.60508@grotto-networking.com> Date: Wed, 23 Jan 2008 07:12:56 -0800 From: Greg Bernstein User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "BRUNGARD, DEBORAH A, ATTLABS" CC: ccamp@ops.ietf.org Subject: Re: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt References: <449B2580D802A443A923DABF3EAB82AF10132C78@OCCLUST04EVS1.ugd.att.com> In-Reply-To: <449B2580D802A443A923DABF3EAB82AF10132C78@OCCLUST04EVS1.ugd.att.com> Content-Type: multipart/alternative; boundary="------------020605090909000502090101" Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 This is a multi-part message in MIME format. --------------020605090909000502090101 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit In favor. Regards Greg B. BRUNGARD, DEBORAH A, ATTLABS wrote: > CCAMP, > > The DT proposed in their meeting presentation for their architecture > and framework document to be accepted as a WG draft: > http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt > > We received a couple of comments in the meeting, we would appreciate > additional feedback on the list. Please express your support (or > otherwise) for this I-D to become a WG draft. > > Thanks, > Deborah -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 --------------020605090909000502090101 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit In favor.
Regards

Greg B.

BRUNGARD, DEBORAH A, ATTLABS wrote:
CCAMP,
 
The DT proposed in their meeting presentation for their architecture and framework document to be accepted as a WG draft:
 
We received a couple of comments in the meeting, we would appreciate additional feedback on the list. Please express your support (or otherwise) for this I-D to become a WG draft.
 
Thanks,
Deborah

-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237
--------------020605090909000502090101-- From ccampan.s@nyls.edu Wed Jan 23 16:26:59 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHn7b-00034L-MF for ccamp-archive@ietf.org; Wed, 23 Jan 2008 16:26:59 -0500 Received: from [82.179.199.194] (helo=123-6f667da8f89) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JHn7a-0002T4-C1 for ccamp-archive@ietf.org; Wed, 23 Jan 2008 16:26:59 -0500 Content-Return: allowed X-Mailer: CME-V6.5.4.3; MSN Received: (qmail 6089 by uid 326); Thu, 24 Jan 2008 12:26:58 +0300 Message-Id: <20080124152658.6091.qmail@123-6f667da8f89> To: Subject: January eNews: Start the Year With % 45 Off From: MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 4.7 (++++) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a
Click Here!
About this mailing:
You are receiving this e-mail because you subscribed to Featured Offers. We respect your privacy. If you do not wish to receive this Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in Feature Offers. This shall not constitute an offer. We shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

©2007 Unsubscribe | More Newsletters | Privacy

Corporation, One Way, Redmond, WA 98052
From owner-ccamp@ops.ietf.org Wed Jan 23 17:43:04 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHoJE-0003Zf-N2 for ccamp-archive@ietf.org; Wed, 23 Jan 2008 17:43:04 -0500 Received: from psg.com ([2001:418:1::62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHoJD-0001u0-7k for ccamp-archive@ietf.org; Wed, 23 Jan 2008 17:43:04 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JHo8X-000HwP-AQ for ccamp-data@psg.com; Wed, 23 Jan 2008 22:32:01 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [64.233.184.238] (helo=wr-out-0506.google.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JHo7l-000HsW-81 for ccamp@ops.ietf.org; Wed, 23 Jan 2008 22:31:51 +0000 Received: by wr-out-0506.google.com with SMTP id 60so1818726wri.8 for ; Wed, 23 Jan 2008 14:31:12 -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=PTGHQT6s3V1WCcbXKgzjSYtuFzyzr4o+ZxIxHrpl3vs=; b=P75sE66oG7b1VgW6y2Ff24uVo2glYfuxWdAru3x1HEUnugjBxiRgWFWMpz3SjPupEK6yP+0YF0IK/K0mnWzf2i6u7PJFFk/tKSkGehP9MCpIJRjLyFpC85aB5TcmZaaDEuAnbKmIMXoADL1eOGYm2N5+CYHHJd+XQmRSB8hA62k= 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=AQhT6pzQPBFJH7sYU1yHgGVdbKkYWDxv/w0AO43AXb1xTYKA1A0mcAgXf3jMUY8reSv3IurZRhA7JrPATi39sk362+jvXpka/vdciXKKop1Mr74TocMW1MPGQHRR75QBjIowWrG/KWQ1HYKM6DG5qlC0vKZU8X5gb3XbRajj0I8= Received: by 10.150.57.5 with SMTP id f5mr3766155yba.140.1201127470673; Wed, 23 Jan 2008 14:31:10 -0800 (PST) Received: by 10.151.27.4 with HTTP; Wed, 23 Jan 2008 14:31:10 -0800 (PST) Message-ID: <8c99930d0801231431h6c573bf6x63fa7cca3a4333ea@mail.gmail.com> Date: Wed, 23 Jan 2008 17:31:10 -0500 From: "Andrew G. Malis" To: ccamp@ops.ietf.org Subject: Re: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Cc: "BRUNGARD, DEBORAH A, ATTLABS" In-Reply-To: <47975978.60508@grotto-networking.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <449B2580D802A443A923DABF3EAB82AF10132C78@OCCLUST04EVS1.ugd.att.com> <47975978.60508@grotto-networking.com> Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Also in favor. Cheers, Andy > BRUNGARD, DEBORAH A, ATTLABS wrote: > CCAMP, > > The DT proposed in their meeting presentation for their architecture and > framework document to be accepted as a WG draft: > http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt > > We received a couple of comments in the meeting, we would appreciate > additional feedback on the list. Please express your support (or otherwise) > for this I-D to become a WG draft. > > Thanks, > Deborah From owner-ccamp@ops.ietf.org Wed Jan 23 19:12:07 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHphP-0002TA-5s for ccamp-archive@ietf.org; Wed, 23 Jan 2008 19:12:07 -0500 Received: from psg.com ([2001:418:1::62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHphM-0004gM-Qj for ccamp-archive@ietf.org; Wed, 23 Jan 2008 19:12:07 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JHpaW-0000il-Cq for ccamp-data@psg.com; Thu, 24 Jan 2008 00:05:00 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [64.208.49.5] (helo=smail6.alcatel.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JHpaS-0000hM-L8 for ccamp@ops.ietf.org; Thu, 24 Jan 2008 00:04:58 +0000 Received: from FRVELSBHS03.ad2.ad.alcatel.com (frvelsbhs03.ad2.ad.alcatel.com [155.132.6.75]) by smail6.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id m0O02RrA009792; Thu, 24 Jan 2008 01:02:28 +0100 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.51]) by FRVELSBHS03.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Thu, 24 Jan 2008 01:04:35 +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: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Date: Thu, 24 Jan 2008 01:04:33 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Thread-Index: AchdVFu8AEzlezFGRoK1wWa//yCoRwAwWYeA References: <449B2580D802A443A923DABF3EAB82AF10132C78@OCCLUST04EVS1.ugd.att.com> <34B3EAA5B3066A42914D28C5ECF5FEA41340D7D1@zrtphxm2.corp.nortel.com> <200801222228.m0MMRxVa004316@mailgate4.alcatel.fr> From: "PAPADIMITRIOU Dimitri" To: "Lou Berger" Cc: "Don Fedyk" , "BRUNGARD, DEBORAH A, ATTLABS" , X-OriginalArrivalTime: 24 Jan 2008 00:04:35.0508 (UTC) FILETIME=[B42E2F40:01C85E1C] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.84 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 5fb88b8381f3896aeacc5a021513237b the question triggered by this poll is the following: if GMPLS for Ethernet is not inline with the existing stacks what is the value of GMPLS re-use ? what's the value to borrow the term GMPLS without its substance ? and in practice, the issue is, if it is not GMPLS per RFC 3945, what's the value compared to any other native control stack that would be developed at IEEE for inst. for these techno's. you quote: > L2SC was always underspecified (e.g., covers both ATM and Ether), additional specification does not result in departing from the initial definition but refinement of the initial definition (definition of a sub-set not a side definition). probably the document is not mature enough to respond to the tie-breaker: what about the FIT of GMPLS for Ethernet but not within the L2SC space (as defined today) ? but in the meantime preclude any allowed use of GMPLS per IETF RFCs to Ethernet if they do not comply with a new WG i-d would create a precedent in the history of this WG with really disastrous impact (including on other application of GMPLS) we're at a turning point (equivalent to RSVP vs RSVP-TE). we need to assess consequences before going one way or another and under which conditions. -d. > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Lou Berger > Sent: Wednesday, January 23, 2008 1:09 AM > To: PAPADIMITRIOU Dimitri > Cc: Lou Berger; Don Fedyk; BRUNGARD, DEBORAH A, ATTLABS;=20 > ccamp@ops.ietf.org > Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt >=20 > We've always had different switching type/capability in=20 > GMPLS. Nothing new here. >=20 > L2SC was always underspecified (e.g., covers both ATM and Ether), is=20 > currently used by some for different purposes, and doesn't allow=20 > unique identification of switching capabilities of an interface. I=20 > *really* don't see the unique identification of an interface's=20 > Ethernet switching function as any different from what is done for=20 > today for the other types or as any big deal or change in GMPLS=20 > direction or architecture. >=20 > but, that's just my perspective. >=20 > Lou >=20 > At 05:44 PM 1/22/2008, PAPADIMITRIOU Dimitri wrote: > >thus the question is whether or not to ask for a change CCAMP "common > >control" in DCAMP "differentiated control" per technology ? > > > >we never have had a techno inducing a base building block=20 > change (GMPLS > >being a generalisation of MPLS-TE). i'm afraid that generalized LSP, > >generalized LSR, generalized label, etc. per GMPLS arch (RFC=20 > 3945) would > >simply be unapplicable as known today and thus the corr.=20 > base protocol > >specs unapplicable. at the end the term "GMPLS" would be=20 > emptied of any > >real substance. > > > >it's a choice but let's ask the questions from the right perspective. > > > >-d. > > > > > -----Original Message----- > > > From: Lou Berger [mailto:lberger@labn.net] > > > Sent: Tuesday, January 22, 2008 11:28 PM > > > To: PAPADIMITRIOU Dimitri > > > Cc: Lou Berger; Don Fedyk; BRUNGARD, DEBORAH A, ATTLABS; > > > ccamp@ops.ietf.org > > > Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt > > > > > > I have no objection to adding "Updates: 3945" to the=20 > document header > > > and matching 3945's category. > > > > > > Lou > > > > > > At 05:11 PM 1/22/2008, PAPADIMITRIOU Dimitri wrote: > > > >Lou > > > > > > > >what i am concerned with: is that the doc extends > > > applicability of GMPLS > > > >to Ethernet by excluding GMPLS for Ethernet per RFC 3945=20 > ? does that > > > >make sense ? > > > > > > > >what's needed instead of hiding behind terms is to state=20 > GMPLS for Y, > > > >where Y includes the set of Ethernet-based techno's under > > > development at > > > >places as indicated in the doc itself. instead of=20 > inducing by a title > > > >such as "GMPLS for Ethernet" that this doc supersedes any > > > previous work > > > >in that > > > >space. > > > > > > > >-d. > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: owner-ccamp@ops.ietf.org > > > > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Lou Berger > > > > > Sent: Tuesday, January 22, 2008 10:50 PM > > > > > To: Don Fedyk > > > > > Cc: PAPADIMITRIOU Dimitri; BRUNGARD, DEBORAH A, ATTLABS; > > > > > ccamp@ops.ietf.org > > > > > Subject: RE: Proposed WG Draft -=20 > draft-gmpls-ethernet-arch-00.txt > > > > > > > > > > Don, > > > > > I agree 100%. Furthermore there is no=20 > statement in the > > > > > draft that 3945 doesn't apply, in fact it explicitly=20 > says just the > > > > > opposite. The reason for the statement in question is > > > simply as you > > > > > say, and to ensure full ETH-LSP definition and interoperable > > > > > operation a new switching type/capability is required. > > > > > > > > > > It's really not such a bid deal or major change. > > > > > > > > > > Lou > > > > > > > > > > At 04:34 PM 1/22/2008, Don Fedyk wrote: > > > > > >Hi Dimitri > > > > > > > > > > > >The text you quote was put in the architecture/=20 > framework, not to > > > > > >exclude L2 Switch Capable (L2SC) but to prevent redefining > > > > > L2SC, which > > > > > >has been there for many years and may be in use. > > > > > > > > > > > >Perhaps the working needs to be adjusted but I don't think > > > > > it is a major > > > > > >issue. > > > > > > > > > > > >Regards, > > > > > >Don > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: owner-ccamp@ops.ietf.org > > > > > > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of > > > > > PAPADIMITRIOU Dimitri > > > > > > > Sent: Tuesday, January 22, 2008 4:16 PM > > > > > > > To: BRUNGARD, DEBORAH A, ATTLABS; ccamp@ops.ietf.org > > > > > > > Subject: RE: Proposed WG Draft - > > > draft-gmpls-ethernet-arch-00.txt > > > > > > > > > > > > > > All, > > > > > > > > > > > > > > > We received a couple of comments in the=20 > meeting, we would > > > > > > > > appreciate additional feedback on the list. > > > > > > > > > > > > > > The document states: > > > > > > > > > > > > > > "The L2SC Interface Switching Capabilities MUST=20 > NOT be used > > > > > > > to represent > > > > > > > interfaces capable of supporting Eth-LSPs.=20 > Interface Switching > > > > > > > Capability specific TE information may be defined as > > > > > needed to support > > > > > > > the requirements of a specific Ethernet Switching > > > Service Type." > > > > > > > > > > > > > > [...] > > > > > > > > > > > > > > "It is expected that there will be no case where an > > > > > Eth-LSP will be > > > > > > > signaled, or an Eth-LSP supporting interface will be > > > > > > > represented, using > > > > > > > the L2SC switching type/capability. A new switching > > > > > type/capability is > > > > > > > required to avoid any potential current usage of the L2SC > > > > > switching > > > > > > > type/capability in support of Ethernet." > > > > > > > > > > > > > > This is explicit statement that GMPLS per RFC 3945 is not > > > > > applicable. > > > > > > > So, it is much more than just an additional codepoint, as > > > > > the control > > > > > > > plane behaviour is to be defined for this=20 > codepoint. So, it > > > > > > > is the open > > > > > > > door for a new control plane behaviour. > > > > > > > > > > > > > > so, let's have a more basic questioning before jumping > > > > > into the single > > > > > > > alternative resulting from this doc.: > > > > > > > > > > > > > > - either it is GMPLS for Ethernet architecture and then > > > > > what exist in > > > > > > > current RFCs should be applicable (because i do not see > > > > > any rationale > > > > > > > for L2SC def. departure for Ethernet frame processing); > > > > > > > > > > > > > > - or not it is X for Y architecture, where X is an IP > > > > > control protocol > > > > > > > based some potentially on some existing GMPLS blocks > > > and Y is not > > > > > > > compatible with the existing definition of Eth frame > > > processing. > > > > > > > > > > > > > > In the latter case, i do not know how this WG can deal > > > > > with such case > > > > > > > (from the control plane perspective). > > > > > > > > > > > > > > -d. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: owner-ccamp@ops.ietf.org > > > > > > > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of BRUNGARD, > > > > > > > > DEBORAH A, ATTLABS > > > > > > > > Sent: Tuesday, January 22, 2008 8:28 PM > > > > > > > > To: ccamp@ops.ietf.org > > > > > > > > Subject: Proposed WG Draft - > > > draft-gmpls-ethernet-arch-00.txt > > > > > > > > > > > > > > > > CCAMP, > > > > > > > > > > > > > > > > The DT proposed in their meeting presentation for their > > > > > > > > architecture and framework document to be accepted as a > > > > > WG draft: > > > > > > > > > > > > > > > >=20 > http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt > > > > > > > > > > > > > > > > We received a couple of comments in the=20 > meeting, we would > > > > > > > > appreciate additional feedback on the list.=20 > Please express > > > > > > > > your support (or otherwise) for this I-D to become > > > a WG draft. > > > > > > > > > > > > > > > > Thanks, > > > > > > > > Deborah > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=20 >=20 >=20 From nwedirectory@murrfood.com Wed Jan 23 21:56:22 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHsGL-0007Gu-IK for ccamp-archive@ietf.org; Wed, 23 Jan 2008 21:56:22 -0500 Received: from [124.82.31.66] (helo=82.124.in-addr.arpa.tm.net.my) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JHsGK-0003du-2r for ccamp-archive@ietf.org; Wed, 23 Jan 2008 21:56:20 -0500 Received: from rw02 ([65.169.192.248]:47910 "HELO rw02" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by 421f527cmurrfood.com with ESMTP id k1OJVGZA714158 (ORCPT ); Thu, 24 Jan 2008 10:56:23 +0800 Message-ID: <001701c85e77$c273fe80$061ce1dc@rw02> From: Colette To: ccamp-archive@ietf.org Subject: is aware Date: Thu, 24 Jan 2008 10:56:23 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0014_01C85E77.C273FE80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.181 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2600.181 X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb This is a multi-part message in MIME format. ------=_NextPart_000_0014_01C85E77.C273FE80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable better for the intellectual growth - and even motor skills than consider bad would of course be good to somebody else and even my the progr= am and the creative abilities of the artist monitoring ------=_NextPart_000_0014_01C85E77.C273FE80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
better for the intellectual growth - and even motor skills than
<= BR>
V I 4A G R A - $1.44
C 0I L I S - $2.27
S3 O M A - $0.61
L E2 V I T R A - $3.63
FEMALE V 5I A G R A
127 Items on S /AL \E Today.

great technological advancements and now we're at a threshold.
------=_NextPart_000_0014_01C85E77.C273FE80-- From owner-ccamp@ops.ietf.org Wed Jan 23 21:59:30 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHsJO-0000m6-15 for ccamp-archive@ietf.org; Wed, 23 Jan 2008 21:59:30 -0500 Received: from psg.com ([2001:418:1::62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHsJM-0007Zl-FI for ccamp-archive@ietf.org; Wed, 23 Jan 2008 21:59:30 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JHsBb-000I7G-0U for ccamp-data@psg.com; Thu, 24 Jan 2008 02:51:27 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [47.140.192.56] (helo=zrtps0kp.nortel.com) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JHsBX-000I6v-Pz for ccamp@ops.ietf.org; Thu, 24 Jan 2008 02:51:25 +0000 Received: from zrtphxm2.corp.nortel.com (zrtphxm2.corp.nortel.com [47.140.202.51]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m0O2pDx08147; Thu, 24 Jan 2008 02:51:13 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: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Date: Wed, 23 Jan 2008 21:51:11 -0500 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA41349EF98@zrtphxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Thread-Index: AchdVFu8AEzlezFGRoK1wWa//yCoRwAwWYeAAAbEl1A= References: <449B2580D802A443A923DABF3EAB82AF10132C78@OCCLUST04EVS1.ugd.att.com> <34B3EAA5B3066A42914D28C5ECF5FEA41340D7D1@zrtphxm2.corp.nortel.com> <200801222228.m0MMRxVa004316@mailgate4.alcatel.fr> From: "Don Fedyk" To: "PAPADIMITRIOU Dimitri" , "Lou Berger" Cc: "BRUNGARD, DEBORAH A, ATTLABS" , Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 9e5c23589e6cce06555030c0194c9e2b Hi Dimitri The document clearly states: "The intent of this document is to reuse and align with as much of the GMPLS protocols as possible. For example reusing the IP control plane addressing allows the existing signaling, routing, LMP and path computation to be used as specified. Additions are made only to accommodate features of Ethernet that are not already supported by GMPLS. The GMPLS protocols support a set of tools for hierarchical LSPs as well as contiguous LSPs. GMPLS specific protocol mechanisms support a variety of networks from peer to peer to UNIs and NNIs." So your question comes down to why we make the statement on L2SC? Like Lou said when we discussed this we thought that L2SC came with baggage and was not precise. The switching capabilities would be specified in documents that address the particular Ethernet data plane. It is true that if there was a valid Ethernet data plane that could use L2SC unambiguously it should fit under the architecture. At any rate getting this right is something that can be accomplished when this is a WG draft.=20 Regards, Don=20 > -----Original Message----- > From: PAPADIMITRIOU Dimitri=20 > [mailto:Dimitri.Papadimitriou@alcatel-lucent.be]=20 > Sent: Wednesday, January 23, 2008 7:05 PM > To: Lou Berger > Cc: Fedyk, Don (BL60:1A00); BRUNGARD, DEBORAH A, ATTLABS;=20 > ccamp@ops.ietf.org > Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt >=20 > the question triggered by this poll is the following: if GMPLS for > Ethernet is not inline with the existing stacks what is the value of > GMPLS re-use ? what's the value to borrow the term GMPLS without its > substance ? and in practice, the issue is, if it is not GMPLS per RFC > 3945, what's the value compared to any other native control stack that > would be developed at IEEE for inst. for these techno's. >=20 > you quote: >=20 > > L2SC was always underspecified (e.g., covers both ATM and Ether), >=20 > additional specification does not result in departing from the initial > definition but refinement of the initial definition (definition of a > sub-set not a side definition). >=20 > probably the document is not mature enough to respond to the > tie-breaker: what about the FIT of GMPLS for Ethernet but not=20 > within the > L2SC space (as defined today) ? but in the meantime preclude=20 > any allowed > use of GMPLS per IETF RFCs to Ethernet if they do not comply=20 > with a new > WG i-d would create a precedent in the history of this WG with really > disastrous impact (including on other application of GMPLS) >=20 > we're at a turning point (equivalent to RSVP vs RSVP-TE). we need to > assess consequences before going one way or another and under which > conditions. >=20 > -d. >=20 > > -----Original Message----- > > From: owner-ccamp@ops.ietf.org=20 > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Lou Berger > > Sent: Wednesday, January 23, 2008 1:09 AM > > To: PAPADIMITRIOU Dimitri > > Cc: Lou Berger; Don Fedyk; BRUNGARD, DEBORAH A, ATTLABS;=20 > > ccamp@ops.ietf.org > > Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt > >=20 > > We've always had different switching type/capability in=20 > > GMPLS. Nothing new here. > >=20 > > L2SC was always underspecified (e.g., covers both ATM and=20 > Ether), is=20 > > currently used by some for different purposes, and doesn't allow=20 > > unique identification of switching capabilities of an interface. I=20 > > *really* don't see the unique identification of an interface's=20 > > Ethernet switching function as any different from what is done for=20 > > today for the other types or as any big deal or change in GMPLS=20 > > direction or architecture. > >=20 > > but, that's just my perspective. > >=20 > > Lou > >=20 > > At 05:44 PM 1/22/2008, PAPADIMITRIOU Dimitri wrote: > > >thus the question is whether or not to ask for a change=20 > CCAMP "common > > >control" in DCAMP "differentiated control" per technology ? > > > > > >we never have had a techno inducing a base building block=20 > > change (GMPLS > > >being a generalisation of MPLS-TE). i'm afraid that=20 > generalized LSP, > > >generalized LSR, generalized label, etc. per GMPLS arch (RFC=20 > > 3945) would > > >simply be unapplicable as known today and thus the corr.=20 > > base protocol > > >specs unapplicable. at the end the term "GMPLS" would be=20 > > emptied of any > > >real substance. > > > > > >it's a choice but let's ask the questions from the right=20 > perspective. > > > > > >-d. > > > > > > > -----Original Message----- > > > > From: Lou Berger [mailto:lberger@labn.net] > > > > Sent: Tuesday, January 22, 2008 11:28 PM > > > > To: PAPADIMITRIOU Dimitri > > > > Cc: Lou Berger; Don Fedyk; BRUNGARD, DEBORAH A, ATTLABS; > > > > ccamp@ops.ietf.org > > > > Subject: RE: Proposed WG Draft -=20 > draft-gmpls-ethernet-arch-00.txt > > > > > > > > I have no objection to adding "Updates: 3945" to the=20 > > document header > > > > and matching 3945's category. > > > > > > > > Lou > > > > > > > > At 05:11 PM 1/22/2008, PAPADIMITRIOU Dimitri wrote: > > > > >Lou > > > > > > > > > >what i am concerned with: is that the doc extends > > > > applicability of GMPLS > > > > >to Ethernet by excluding GMPLS for Ethernet per RFC 3945=20 > > ? does that > > > > >make sense ? > > > > > > > > > >what's needed instead of hiding behind terms is to state=20 > > GMPLS for Y, > > > > >where Y includes the set of Ethernet-based techno's under > > > > development at > > > > >places as indicated in the doc itself. instead of=20 > > inducing by a title > > > > >such as "GMPLS for Ethernet" that this doc supersedes any > > > > previous work > > > > >in that > > > > >space. > > > > > > > > > >-d. > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: owner-ccamp@ops.ietf.org > > > > > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Lou Berger > > > > > > Sent: Tuesday, January 22, 2008 10:50 PM > > > > > > To: Don Fedyk > > > > > > Cc: PAPADIMITRIOU Dimitri; BRUNGARD, DEBORAH A, ATTLABS; > > > > > > ccamp@ops.ietf.org > > > > > > Subject: RE: Proposed WG Draft -=20 > > draft-gmpls-ethernet-arch-00.txt > > > > > > > > > > > > Don, > > > > > > I agree 100%. Furthermore there is no=20 > > statement in the > > > > > > draft that 3945 doesn't apply, in fact it explicitly=20 > > says just the > > > > > > opposite. The reason for the statement in question is > > > > simply as you > > > > > > say, and to ensure full ETH-LSP definition and interoperable > > > > > > operation a new switching type/capability is required. > > > > > > > > > > > > It's really not such a bid deal or major change. > > > > > > > > > > > > Lou > > > > > > > > > > > > At 04:34 PM 1/22/2008, Don Fedyk wrote: > > > > > > >Hi Dimitri > > > > > > > > > > > > > >The text you quote was put in the architecture/=20 > > framework, not to > > > > > > >exclude L2 Switch Capable (L2SC) but to prevent redefining > > > > > > L2SC, which > > > > > > >has been there for many years and may be in use. > > > > > > > > > > > > > >Perhaps the working needs to be adjusted but I don't think > > > > > > it is a major > > > > > > >issue. > > > > > > > > > > > > > >Regards, > > > > > > >Don > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: owner-ccamp@ops.ietf.org > > > > > > > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of > > > > > > PAPADIMITRIOU Dimitri > > > > > > > > Sent: Tuesday, January 22, 2008 4:16 PM > > > > > > > > To: BRUNGARD, DEBORAH A, ATTLABS; ccamp@ops.ietf.org > > > > > > > > Subject: RE: Proposed WG Draft - > > > > draft-gmpls-ethernet-arch-00.txt > > > > > > > > > > > > > > > > All, > > > > > > > > > > > > > > > > > We received a couple of comments in the=20 > > meeting, we would > > > > > > > > > appreciate additional feedback on the list. > > > > > > > > > > > > > > > > The document states: > > > > > > > > > > > > > > > > "The L2SC Interface Switching Capabilities MUST=20 > > NOT be used > > > > > > > > to represent > > > > > > > > interfaces capable of supporting Eth-LSPs.=20 > > Interface Switching > > > > > > > > Capability specific TE information may be defined as > > > > > > needed to support > > > > > > > > the requirements of a specific Ethernet Switching > > > > Service Type." > > > > > > > > > > > > > > > > [...] > > > > > > > > > > > > > > > > "It is expected that there will be no case where an > > > > > > Eth-LSP will be > > > > > > > > signaled, or an Eth-LSP supporting interface will be > > > > > > > > represented, using > > > > > > > > the L2SC switching type/capability. A new switching > > > > > > type/capability is > > > > > > > > required to avoid any potential current usage=20 > of the L2SC > > > > > > switching > > > > > > > > type/capability in support of Ethernet." > > > > > > > > > > > > > > > > This is explicit statement that GMPLS per RFC=20 > 3945 is not > > > > > > applicable. > > > > > > > > So, it is much more than just an additional=20 > codepoint, as > > > > > > the control > > > > > > > > plane behaviour is to be defined for this=20 > > codepoint. So, it > > > > > > > > is the open > > > > > > > > door for a new control plane behaviour. > > > > > > > > > > > > > > > > so, let's have a more basic questioning before jumping > > > > > > into the single > > > > > > > > alternative resulting from this doc.: > > > > > > > > > > > > > > > > - either it is GMPLS for Ethernet architecture and then > > > > > > what exist in > > > > > > > > current RFCs should be applicable (because i do not see > > > > > > any rationale > > > > > > > > for L2SC def. departure for Ethernet frame processing); > > > > > > > > > > > > > > > > - or not it is X for Y architecture, where X is an IP > > > > > > control protocol > > > > > > > > based some potentially on some existing GMPLS blocks > > > > and Y is not > > > > > > > > compatible with the existing definition of Eth frame > > > > processing. > > > > > > > > > > > > > > > > In the latter case, i do not know how this WG can deal > > > > > > with such case > > > > > > > > (from the control plane perspective). > > > > > > > > > > > > > > > > -d. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: owner-ccamp@ops.ietf.org > > > > > > > > > [mailto:owner-ccamp@ops.ietf.org] On Behalf=20 > Of BRUNGARD, > > > > > > > > > DEBORAH A, ATTLABS > > > > > > > > > Sent: Tuesday, January 22, 2008 8:28 PM > > > > > > > > > To: ccamp@ops.ietf.org > > > > > > > > > Subject: Proposed WG Draft - > > > > draft-gmpls-ethernet-arch-00.txt > > > > > > > > > > > > > > > > > > CCAMP, > > > > > > > > > > > > > > > > > > The DT proposed in their meeting presentation=20 > for their > > > > > > > > > architecture and framework document to be=20 > accepted as a > > > > > > WG draft: > > > > > > > > > > > > > > > > > > >=20 > > http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt > > > > > > > > > > > > > > > > > > We received a couple of comments in the=20 > > meeting, we would > > > > > > > > > appreciate additional feedback on the list.=20 > > Please express > > > > > > > > > your support (or otherwise) for this I-D to become > > > > a WG draft. > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > Deborah > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=20 > >=20 > >=20 >=20 From reidyykriv@truffle.unanimity.com Thu Jan 24 00:36:39 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHulT-00026y-PM for ccamp-archive@ietf.org; Thu, 24 Jan 2008 00:36:39 -0500 Received: from [213.210.227.42] (helo=[212.71.32.88]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JHulT-0006tH-13 for ccamp-archive@ietf.org; Thu, 24 Jan 2008 00:36:39 -0500 Received: from ajit ([153.185.104.45] helo=ajit) by [212.71.32.88] ( sendmail 8.13.3/8.13.1) with esmtpa id 1hVOUr-000TMA-bf for ccamp-archive@ietf.org; Thu, 24 Jan 2008 11:00:24 +05-30 Message-ID: <000c01c85e4a$21869c80$582047d4@ajit> From: "Gradi reidy" To: Subject: kihorud Date: Thu, 24 Jan 2008 10:59:46 +05-30 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C85E78.3B3ED880" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 3.7 (+++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ------=_NextPart_000_0009_01C85E78.3B3ED880 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi there ccamp-archive you can buy quality pharm for less money http://simplepick.com Gradi reidy ------=_NextPart_000_0009_01C85E78.3B3ED880 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi there ccamp-archive
you can buy quality pharm for less = money
http://simplepick.com
Gradi reidy
------=_NextPart_000_0009_01C85E78.3B3ED880-- From 0477347vjeg@silvanamaria.com.br Thu Jan 24 02:06:30 2008 Return-path: <0477347vjeg@silvanamaria.com.br> Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHwAP-0003by-VQ for ccamp-archive@megatron.ietf.org; Thu, 24 Jan 2008 02:06:29 -0500 Received: from eic136.neoplus.adsl.tpnet.pl ([83.21.118.136]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JHwAP-0000VB-Bz for ccamp-archive@megatron.ietf.org; Thu, 24 Jan 2008 02:06:29 -0500 Received: (qmail 70811 invoked from network); Thu, 24 Jan 2008 08:06:22 +0100 Received: from unknown (HELO silvanamaria.com.br) (31.137.246.30) by sanwaestate.com with SMTP; Thu, 24 Jan 2008 08:06:21 +0100 Received: from localhost.localdomain (ryder-wilcox.com [18.40.175.87]) by silvanamaria.com.br (8.13.1/8.13.1) with SMTP id JGGoXYVR207727 for ; Thu, 24 Jan 2008 08:06:20 +0100 Message-Id: <268177039379.JGGoXYVR207727@560466.ryder-wilcox.com> Received: from phpmailer ([127.0.0.1]) by ryder-wilcox.com with HTTP; Thu, 24 Jan 2008 08:06:20 +0100 Date: Thu, 24 Jan 2008 08:06:20 +0100 To: ccamp-archive@megatron.ietf.org From: "0477347" <0477347vjeg@silvanamaria.com.br> Subject: 0exclaim X-Priority: 3 X-Mailer: phpmailer [version 1.54] Reply-To: 0477347vjeg@silvanamaria.com.br MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset = "iso-8859-1" X-Spam-Score: 4.2 (++++) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 http://iirghaiea.com/ I love how I gained inches in just weeks, it was truly amazing From owner-ccamp@ops.ietf.org Thu Jan 24 03:35:15 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHxYJ-00087A-Uc for ccamp-archive@ietf.org; Thu, 24 Jan 2008 03:35:15 -0500 Received: from psg.com ([2001:418:1::62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JHxYH-0005bd-Ds for ccamp-archive@ietf.org; Thu, 24 Jan 2008 03:35:15 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JHxNN-000HIy-Qa for ccamp-data@psg.com; Thu, 24 Jan 2008 08:23:57 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [62.23.212.7] (helo=smail6.alcatel.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JHxNJ-000HHk-S4 for ccamp@ops.ietf.org; Thu, 24 Jan 2008 08:23:56 +0000 Received: from FRVELSBHS07.ad2.ad.alcatel.com (frvelsbhs07.ad2.ad.alcatel.com [155.132.6.79]) by smail6.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id m0O8LO5A013576; Thu, 24 Jan 2008 09:21:24 +0100 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.51]) by FRVELSBHS07.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Thu, 24 Jan 2008 09:23:23 +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: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Date: Thu, 24 Jan 2008 09:23:21 +0100 Message-ID: In-Reply-To: <34B3EAA5B3066A42914D28C5ECF5FEA41349EF98@zrtphxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Thread-Index: AchdVFu8AEzlezFGRoK1wWa//yCoRwAwWYeAAAbEl1AAC/YakA== References: <449B2580D802A443A923DABF3EAB82AF10132C78@OCCLUST04EVS1.ugd.att.com> <34B3EAA5B3066A42914D28C5ECF5FEA41340D7D1@zrtphxm2.corp.nortel.com> <200801222228.m0MMRxVa004316@mailgate4.alcatel.fr> <34B3EAA5B3066A42914D28C5ECF5FEA41349EF98@zrtphxm2.corp.nortel.com> From: "PAPADIMITRIOU Dimitri" To: "Don Fedyk" , "Lou Berger" Cc: "BRUNGARD, DEBORAH A, ATTLABS" , X-OriginalArrivalTime: 24 Jan 2008 08:23:23.0004 (UTC) FILETIME=[625BABC0:01C85E62] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.84 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: e95407604bef3289cd27cb4f3b3a35b4 Hi Don so, what's wrong with the definition of L2SC then ? from 3945: 2. Layer-2 Switch Capable (L2SC) interfaces: Interfaces that recognize frame/cell boundaries and can switch data based on the content of the frame/cell header. Examples include interfaces on Ethernet bridges that switch data based on the content of the MAC header and interfaces on ATM-LSRs that forward data based on the ATM VPI/VCI.=20 as such the statement "A new switching type/capability is required to avoid any potential current usage of the L2SC switching type/capability=20 in support of Ethernet." is made but never explained why in the doc - now coming down to the first sentence you indicated from your doc. "The intent of this document is to reuse and align with as much of the GMPLS protocols as possible.... Additions are made only to accommodate=20 features of Ethernet that are not already supported by GMPLS." It should have been something like: "This doc. details the GMPLS protocol suite architecture for Ethernet. Extensions are made only=20 to accommodate features of Ethernet that are not already supported=20 by GMPLS RFCs and inline with its architecture defined in RFC 3945." otherwise the result would be progressively that all GMPLS RFCs are cracked down to accommodate Ethernet. thanks, -d. > -----Original Message----- > From: Don Fedyk [mailto:dwfedyk@nortel.com]=20 > Sent: Thursday, January 24, 2008 3:51 AM > To: PAPADIMITRIOU Dimitri; Lou Berger > Cc: BRUNGARD, DEBORAH A, ATTLABS; ccamp@ops.ietf.org > Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt >=20 > Hi Dimitri >=20 > The document clearly states: >=20 > "The intent of this document is to reuse and align with as much of the > GMPLS protocols as possible. For example reusing the IP control > plane addressing allows the existing signaling, routing,=20 > LMP and path > computation to be used as specified. Additions are made only to > accommodate features of Ethernet that are not already supported by > GMPLS. The GMPLS protocols support a set of tools for hierarchical > LSPs as well as contiguous LSPs. GMPLS specific protocol mechanisms > support a variety of networks from peer to peer to UNIs and NNIs." >=20 > So your question comes down to why we make the statement on=20 > L2SC? Like > Lou said when we discussed this we thought that L2SC came with baggage > and was not precise. The switching capabilities would be specified in > documents that address the particular Ethernet data plane. It is true > that if there was a valid Ethernet data plane that could use L2SC > unambiguously it should fit under the architecture. At any=20 > rate getting > this right is something that can be accomplished when this is a WG > draft.=20 >=20 > Regards, > Don=20 >=20 >=20 >=20 > > -----Original Message----- > > From: PAPADIMITRIOU Dimitri=20 > > [mailto:Dimitri.Papadimitriou@alcatel-lucent.be]=20 > > Sent: Wednesday, January 23, 2008 7:05 PM > > To: Lou Berger > > Cc: Fedyk, Don (BL60:1A00); BRUNGARD, DEBORAH A, ATTLABS;=20 > > ccamp@ops.ietf.org > > Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt > >=20 > > the question triggered by this poll is the following: if GMPLS for > > Ethernet is not inline with the existing stacks what is the value of > > GMPLS re-use ? what's the value to borrow the term GMPLS without its > > substance ? and in practice, the issue is, if it is not=20 > GMPLS per RFC > > 3945, what's the value compared to any other native control=20 > stack that > > would be developed at IEEE for inst. for these techno's. > >=20 > > you quote: > >=20 > > > L2SC was always underspecified (e.g., covers both ATM and Ether), > >=20 > > additional specification does not result in departing from=20 > the initial > > definition but refinement of the initial definition (definition of a > > sub-set not a side definition). > >=20 > > probably the document is not mature enough to respond to the > > tie-breaker: what about the FIT of GMPLS for Ethernet but not=20 > > within the > > L2SC space (as defined today) ? but in the meantime preclude=20 > > any allowed > > use of GMPLS per IETF RFCs to Ethernet if they do not comply=20 > > with a new > > WG i-d would create a precedent in the history of this WG=20 > with really > > disastrous impact (including on other application of GMPLS) > >=20 > > we're at a turning point (equivalent to RSVP vs RSVP-TE). we need to > > assess consequences before going one way or another and under which > > conditions. > >=20 > > -d. > >=20 > > > -----Original Message----- > > > From: owner-ccamp@ops.ietf.org=20 > > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Lou Berger > > > Sent: Wednesday, January 23, 2008 1:09 AM > > > To: PAPADIMITRIOU Dimitri > > > Cc: Lou Berger; Don Fedyk; BRUNGARD, DEBORAH A, ATTLABS;=20 > > > ccamp@ops.ietf.org > > > Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt > > >=20 > > > We've always had different switching type/capability in=20 > > > GMPLS. Nothing new here. > > >=20 > > > L2SC was always underspecified (e.g., covers both ATM and=20 > > Ether), is=20 > > > currently used by some for different purposes, and doesn't allow=20 > > > unique identification of switching capabilities of an=20 > interface. I=20 > > > *really* don't see the unique identification of an interface's=20 > > > Ethernet switching function as any different from what is=20 > done for=20 > > > today for the other types or as any big deal or change in GMPLS=20 > > > direction or architecture. > > >=20 > > > but, that's just my perspective. > > >=20 > > > Lou > > >=20 > > > At 05:44 PM 1/22/2008, PAPADIMITRIOU Dimitri wrote: > > > >thus the question is whether or not to ask for a change=20 > > CCAMP "common > > > >control" in DCAMP "differentiated control" per technology ? > > > > > > > >we never have had a techno inducing a base building block=20 > > > change (GMPLS > > > >being a generalisation of MPLS-TE). i'm afraid that=20 > > generalized LSP, > > > >generalized LSR, generalized label, etc. per GMPLS arch (RFC=20 > > > 3945) would > > > >simply be unapplicable as known today and thus the corr.=20 > > > base protocol > > > >specs unapplicable. at the end the term "GMPLS" would be=20 > > > emptied of any > > > >real substance. > > > > > > > >it's a choice but let's ask the questions from the right=20 > > perspective. > > > > > > > >-d. > > > > > > > > > -----Original Message----- > > > > > From: Lou Berger [mailto:lberger@labn.net] > > > > > Sent: Tuesday, January 22, 2008 11:28 PM > > > > > To: PAPADIMITRIOU Dimitri > > > > > Cc: Lou Berger; Don Fedyk; BRUNGARD, DEBORAH A, ATTLABS; > > > > > ccamp@ops.ietf.org > > > > > Subject: RE: Proposed WG Draft -=20 > > draft-gmpls-ethernet-arch-00.txt > > > > > > > > > > I have no objection to adding "Updates: 3945" to the=20 > > > document header > > > > > and matching 3945's category. > > > > > > > > > > Lou > > > > > > > > > > At 05:11 PM 1/22/2008, PAPADIMITRIOU Dimitri wrote: > > > > > >Lou > > > > > > > > > > > >what i am concerned with: is that the doc extends > > > > > applicability of GMPLS > > > > > >to Ethernet by excluding GMPLS for Ethernet per RFC 3945=20 > > > ? does that > > > > > >make sense ? > > > > > > > > > > > >what's needed instead of hiding behind terms is to state=20 > > > GMPLS for Y, > > > > > >where Y includes the set of Ethernet-based techno's under > > > > > development at > > > > > >places as indicated in the doc itself. instead of=20 > > > inducing by a title > > > > > >such as "GMPLS for Ethernet" that this doc supersedes any > > > > > previous work > > > > > >in that > > > > > >space. > > > > > > > > > > > >-d. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: owner-ccamp@ops.ietf.org > > > > > > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Lou Berger > > > > > > > Sent: Tuesday, January 22, 2008 10:50 PM > > > > > > > To: Don Fedyk > > > > > > > Cc: PAPADIMITRIOU Dimitri; BRUNGARD, DEBORAH A, ATTLABS; > > > > > > > ccamp@ops.ietf.org > > > > > > > Subject: RE: Proposed WG Draft -=20 > > > draft-gmpls-ethernet-arch-00.txt > > > > > > > > > > > > > > Don, > > > > > > > I agree 100%. Furthermore there is no=20 > > > statement in the > > > > > > > draft that 3945 doesn't apply, in fact it explicitly=20 > > > says just the > > > > > > > opposite. The reason for the statement in question is > > > > > simply as you > > > > > > > say, and to ensure full ETH-LSP definition and=20 > interoperable > > > > > > > operation a new switching type/capability is required. > > > > > > > > > > > > > > It's really not such a bid deal or major change. > > > > > > > > > > > > > > Lou > > > > > > > > > > > > > > At 04:34 PM 1/22/2008, Don Fedyk wrote: > > > > > > > >Hi Dimitri > > > > > > > > > > > > > > > >The text you quote was put in the architecture/=20 > > > framework, not to > > > > > > > >exclude L2 Switch Capable (L2SC) but to prevent=20 > redefining > > > > > > > L2SC, which > > > > > > > >has been there for many years and may be in use. > > > > > > > > > > > > > > > >Perhaps the working needs to be adjusted but I=20 > don't think > > > > > > > it is a major > > > > > > > >issue. > > > > > > > > > > > > > > > >Regards, > > > > > > > >Don > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: owner-ccamp@ops.ietf.org > > > > > > > > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of > > > > > > > PAPADIMITRIOU Dimitri > > > > > > > > > Sent: Tuesday, January 22, 2008 4:16 PM > > > > > > > > > To: BRUNGARD, DEBORAH A, ATTLABS; ccamp@ops.ietf.org > > > > > > > > > Subject: RE: Proposed WG Draft - > > > > > draft-gmpls-ethernet-arch-00.txt > > > > > > > > > > > > > > > > > > All, > > > > > > > > > > > > > > > > > > > We received a couple of comments in the=20 > > > meeting, we would > > > > > > > > > > appreciate additional feedback on the list. > > > > > > > > > > > > > > > > > > The document states: > > > > > > > > > > > > > > > > > > "The L2SC Interface Switching Capabilities MUST=20 > > > NOT be used > > > > > > > > > to represent > > > > > > > > > interfaces capable of supporting Eth-LSPs.=20 > > > Interface Switching > > > > > > > > > Capability specific TE information may be defined as > > > > > > > needed to support > > > > > > > > > the requirements of a specific Ethernet Switching > > > > > Service Type." > > > > > > > > > > > > > > > > > > [...] > > > > > > > > > > > > > > > > > > "It is expected that there will be no case where an > > > > > > > Eth-LSP will be > > > > > > > > > signaled, or an Eth-LSP supporting interface will be > > > > > > > > > represented, using > > > > > > > > > the L2SC switching type/capability. A new switching > > > > > > > type/capability is > > > > > > > > > required to avoid any potential current usage=20 > > of the L2SC > > > > > > > switching > > > > > > > > > type/capability in support of Ethernet." > > > > > > > > > > > > > > > > > > This is explicit statement that GMPLS per RFC=20 > > 3945 is not > > > > > > > applicable. > > > > > > > > > So, it is much more than just an additional=20 > > codepoint, as > > > > > > > the control > > > > > > > > > plane behaviour is to be defined for this=20 > > > codepoint. So, it > > > > > > > > > is the open > > > > > > > > > door for a new control plane behaviour. > > > > > > > > > > > > > > > > > > so, let's have a more basic questioning before jumping > > > > > > > into the single > > > > > > > > > alternative resulting from this doc.: > > > > > > > > > > > > > > > > > > - either it is GMPLS for Ethernet=20 > architecture and then > > > > > > > what exist in > > > > > > > > > current RFCs should be applicable (because i=20 > do not see > > > > > > > any rationale > > > > > > > > > for L2SC def. departure for Ethernet frame=20 > processing); > > > > > > > > > > > > > > > > > > - or not it is X for Y architecture, where X is an IP > > > > > > > control protocol > > > > > > > > > based some potentially on some existing GMPLS blocks > > > > > and Y is not > > > > > > > > > compatible with the existing definition of Eth frame > > > > > processing. > > > > > > > > > > > > > > > > > > In the latter case, i do not know how this WG can deal > > > > > > > with such case > > > > > > > > > (from the control plane perspective). > > > > > > > > > > > > > > > > > > -d. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: owner-ccamp@ops.ietf.org > > > > > > > > > > [mailto:owner-ccamp@ops.ietf.org] On Behalf=20 > > Of BRUNGARD, > > > > > > > > > > DEBORAH A, ATTLABS > > > > > > > > > > Sent: Tuesday, January 22, 2008 8:28 PM > > > > > > > > > > To: ccamp@ops.ietf.org > > > > > > > > > > Subject: Proposed WG Draft - > > > > > draft-gmpls-ethernet-arch-00.txt > > > > > > > > > > > > > > > > > > > > CCAMP, > > > > > > > > > > > > > > > > > > > > The DT proposed in their meeting presentation=20 > > for their > > > > > > > > > > architecture and framework document to be=20 > > accepted as a > > > > > > > WG draft: > > > > > > > > > > > > > > > > > > > > > >=20 > > >=20 > http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt > > > > > > > > > > > > > > > > > > > > We received a couple of comments in the=20 > > > meeting, we would > > > > > > > > > > appreciate additional feedback on the list.=20 > > > Please express > > > > > > > > > > your support (or otherwise) for this I-D to become > > > > > a WG draft. > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > Deborah > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=20 > > >=20 > > >=20 > >=20 >=20 From belldd@urscorp.com Thu Jan 24 03:38:04 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JHxb2-0002Lk-15 for ccamp-archive@ietf.org; Thu, 24 Jan 2008 03:38:04 -0500 Received: from [81.195.224.98] (helo=zinpme) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JHxb1-0003FH-8Q for ccamp-archive@ietf.org; Thu, 24 Jan 2008 03:38:03 -0500 Received: from [222.130.27.79] (helo=ufy) by zinpme with smtp (Exim 4.62 (FreeBSD)) id 1JIg-0005XT-Sv; Thu, 24 Jan 2008 11:42:48 +0300 Message-ID: <47984E69.7030205@urscorp.com> Date: Thu, 24 Jan 2008 11:38:01 +0300 From: User-Agent: Thunderbird 1.5.0.13 (Windows/20070809) MIME-Version: 1.0 To: ccamp-archive@ietf.org Subject: Words in my Heart Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 Special Romance http://61.58.173.69/ From jkang@aam.com Thu Jan 24 07:32:31 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JI1Fu-0006xX-Vl for ccamp-archive@ietf.org; Thu, 24 Jan 2008 07:32:31 -0500 Received: from p4051-ipbf3210marunouchi.tokyo.ocn.ne.jp ([122.29.99.51]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JI1Fu-00023a-8i for ccamp-archive@ietf.org; Thu, 24 Jan 2008 07:32:30 -0500 Received: from [137.156.67.207] (helo=vzyzz) by p4051-ipbf3210marunouchi.tokyo.ocn.ne.jp with smtp (Exim 4.62 (FreeBSD)) id 1JI1ID-0004Sq-Gd; Thu, 24 Jan 2008 21:34:53 +0900 Message-ID: <000e01c85e85$3ada8580$cf439c89@vzyzz> From: To: Subject: the quicker pecker upper Date: Thu, 24 Jan 2008 21:32:49 +0900 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="windows-1252"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Spam-Score: 2.7 (++) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 Will you be ready at the right moment with the right girl? http://rqokyj.endscience.com From Morgaliovienebtiy@ROBINSONFANS.COM Thu Jan 24 09:16:36 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JI2se-0000LW-Bg for ccamp-archive@ietf.org; Thu, 24 Jan 2008 09:16:36 -0500 Received: from [190.57.107.115] (helo=ip-gt.190.57.89.115.telefonica-ca.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JI2sd-0005a6-9s for ccamp-archive@ietf.org; Thu, 24 Jan 2008 09:16:36 -0500 Received: from RADIOVERDAD by ROBINSONFANS.COM with ASMTP id 7ACE18E0 for ; Tue, 15 Jan 2008 03:49:44 -0600 Received: from RADIOVERDAD ([130.167.199.75]) by ROBINSONFANS.COM with ESMTP id 2FCC17354743 for ; Tue, 15 Jan 2008 03:49:44 -0600 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 15 Jan 2008 03:49:20 -0600 To: ccamp-archive@ietf.org From: "Lalita Morgalioviene" Subject: edivur Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Yo yo yo ccamp-archive your little friend needs help too C1/\lis will help http://geroihalate.com Lalita Morgalioviene From owner-ccamp@ops.ietf.org Thu Jan 24 11:15:21 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JI4jZ-0001wA-J0 for ccamp-archive@ietf.org; Thu, 24 Jan 2008 11:15:21 -0500 Received: from psg.com ([2001:418:1::62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JI4jY-0001aF-48 for ccamp-archive@ietf.org; Thu, 24 Jan 2008 11:15:21 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JI4Va-000ES7-HT for ccamp-data@psg.com; Thu, 24 Jan 2008 16:00:54 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,MISSING_MID, RDNS_NONE autolearn=no version=3.2.3 Received: from [216.104.42.195] (helo=esc91.midphase.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JI4VL-000EQV-QX for ccamp@ops.ietf.org; Thu, 24 Jan 2008 16:00:41 +0000 Received: from esc91.midphase.com ([216.104.33.66] helo=LC2.labn.net) by esc91.midphase.com with esmtpa (Exim 4.68) (envelope-from ) id 1JI4VI-0003bH-5j; Thu, 24 Jan 2008 11:00:36 -0500 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 24 Jan 2008 11:00:34 -0500 To: ccamp@ops.ietf.org From: Lou Berger Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Cc: "BRUNGARD, DEBORAH A, ATTLABS" In-Reply-To: <34B3EAA5B3066A42914D28C5ECF5FEA41349EF98@zrtphxm2.corp.nor tel.com> References: <449B2580D802A443A923DABF3EAB82AF10132C78@OCCLUST04EVS1.ugd.att.com> <34B3EAA5B3066A42914D28C5ECF5FEA41340D7D1@zrtphxm2.corp.nortel.com> <200801222228.m0MMRxVa004316@mailgate4.alcatel.fr> <34B3EAA5B3066A42914D28C5ECF5FEA41349EF98@zrtphxm2.corp.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - esc91.midphase.com X-AntiAbuse: Original Domain - ops.ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-Source: X-Source-Args: X-Source-Dir: Sender: owner-ccamp@ops.ietf.org Precedence: bulk Message-Id: X-Spam-Score: 0.0 (/) X-Scan-Signature: 1c0c3d540ad9f95212b1c2a9a2cc2595 All, I think this level of theoretical/hypothetical discussion can continue ad infinitum. I propose we leave the text as is, and revisit the decision (and text) in the context of the anticipated mechanism specific documents if and when someone propose to use L2SC. WG-chairs, Does this make sense? Is it acceptable? Thanks, Lou At 09:51 PM 1/23/2008, Don Fedyk wrote: >Hi Dimitri > >The document clearly states: > >"The intent of this document is to reuse and align with as much of the > GMPLS protocols as possible. For example reusing the IP control > plane addressing allows the existing signaling, routing, LMP and path > computation to be used as specified. Additions are made only to > accommodate features of Ethernet that are not already supported by > GMPLS. The GMPLS protocols support a set of tools for hierarchical > LSPs as well as contiguous LSPs. GMPLS specific protocol mechanisms > support a variety of networks from peer to peer to UNIs and NNIs." > >So your question comes down to why we make the statement on L2SC? Like >Lou said when we discussed this we thought that L2SC came with baggage >and was not precise. The switching capabilities would be specified in >documents that address the particular Ethernet data plane. It is true >that if there was a valid Ethernet data plane that could use L2SC >unambiguously it should fit under the architecture. At any rate getting >this right is something that can be accomplished when this is a WG >draft. > >Regards, >Don > > > > > -----Original Message----- > > From: PAPADIMITRIOU Dimitri > > [mailto:Dimitri.Papadimitriou@alcatel-lucent.be] > > Sent: Wednesday, January 23, 2008 7:05 PM > > To: Lou Berger > > Cc: Fedyk, Don (BL60:1A00); BRUNGARD, DEBORAH A, ATTLABS; > > ccamp@ops.ietf.org > > Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt > > > > the question triggered by this poll is the following: if GMPLS for > > Ethernet is not inline with the existing stacks what is the value of > > GMPLS re-use ? what's the value to borrow the term GMPLS without its > > substance ? and in practice, the issue is, if it is not GMPLS per RFC > > 3945, what's the value compared to any other native control stack that > > would be developed at IEEE for inst. for these techno's. > > > > you quote: > > > > > L2SC was always underspecified (e.g., covers both ATM and Ether), > > > > additional specification does not result in departing from the initial > > definition but refinement of the initial definition (definition of a > > sub-set not a side definition). > > > > probably the document is not mature enough to respond to the > > tie-breaker: what about the FIT of GMPLS for Ethernet but not > > within the > > L2SC space (as defined today) ? but in the meantime preclude > > any allowed > > use of GMPLS per IETF RFCs to Ethernet if they do not comply > > with a new > > WG i-d would create a precedent in the history of this WG with really > > disastrous impact (including on other application of GMPLS) > > > > we're at a turning point (equivalent to RSVP vs RSVP-TE). we need to > > assess consequences before going one way or another and under which > > conditions. > > > > -d. > > > > > -----Original Message----- > > > From: owner-ccamp@ops.ietf.org > > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Lou Berger > > > Sent: Wednesday, January 23, 2008 1:09 AM > > > To: PAPADIMITRIOU Dimitri > > > Cc: Lou Berger; Don Fedyk; BRUNGARD, DEBORAH A, ATTLABS; > > > ccamp@ops.ietf.org > > > Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt > > > > > > We've always had different switching type/capability in > > > GMPLS. Nothing new here. > > > > > > L2SC was always underspecified (e.g., covers both ATM and > > Ether), is > > > currently used by some for different purposes, and doesn't allow > > > unique identification of switching capabilities of an interface. I > > > *really* don't see the unique identification of an interface's > > > Ethernet switching function as any different from what is done for > > > today for the other types or as any big deal or change in GMPLS > > > direction or architecture. > > > > > > but, that's just my perspective. > > > > > > Lou > > > > > > At 05:44 PM 1/22/2008, PAPADIMITRIOU Dimitri wrote: > > > >thus the question is whether or not to ask for a change > > CCAMP "common > > > >control" in DCAMP "differentiated control" per technology ? > > > > > > > >we never have had a techno inducing a base building block > > > change (GMPLS > > > >being a generalisation of MPLS-TE). i'm afraid that > > generalized LSP, > > > >generalized LSR, generalized label, etc. per GMPLS arch (RFC > > > 3945) would > > > >simply be unapplicable as known today and thus the corr. > > > base protocol > > > >specs unapplicable. at the end the term "GMPLS" would be > > > emptied of any > > > >real substance. > > > > > > > >it's a choice but let's ask the questions from the right > > perspective. > > > > > > > >-d. > > > > > > > > > -----Original Message----- > > > > > From: Lou Berger [mailto:lberger@labn.net] > > > > > Sent: Tuesday, January 22, 2008 11:28 PM > > > > > To: PAPADIMITRIOU Dimitri > > > > > Cc: Lou Berger; Don Fedyk; BRUNGARD, DEBORAH A, ATTLABS; > > > > > ccamp@ops.ietf.org > > > > > Subject: RE: Proposed WG Draft - > > draft-gmpls-ethernet-arch-00.txt > > > > > > > > > > I have no objection to adding "Updates: 3945" to the > > > document header > > > > > and matching 3945's category. > > > > > > > > > > Lou > > > > > > > > > > At 05:11 PM 1/22/2008, PAPADIMITRIOU Dimitri wrote: > > > > > >Lou > > > > > > > > > > > >what i am concerned with: is that the doc extends > > > > > applicability of GMPLS > > > > > >to Ethernet by excluding GMPLS for Ethernet per RFC 3945 > > > ? does that > > > > > >make sense ? > > > > > > > > > > > >what's needed instead of hiding behind terms is to state > > > GMPLS for Y, > > > > > >where Y includes the set of Ethernet-based techno's under > > > > > development at > > > > > >places as indicated in the doc itself. instead of > > > inducing by a title > > > > > >such as "GMPLS for Ethernet" that this doc supersedes any > > > > > previous work > > > > > >in that > > > > > >space. > > > > > > > > > > > >-d. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: owner-ccamp@ops.ietf.org > > > > > > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Lou Berger > > > > > > > Sent: Tuesday, January 22, 2008 10:50 PM > > > > > > > To: Don Fedyk > > > > > > > Cc: PAPADIMITRIOU Dimitri; BRUNGARD, DEBORAH A, ATTLABS; > > > > > > > ccamp@ops.ietf.org > > > > > > > Subject: RE: Proposed WG Draft - > > > draft-gmpls-ethernet-arch-00.txt > > > > > > > > > > > > > > Don, > > > > > > > I agree 100%. Furthermore there is no > > > statement in the > > > > > > > draft that 3945 doesn't apply, in fact it explicitly > > > says just the > > > > > > > opposite. The reason for the statement in question is > > > > > simply as you > > > > > > > say, and to ensure full ETH-LSP definition and interoperable > > > > > > > operation a new switching type/capability is required. > > > > > > > > > > > > > > It's really not such a bid deal or major change. > > > > > > > > > > > > > > Lou > > > > > > > > > > > > > > At 04:34 PM 1/22/2008, Don Fedyk wrote: > > > > > > > >Hi Dimitri > > > > > > > > > > > > > > > >The text you quote was put in the architecture/ > > > framework, not to > > > > > > > >exclude L2 Switch Capable (L2SC) but to prevent redefining > > > > > > > L2SC, which > > > > > > > >has been there for many years and may be in use. > > > > > > > > > > > > > > > >Perhaps the working needs to be adjusted but I don't think > > > > > > > it is a major > > > > > > > >issue. > > > > > > > > > > > > > > > >Regards, > > > > > > > >Don > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: owner-ccamp@ops.ietf.org > > > > > > > > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of > > > > > > > PAPADIMITRIOU Dimitri > > > > > > > > > Sent: Tuesday, January 22, 2008 4:16 PM > > > > > > > > > To: BRUNGARD, DEBORAH A, ATTLABS; ccamp@ops.ietf.org > > > > > > > > > Subject: RE: Proposed WG Draft - > > > > > draft-gmpls-ethernet-arch-00.txt > > > > > > > > > > > > > > > > > > All, > > > > > > > > > > > > > > > > > > > We received a couple of comments in the > > > meeting, we would > > > > > > > > > > appreciate additional feedback on the list. > > > > > > > > > > > > > > > > > > The document states: > > > > > > > > > > > > > > > > > > "The L2SC Interface Switching Capabilities MUST > > > NOT be used > > > > > > > > > to represent > > > > > > > > > interfaces capable of supporting Eth-LSPs. > > > Interface Switching > > > > > > > > > Capability specific TE information may be defined as > > > > > > > needed to support > > > > > > > > > the requirements of a specific Ethernet Switching > > > > > Service Type." > > > > > > > > > > > > > > > > > > [...] > > > > > > > > > > > > > > > > > > "It is expected that there will be no case where an > > > > > > > Eth-LSP will be > > > > > > > > > signaled, or an Eth-LSP supporting interface will be > > > > > > > > > represented, using > > > > > > > > > the L2SC switching type/capability. A new switching > > > > > > > type/capability is > > > > > > > > > required to avoid any potential current usage > > of the L2SC > > > > > > > switching > > > > > > > > > type/capability in support of Ethernet." > > > > > > > > > > > > > > > > > > This is explicit statement that GMPLS per RFC > > 3945 is not > > > > > > > applicable. > > > > > > > > > So, it is much more than just an additional > > codepoint, as > > > > > > > the control > > > > > > > > > plane behaviour is to be defined for this > > > codepoint. So, it > > > > > > > > > is the open > > > > > > > > > door for a new control plane behaviour. > > > > > > > > > > > > > > > > > > so, let's have a more basic questioning before jumping > > > > > > > into the single > > > > > > > > > alternative resulting from this doc.: > > > > > > > > > > > > > > > > > > - either it is GMPLS for Ethernet architecture and then > > > > > > > what exist in > > > > > > > > > current RFCs should be applicable (because i do not see > > > > > > > any rationale > > > > > > > > > for L2SC def. departure for Ethernet frame processing); > > > > > > > > > > > > > > > > > > - or not it is X for Y architecture, where X is an IP > > > > > > > control protocol > > > > > > > > > based some potentially on some existing GMPLS blocks > > > > > and Y is not > > > > > > > > > compatible with the existing definition of Eth frame > > > > > processing. > > > > > > > > > > > > > > > > > > In the latter case, i do not know how this WG can deal > > > > > > > with such case > > > > > > > > > (from the control plane perspective). > > > > > > > > > > > > > > > > > > -d. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: owner-ccamp@ops.ietf.org > > > > > > > > > > [mailto:owner-ccamp@ops.ietf.org] On Behalf > > Of BRUNGARD, > > > > > > > > > > DEBORAH A, ATTLABS > > > > > > > > > > Sent: Tuesday, January 22, 2008 8:28 PM > > > > > > > > > > To: ccamp@ops.ietf.org > > > > > > > > > > Subject: Proposed WG Draft - > > > > > draft-gmpls-ethernet-arch-00.txt > > > > > > > > > > > > > > > > > > > > CCAMP, > > > > > > > > > > > > > > > > > > > > The DT proposed in their meeting presentation > > for their > > > > > > > > > > architecture and framework document to be > > accepted as a > > > > > > > WG draft: > > > > > > > > > > > > > > > > > > > > > > > > > http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt > > > > > > > > > > > > > > > > > > > > We received a couple of comments in the > > > meeting, we would > > > > > > > > > > appreciate additional feedback on the list. > > > Please express > > > > > > > > > > your support (or otherwise) for this I-D to become > > > > > a WG draft. > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > Deborah > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From happinesskm37@seldinconstruction.com Thu Jan 24 12:54:34 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JI6HZ-0006Ni-UU for ccamp-archive@ietf.org; Thu, 24 Jan 2008 12:54:33 -0500 Received: from 82.138.broadband3.iol.cz ([85.70.138.82]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JI6HY-0005q9-W0 for ccamp-archive@ietf.org; Thu, 24 Jan 2008 12:54:33 -0500 Received: from [85.70.138.82] by mx.seldinconstruction.com; Thu, 24 Jan 2008 18:54:32 +0100 From: Guy To: Subject: CockLargishShannon Date: Thu, 24 Jan 2008 18:54:32 +0100 Message-ID: <01c85eba$8e09e400$528a4655@happinesskm37> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2663 Importance: Normal X-Spam-Score: 2.9 (++) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 GreatestPhallusMichel http://www.calormontes.com From owner-ccamp@ops.ietf.org Thu Jan 24 13:01:42 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JI6OU-00077I-LC for ccamp-archive@ietf.org; Thu, 24 Jan 2008 13:01:42 -0500 Received: from psg.com ([2001:418:1::62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JI6OS-0004cs-Va for ccamp-archive@ietf.org; Thu, 24 Jan 2008 13:01:42 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JI6Cz-0000Th-3X for ccamp-data@psg.com; Thu, 24 Jan 2008 17:49:49 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [66.226.64.2] (helo=pro.abac.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JI6Cw-0000Sz-Dw for ccamp@ops.ietf.org; Thu, 24 Jan 2008 17:49:47 +0000 Received: from [192.168.0.131] (c-71-202-41-42.hsd1.ca.comcast.net [71.202.41.42]) (authenticated bits=0) by pro.abac.com (8.14.1/8.14.1) with ESMTP id m0OHnbpm068484 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Jan 2008 09:49:38 -0800 (PST) (envelope-from gregb@grotto-networking.com) Message-ID: <4798CFB3.3030605@grotto-networking.com> Date: Thu, 24 Jan 2008 09:49:39 -0800 From: Greg Bernstein User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: ccamp CC: Adrian Farrel Subject: Calls, Connections and VCAT... Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Hello all, and Adrian and "GMPLS call" authors in particular. I've been reviewing the requirements for VCAT/LCAS and potential additions, the definition of "call" from G.8081 (2004) and trying to reconcile these in an efficient manner so we can move forward with the GMPLS/VCAT draft. Definitions from G.8081: 3.2.6 call: An association between endpoints that supports an instance of a service. 3.2.7 call control: Call control is a signalling association between one or more user applications and the network to control the set-up, release, modification and maintenance of sets of connections. Additional information from G.8080 (2006) section 5.1: "Additionally, call control is provided at interlayer NCC boundaries." From these definitions it seems that the use of "call control" to coordinate an inverse multiplexing technology is actually recommended (since this is the domain boundary between to layers). However in trying to use RFC4974 along with the additional requirements that have come up (and seem desired), I seem to have a problem when I want to utilize an existing connection with a new call. In RFC4974. Section 5.2.2. It says: "The Connections (LSPs) associated with a Call need to carry a reference to the Call - the short Call ID. A new field is added to the signaling protocol to identify an individual LSP with the Call to which it belongs." This is where the complications come in, since we cannot change "session" information on an LSP and hence can't change the Call ID. But do we always need the call ID with the LSP? In section 4.2 of RFC4974 the hierarchy of of calls, connections, tunnels and LSP is given and it seems that (Session, Tunnel ID, LSP ID) can be used to uniquely identify the LSP too. The feedback I received concerning VCAT signaling approaches included: (a) support for Notify based mechanism (b) strong opposition to the current multiple VCGs per call work around for "resource sharing" (c) mild interest, but no proposals in something else entirely. Hence at this stage and based on my reading of G.8080, G.8081, I'd like to try to fix the "call" approach. Other solution proposals are welcome, but I will not be actively pursuing them. Regards Greg B. -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 From kcmx@adelphia.com Thu Jan 24 16:00:03 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JI9B4-0007LX-UN for ccamp-archive@ietf.org; Thu, 24 Jan 2008 16:00:02 -0500 Received: from chello089078017242.chello.pl ([89.78.17.242]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JI9B3-0003Em-Nj for ccamp-archive@ietf.org; Thu, 24 Jan 2008 16:00:02 -0500 Message-ID: <000801c85ecc$042a7103$cdf53f90@spdwxeue> From: "dirk jimmy" To: Subject: Save today 60% Off ALL Designer Footwear such as Gucci Prada Chanel Date: Thu, 24 Jan 2008 19:12:37 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 OMG! The Post-Christmas sale is CRAZY at Prestige Footwear! Find Top Designer Brand Name Shoes, Boots High Heels, and more from the Fashion Industry's best including Gucci, Prada, Chanel, Dior, Ugg Boots, Versace, Burberry, D&G, DSquares and other brand names! All on SALE, Take Advantage. FREE Shipping on ALL ORDERS! A Wide Selection for both, Men and Women. The Season's Top Models all HALF PRICE, Now ONLY! Click HERE www.bestshoesstreet.com Can you believe it? Because I can't! SAVE NOW From jalmendares@casinos.gub.uy Thu Jan 24 18:15:05 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIBHl-0006Wb-Hz for ccamp-archive@ietf.org; Thu, 24 Jan 2008 18:15:05 -0500 Received: from [63.135.137.221] (helo=63-135-137-221.netnet.net) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JIBHj-0006el-73 for ccamp-archive@ietf.org; Thu, 24 Jan 2008 18:15:03 -0500 Received: from ghk ([166.157.104.194]) by 63-135-137-221.netnet.net (8.13.3/8.13.3) with SMTP id m0ONI4Dq063827; Thu, 24 Jan 2008 17:18:04 -0600 Message-ID: <47991BED.2050405@casinos.gub.uy> Date: Thu, 24 Jan 2008 17:14:53 -0600 From: User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: ccamp-archive@ietf.org Subject: Have as many wonderful nights as you want! Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.6 (/) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 be all that you can be http://iaodei.saymuch.com From owner-ccamp@ops.ietf.org Thu Jan 24 18:41:23 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIBhD-0006MA-3x for ccamp-archive@ietf.org; Thu, 24 Jan 2008 18:41:23 -0500 Received: from psg.com ([2001:418:1::62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JIBhA-0003iy-Ha for ccamp-archive@ietf.org; Thu, 24 Jan 2008 18:41:23 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JIBTi-000BZM-A1 for ccamp-data@psg.com; Thu, 24 Jan 2008 23:27:26 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE, RDNS_NONE autolearn=no version=3.2.3 Received: from [168.127.0.56] (helo=fncnmp03.fnc.fujitsu.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JIBTf-000BYr-RS for ccamp@ops.ietf.org; Thu, 24 Jan 2008 23:27:25 +0000 X-IronPort-AV: E=Sophos;i="4.25,246,1199685600"; d="scan'208,217";a="275092702" Received: from rchemx01.fnc.net.local ([168.127.134.104]) by fncnmp01.fnc.fujitsu.com with ESMTP; 24 Jan 2008 17:27:17 -0600 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_01C85EE0.A815503E" Subject: LSPID for Segment Recovery Date: Thu, 24 Jan 2008 17:27:16 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: LSPID for Segment Recovery Thread-Index: Ache4KgQ2YcByof3RWGUMtyDsZsljw== From: "Bardalai, Snigdho" To: "Ccamp (E-mail)" Cc: "Adrian Farrel (E-mail)" , "Lou Berger (E-mail)" Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 This is a multi-part message in MIME format. ------_=_NextPart_001_01C85EE0.A815503E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I have a doubt on the relationship between LSPID and association ID for = tunnels with segment recovery. Would appreciate it if someone could = clarify. RFC4872 suggests using the working LSP's LSPID as the association ID in = the ASSOCIATION object for the recovery LSP and the reverse for the = working LSP and RFC4873 requires the use of this definition as per the = following extract: 2. Segment Recovery snip ...... snip When [RFC4090] isn't being used, the association between segment recovery LSPs with other LSPs is indicated using the ASSOCIATION object defined in [RFC4872] snip...... I would expect this definition includes the way the association ID value = should be assigned, is my understanding correct?=20 I can understand how the ASSOCIATION object for the recovery LSP can = have its association ID set to the working LSP LSPID but it may not be = possible for the reverse since there could be multiple recovery LSP = segments.=20 I would like to understand what should the working LSP association ID be = in case of segment recovery, should it be set to its own LSPID? Also, my understanding is that the association ID needs to be unique in = the context of the association source, if that is the case does it mean = if LSPID is used as the association ID then the LSPID should also be = unique in the context of the association source rather than the context = of a tunnel. Thanks, Snigdho ------_=_NextPart_001_01C85EE0.A815503E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable LSPID for Segment Recovery

Hi,

I have a doubt on the relationship = between LSPID and association ID for tunnels with segment recovery. = Would appreciate it if someone could clarify.

RFC4872 suggests using the working = LSP's LSPID as the association ID in the ASSOCIATION object for the = recovery LSP and the reverse for the working LSP and RFC4873 requires = the use of this definition as per the following extract:

2.  Segment Recovery

   snip ...... snip

   When [RFC4090] isn't being = used, the association between segment
   recovery LSPs with other = LSPs is indicated using the ASSOCIATION
   object defined in = [RFC4872]

   snip......

I would expect this definition includes = the way the association ID value should be assigned, is my understanding = correct?

I can understand how the ASSOCIATION = object for the recovery LSP can have its association ID set to the = working LSP LSPID but it may not be possible for the reverse since there = could be multiple recovery LSP segments.

I would like to understand what should = the working LSP association ID be in case of segment recovery, should it = be set to its own LSPID?

Also, my understanding is that the = association ID needs to be unique in the context of the association = source, if that is the case does it mean if LSPID is used as the = association ID then the LSPID should also be unique in the context of = the association source rather than the context of a tunnel.

Thanks,
Snigdho

------_=_NextPart_001_01C85EE0.A815503E-- From samshupsec@acadian-group.com Thu Jan 24 19:19:22 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JICHy-0007Mc-EE for ccamp-archive@megatron.ietf.org; Thu, 24 Jan 2008 19:19:22 -0500 Received: from [201.50.65.22] (helo=20150065022.user.veloxzone.com.br) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JICHx-0000tT-T6 for ccamp-archive@megatron.ietf.org; Thu, 24 Jan 2008 19:19:22 -0500 Received: (qmail 79264 invoked from network); Thu, 24 Jan 2008 21:19:23 -0300 Received: from unknown (HELO acadian-group.com) (7.169.184.13) by with SMTP; Thu, 24 Jan 2008 21:19:22 -0300 Received: from localhost.localdomain ( [210.148.81.145]) by acadian-group.com (8.13.1/8.13.1) with SMTP id tTaXhDbQ919924 for ; Thu, 24 Jan 2008 21:19:21 -0300 Message-Id: <764617602803.tTaXhDbQ919924@749621.> Received: from phpmailer ([127.0.0.1]) by with HTTP; Thu, 24 Jan 2008 21:19:21 -0300 Date: Thu, 24 Jan 2008 21:19:21 -0300 To: ccamp-archive@megatron.ietf.org From: "samshu" Subject: sammot X-Priority: 3 X-Mailer: phpmailer [version 1.54] Reply-To: samshupsec@acadian-group.com MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset = "iso-8859-1" X-Antivirus: avast! (VPS 080123-2, 23/01/2008), Outbound message X-Antivirus-Status: Clean X-Spam-Score: 4.8 (++++) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 http://boieoae.com/ Want to change your life around? No problem. Click here From saluerio508@acadian-group.com Thu Jan 24 19:19:47 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JICIN-0007hP-IX for ccamp-archive@ietf.org; Thu, 24 Jan 2008 19:19:47 -0500 Received: from [201.50.65.22] (helo=20150065022.user.veloxzone.com.br) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JICIN-0000uB-24 for ccamp-archive@ietf.org; Thu, 24 Jan 2008 19:19:47 -0500 Received: (qmail 9335 invoked from network); Thu, 24 Jan 2008 21:19:48 -0300 Received: from unknown (HELO acadian-group.com) (205.39.122.112) by with SMTP; Thu, 24 Jan 2008 21:19:47 -0300 Received: from localhost.localdomain ( [48.56.67.100]) by acadian-group.com (8.13.1/8.13.1) with SMTP id omzACsOU073189 for ; Thu, 24 Jan 2008 21:19:46 -0300 Message-Id: <329577153727.omzACsOU073189@084427.> Received: from phpmailer ([127.0.0.1]) by with HTTP; Thu, 24 Jan 2008 21:19:46 -0300 Date: Thu, 24 Jan 2008 21:19:46 -0300 To: ccamp-archive@ietf.org From: "saluerio" Subject: sangupse X-Priority: 3 X-Mailer: phpmailer [version 1.54] Reply-To: saluerio508@acadian-group.com MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset = "iso-8859-1" X-Antivirus: avast! (VPS 080123-2, 23/01/2008), Outbound message X-Antivirus-Status: Clean X-Spam-Score: 1.6 (+) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 http://www.bdpageao.com/ Make your lady love you even more with your new, massive rod. From richard@wyeconstruction.com Thu Jan 24 21:04:13 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIDvR-0005AF-Qo; Thu, 24 Jan 2008 21:04:13 -0500 Received: from [124.13.4.214] (helo=[124.13.4.214]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JIDvQ-0003ti-KG; Thu, 24 Jan 2008 21:04:13 -0500 Received: from [124.13.4.214] by mail2.wyeconstruction.com; Fri, 25 Jan 2008 10:25:51 +0800 From: "Jefferson Darby" To: Subject: Re: Darby Date: Fri, 25 Jan 2008 10:25:51 +0800 Message-ID: <01c85f3c$a884a180$d6040d7c@richard> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Importance: Normal X-Spam-Score: 0.1 (/) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 If a relaxing moment turns into the right moment, will you be ready? http://www.bnoaeoab.com I appreciate that Something more fun. compared with For the sake In a way that makes you beneficial but should not be viewed From tony.eide@radioarchipielago.com Thu Jan 24 21:11:45 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIE2j-0004iR-3l for ccamp-archive@megatron.ietf.org; Thu, 24 Jan 2008 21:11:45 -0500 Received: from [201.250.56.214] (helo=hogar-2591e8fa3) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JIE2h-00043a-Tv for ccamp-archive@megatron.ietf.org; Thu, 24 Jan 2008 21:11:44 -0500 Received: from [201.250.56.214] by mail.radioarchipielago.com; Thu, 24 Jan 2008 23:33:26 -0300 From: "Brian Hooper" To: Subject: Re: Hooper Date: Thu, 24 Jan 2008 23:33:26 -0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: Aca6QPMT7F9TJYFWL3Q2V2Q3JQD30A== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Message-ID: <01c85ee1$8447a700$d638fac9@tony.eide> X-Spam-Score: 0.1 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db If a relaxing moment turns into the right moment, will you be ready? http://www.bnieiawe.com that I have been when he casually mentions or just romping of issues with a You want to learn about discover From o.thurman_ye@cyclotomic.com Fri Jan 25 00:18:09 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIGx6-000752-Uv; Fri, 25 Jan 2008 00:18:08 -0500 Received: from host222-161-dynamic.50-82-r.retail.telecomitalia.it ([82.50.161.222] helo=northstate.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JIGx5-0000pm-AI; Fri, 25 Jan 2008 00:18:08 -0500 Sender: To: isis-wg-admin@ietf.org Bcc: mbeaulie@ietf.org, ieprep@ietf.org, hubmib-bounces@ietf.org, ccamp-archive@ietf.org, ldap-dir-bounces@ietf.org From: "Olive Thurman" In-Reply-To: Reply-To: "Olive Thurman" Date: Fri, 25 Jan 2008 00:02:47 -0700 X-Sender: Subject: :: 86% Cheaper than Original Price: aRolex, Cartier, Omega, Chanel, Tag Heuer, Breitling & ... jolgke1x3dc783cl Message-ID: <1201244567.4767@cyclotomic.com> Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 8bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 ** We add 100 Latest Arrival 2008 models Watches ** /// Safe & guaranteed shopping \\\ /// Inquiries answered in 24 hours \\\ /// Over 1360 Models to choose from \\\ Swiss QualityReplica Many World famous LUXURY BRANDS Free 1 year Warranty on all Watches http://zevebobu27915.googlepages.com From lackey@goodwindows.com Fri Jan 25 01:36:53 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIIBJ-0005Gm-51 for ccamp-archive@ietf.org; Fri, 25 Jan 2008 01:36:53 -0500 Received: from [83.228.36.17] (helo=mgbgcj) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JIIBI-0002pv-Jt for ccamp-archive@ietf.org; Fri, 25 Jan 2008 01:36:53 -0500 Received: (qmail 13770 invoked from network); Fri, 25 Jan 2008 08:36:38 +0200 Received: from unknown (HELO hpfsv) (137.73.35.37) by mgbgcj with SMTP; Fri, 25 Jan 2008 08:36:38 +0200 Message-ID: <47998376.1050100@goodwindows.com> Date: Fri, 25 Jan 2008 08:36:38 +0200 From: User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: ccamp-archive@ietf.org Subject: Special Romance Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 The Dance of Love http://69.246.113.197/ From ccamp10@terra.com.br Fri Jan 25 03:53:52 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIKJr-0005sD-Vs for ccamp-archive@ietf.org; Fri, 25 Jan 2008 03:53:52 -0500 Received: from [195.151.227.21] (helo=3b071416275e4e2) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JIKJq-00068s-Jf for ccamp-archive@ietf.org; Fri, 25 Jan 2008 03:53:51 -0500 Content-Return: allowed X-Mailer: CME-V6.5.4.3; MSN Received: (qmail 10007 by uid 294); Fri, 25 Jan 2008 11:53:57 +0300 Message-Id: <20080125145357.10009.qmail@3b071416275e4e2> To: Subject: January 73% OFF From: MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 1.8 (+) X-Scan-Signature: 88b11fc64c1bfdb4425294ef5374ca07
From owner-ccamp@ops.ietf.org Fri Jan 25 04:14:40 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIKe0-00067W-2e for ccamp-archive@ietf.org; Fri, 25 Jan 2008 04:14:40 -0500 Received: from psg.com ([2001:418:1::62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JIKdw-0000DI-QO for ccamp-archive@ietf.org; Fri, 25 Jan 2008 04:14:40 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JIKT9-000EHk-Ab for ccamp-data@psg.com; Fri, 25 Jan 2008 09:03:27 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE, RDNS_NONE autolearn=no version=3.2.3 Received: from [193.180.251.62] (helo=mailgw4.ericsson.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JIKT5-000EHQ-Jg for ccamp@ops.ietf.org; Fri, 25 Jan 2008 09:03:25 +0000 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 0937D21397; Fri, 25 Jan 2008 10:03:21 +0100 (CET) X-AuditID: c1b4fb3e-ae5efbb0000007e1-30-4799a5d859c0 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id DBF5021196; Fri, 25 Jan 2008 10:03:20 +0100 (CET) Received: from esealmw110.eemea.ericsson.se ([153.88.200.78]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Jan 2008 10:03:20 +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_01C85F31.21C359D3" Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Date: Fri, 25 Jan 2008 10:03:29 +0100 Message-ID: <0428AC48A879ED46A94F39D5665DF6840100234F@esealmw110.eemea.ericsson.se> In-Reply-To: <449B2580D802A443A923DABF3EAB82AF10132C78@OCCLUST04EVS1.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt thread-index: AchdLOH3JrqySZgzQVuueGk7Nk+CoACBCarA From: "Diego Caviglia" To: "BRUNGARD, DEBORAH A, ATTLABS" , X-OriginalArrivalTime: 25 Jan 2008 09:03:20.0386 (UTC) FILETIME=[21B8E220:01C85F31] X-Brightmail-Tracker: AAAAAA== Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -1.0 (-) X-Scan-Signature: 578c2c9d0cb01ffe6e1ca36540edd070 This is a multi-part message in MIME format. ------_=_NextPart_001_01C85F31.21C359D3 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I support this as WG even if I'd like to have the Dimitri questions = addressed, may in next WG version of the doc. =20 LBR Diego =20 ________________________________ From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On = Behalf Of BRUNGARD, DEBORAH A, ATTLABS Sent: marted=EC 22 gennaio 2008 20.28 To: ccamp@ops.ietf.org Subject: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt =20 CCAMP, =20 The DT proposed in their meeting presentation for their architecture and = framework document to be accepted as a WG draft: http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt =20 We received a couple of comments in the meeting, we would appreciate = additional feedback on the list. Please express your support (or = otherwise) for this I-D to become a WG draft. =20 Thanks, Deborah ------_=_NextPart_001_01C85F31.21C359D3 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I support this as WG even if = I’d like to have the Dimitri questions addressed, may in next WG version of = the doc.

 

LBR


Diego

 
------_=_NextPart_001_01C85F31.21C359D3-- From owner-ccamp@ops.ietf.org Fri Jan 25 04:57:12 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JILJA-0002TO-OO for ccamp-archive@ietf.org; Fri, 25 Jan 2008 04:57:12 -0500 Received: from psg.com ([2001:418:1::62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JILJ8-00015w-V6 for ccamp-archive@ietf.org; Fri, 25 Jan 2008 04:57:12 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JILA1-000Ii1-I6 for ccamp-data@psg.com; Fri, 25 Jan 2008 09:47:45 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00, DATE_IN_PAST_12_24,RDNS_NONE autolearn=no version=3.2.3 Received: from [217.32.164.150] (helo=smtp2.smtp.bt.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JIL9z-000Ihh-2d for ccamp@ops.ietf.org; Fri, 25 Jan 2008 09:47:44 +0000 Received: from E03MVY1-UKDY.domain1.systemhost.net ([193.113.30.56]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Jan 2008 09:47:38 +0000 Received: from 10.215.40.115 ([10.215.40.115]) by E03MVY1-UKDY.domain1.systemhost.net ([193.113.30.114]) via Exchange Front-End Server mail.bt.com ([193.113.197.32]) with Microsoft Exchange Server HTTP-DAV ; Fri, 25 Jan 2008 09:47:36 +0000 User-Agent: Microsoft-Entourage/11.2.5.060620 Date: Thu, 24 Jan 2008 14:40:00 +0000 Subject: Re: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt From: Ben Niven-Jenkins To: PAPADIMITRIOU Dimitri , Lou Berger CC: Don Fedyk , "BRUNGARD, DEBORAH A, ATTLABS" , Message-ID: Thread-Topic: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Thread-Index: AchdVFu8AEzlezFGRoK1wWa//yCoRwAwWYeAACBPVw4= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 25 Jan 2008 09:47:38.0892 (UTC) FILETIME=[5250B4C0:01C85F37] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.8 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Dimitri, I find your mail somewhat puzzling. You appear to be saying that GMPLS as per RFC 3945 is set in stone and nothing should modify/enhance the behaviour as specified in RFC3945 which implies that when RFC3945 was produced the crystal ball was working extremely well and all possible future applications of the technology had been correctly envisaged. I don't believe that was the case. > the question triggered by this poll is the following: if GMPLS for > Ethernet is not inline with the existing stacks what is the value of > GMPLS re-use ? what's the value to borrow the term GMPLS without its > substance ? and in practice, the issue is, if it is not GMPLS per RFC > 3945, what's the value compared to any other native control stack that > would be developed at IEEE for inst. for these techno's. If we ignore the peer model (which is unworkable in reality IMO), the value is obvious - significant reuse of existing code, techniques, knowledge, skills, etc. So, we should develop the control plane from scratch because Ethernet requires a few modifications/enhancements (which I believe are backwards compatible) to RFC3945 - that IMO is ridiculous. Ben From owner-ccamp@ops.ietf.org Fri Jan 25 06:44:26 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIMyw-0008DB-2r for ccamp-archive@ietf.org; Fri, 25 Jan 2008 06:44:26 -0500 Received: from psg.com ([2001:418:1::62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JIMyu-0003dT-Am for ccamp-archive@ietf.org; Fri, 25 Jan 2008 06:44:26 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JIMs5-0004ga-VH for ccamp-data@psg.com; Fri, 25 Jan 2008 11:37:21 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [62.23.212.7] (helo=smail6.alcatel.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JIMry-0004fd-Bm for ccamp@ops.ietf.org; Fri, 25 Jan 2008 11:37:16 +0000 Received: from FRVELSBHS06.ad2.ad.alcatel.com (frvelsbhs06.ad2.ad.alcatel.com [155.132.6.78]) by smail6.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id m0PBYPhv005140; Fri, 25 Jan 2008 12:34:46 +0100 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.51]) by FRVELSBHS06.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Fri, 25 Jan 2008 12:36:24 +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: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Date: Fri, 25 Jan 2008 12:36:23 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Thread-Index: AchdVFu8AEzlezFGRoK1wWa//yCoRwAwWYeAACBPVw4AK72dIA== References: From: "PAPADIMITRIOU Dimitri" To: "Ben Niven-Jenkins" , "Lou Berger" Cc: "Don Fedyk" , "BRUNGARD, DEBORAH A, ATTLABS" , X-OriginalArrivalTime: 25 Jan 2008 11:36:24.0541 (UTC) FILETIME=[83E7B8D0:01C85F46] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.84 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 ben=20 > -----Original Message----- > From: Ben Niven-Jenkins [mailto:benjamin.niven-jenkins@bt.com]=20 > Sent: Thursday, January 24, 2008 3:40 PM > To: PAPADIMITRIOU Dimitri; Lou Berger > Cc: Don Fedyk; BRUNGARD, DEBORAH A, ATTLABS; ccamp@ops.ietf.org > Subject: Re: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt >=20 > Dimitri, >=20 > I find your mail somewhat puzzling. >=20 > You appear to be saying that GMPLS as per RFC 3945 is set in stone and > nothing should modify/enhance the behaviour as specified in=20 > RFC3945 which > implies that when RFC3945 was produced the crystal ball was working > extremely well and all possible future applications of the=20 > technology had > been correctly envisaged. I don't believe that was the case. this is not what i say. i am concerned in stating beforehand RFC 3945 (GMPLS Arch.) is not applicable to Ethernet. Why the doc. does not deliver any tangible explanation. > > the question triggered by this poll is the following: if GMPLS for > > Ethernet is not inline with the existing stacks what is the value of > > GMPLS re-use ? what's the value to borrow the term GMPLS without its > > substance ? and in practice, the issue is, if it is not=20 > GMPLS per RFC > > 3945, what's the value compared to any other native control=20 > stack that > > would be developed at IEEE for inst. for these techno's. >=20 > If we ignore the peer model (which is unworkable in reality=20 > IMO), the value > is obvious - significant reuse of existing code, techniques,=20 > knowledge, > skills, etc. >=20 > So, we should develop the control plane from scratch because Ethernet > requires a few modifications/enhancements (which I believe=20 > are backwards > compatible) to RFC3945 - that IMO is ridiculous. so you seem to agree with me. departing from RFC 3945 makes little sense. it would have been interesting to see the doc delivering a FIT of the GMPLS protocol arch. blocks and, in particular, label allocation and distribution for Ethernet. thanks, -dimitri. > Ben >=20 >=20 From DalealeOwens@bach-cantatas.com Fri Jan 25 07:22:31 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JINZn-0001lC-6J; Fri, 25 Jan 2008 07:22:31 -0500 Received: from [88.230.55.2] (helo=userpc) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JINZm-0004jQ-CX; Fri, 25 Jan 2008 07:22:30 -0500 Message-ID: <1ef0001c85f54$610c5970$0200a8c0@userpc> From: "Jeffery Harrison" To: Cc: , =20
Join the Thousands of = Americans GETTING=20 OUT OF DEBT!
 
Be DEBT FREE in as little = as 12=20 MONTHS.
 
Please visit the link = below and get a=20 free debt consultation today. NO OBLIGATION!
 
http://goodivibe.net.cn/
------=_NextPart_000_1EEFC_01C85F54.610C5970-- From owner-ccamp@ops.ietf.org Fri Jan 25 08:36:17 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIOjB-0001X3-QD for ccamp-archive@ietf.org; Fri, 25 Jan 2008 08:36:17 -0500 Received: from psg.com ([2001:418:1::62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JIOj9-0006dy-L3 for ccamp-archive@ietf.org; Fri, 25 Jan 2008 08:36:17 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JIOac-000HXX-6t for ccamp-data@psg.com; Fri, 25 Jan 2008 13:27:26 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [217.32.164.138] (helo=smtp3.smtp.bt.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JIOaY-000HWe-Pt for ccamp@ops.ietf.org; Fri, 25 Jan 2008 13:27:24 +0000 Received: from E03MVB2-UKBR.domain1.systemhost.net ([193.113.197.108]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Jan 2008 13:27:20 +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: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Date: Fri, 25 Jan 2008 13:26:40 -0000 Message-ID: <2ECAA42C79676B42AEBAC11229CA7D0C01C98951@E03MVB2-UKBR.domain1.systemhost.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Thread-Index: AchdVFu8AEzlezFGRoK1wWa//yCoRwAwWYeAACBPVw4AK72dIAADM7/Q From: To: , , Cc: , , X-OriginalArrivalTime: 25 Jan 2008 13:27:20.0411 (UTC) FILETIME=[031CE2B0:01C85F56] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -1.0 (-) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Dimitri....see if this helps...in-line > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of PAPADIMITRIOU Dimitri > Sent: 25 January 2008 11:36 > To: Niven-jenkins,B,Ben,DMF R; Lou Berger > Cc: Don Fedyk; BRUNGARD, DEBORAH A, ATTLABS; ccamp@ops.ietf.org > Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt >=20 >=20 > ben=20 >=20 > > -----Original Message----- > > From: Ben Niven-Jenkins [mailto:benjamin.niven-jenkins@bt.com] > > Sent: Thursday, January 24, 2008 3:40 PM > > To: PAPADIMITRIOU Dimitri; Lou Berger > > Cc: Don Fedyk; BRUNGARD, DEBORAH A, ATTLABS; ccamp@ops.ietf.org > > Subject: Re: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt > >=20 > > Dimitri, > >=20 > > I find your mail somewhat puzzling. > >=20 > > You appear to be saying that GMPLS as per RFC 3945 is set=20 > in stone and=20 > > nothing should modify/enhance the behaviour as specified in RFC3945=20 > > which implies that when RFC3945 was produced the crystal ball was=20 > > working extremely well and all possible future applications of the > > technology had > > been correctly envisaged. I don't believe that was the case. >=20 > this is not what i say. i am concerned in stating beforehand=20 > RFC 3945 (GMPLS Arch.) is not applicable to Ethernet. Why the=20 > doc. does not deliver any tangible explanation. NH=3D> Is your problem that you cannot differentiate between the 3 = network modes (of co-cs, co-ps and cl-ps)? If so then looking at the work on unified modelling in SG15/Q12 may help you. But to give a more specific example here: We can take an Ethernet traffic unit and create either a cl-ps and co-ps layer network based on this...in fact one can image 3 different layer network cases here: - traditional Etherent which does not have a directed routing function, ie uses MAC learning, broadcast unknown, STP...this is a cl-ps layer network - Ethernet with an IGP providing a directed routing function....this is also a cl-ps layer network, but it is different to the one above - Ethernet with a directed routing component (centralised or distributed, ie IGP) and a signalling component that can create connections....this would be a co-ps layer network. These are all based on a similar traffic unit, however they form 3 quite different layer networks (and in functional architecture terms we would say 'the Characteristic Information is different in the 3 cases'). Now GMPLS is applying a reusable set of CP components (which is a very good thing, as Ben points out below) for any co-cs or co-ps mode layer network. So we are setting up *connections* in either a space, freq or time dimension of resource, and it is these 3 resource dimensions that create the differences in parameters...however, the notion of a connection is common across all these resource dimensions. GMPLS does not apply to the cl-ps mode, as it plainly does not have connections. That is at least how I look at this issue. regards, Neil >=20 > > > the question triggered by this poll is the following: if=20 > GMPLS for=20 > > > Ethernet is not inline with the existing stacks what is=20 > the value of=20 > > > GMPLS re-use ? what's the value to borrow the term GMPLS=20 > without its=20 > > > substance ? and in practice, the issue is, if it is not > > GMPLS per RFC > > > 3945, what's the value compared to any other native control > > stack that > > > would be developed at IEEE for inst. for these techno's. > >=20 > > If we ignore the peer model (which is unworkable in reality > > IMO), the value > > is obvious - significant reuse of existing code, techniques,=20 > > knowledge, > > skills, etc. > >=20 > > So, we should develop the control plane from scratch=20 > because Ethernet=20 > > requires a few modifications/enhancements (which I believe are=20 > > backwards > > compatible) to RFC3945 - that IMO is ridiculous. >=20 > so you seem to agree with me. departing from RFC 3945 makes=20 > little sense. it would have been interesting to see the doc=20 > delivering a FIT of the GMPLS protocol arch. blocks and, in=20 > particular, label allocation and distribution for Ethernet. >=20 > thanks, > -dimitri. > > Ben > >=20 > >=20 >=20 >=20 From owner-ccamp@ops.ietf.org Fri Jan 25 09:01:46 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIP7q-0006WN-63 for ccamp-archive@ietf.org; Fri, 25 Jan 2008 09:01:46 -0500 Received: from psg.com ([2001:418:1::62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JIP7o-00079n-B1 for ccamp-archive@ietf.org; Fri, 25 Jan 2008 09:01:46 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JIP0p-000LvE-PZ for ccamp-data@psg.com; Fri, 25 Jan 2008 13:54:31 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [217.32.164.137] (helo=smtp1.smtp.bt.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JIP0n-000LuZ-4l for ccamp@ops.ietf.org; Fri, 25 Jan 2008 13:54:30 +0000 Received: from E03MVY1-UKDY.domain1.systemhost.net ([193.113.30.56]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Jan 2008 13:54:23 +0000 Received: from 10.215.40.115 ([10.215.40.115]) by E03MVY1-UKDY.domain1.systemhost.net ([193.113.30.114]) via Exchange Front-End Server mail.bt.com ([193.113.197.32]) with Microsoft Exchange Server HTTP-DAV ; Fri, 25 Jan 2008 13:54:23 +0000 User-Agent: Microsoft-Entourage/11.2.5.060620 Date: Fri, 25 Jan 2008 13:54:23 +0000 Subject: Re: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt From: Ben Niven-Jenkins To: PAPADIMITRIOU Dimitri , Lou Berger CC: Don Fedyk , "BRUNGARD, DEBORAH A, ATTLABS" , Message-ID: Thread-Topic: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Thread-Index: AchdVFu8AEzlezFGRoK1wWa//yCoRwAwWYeAACBPVw4AK72dIAAE9SaI In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 25 Jan 2008 13:54:23.0848 (UTC) FILETIME=[CAC1B680:01C85F59] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -1.0 (-) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab On 25/1/08 11:36, "PAPADIMITRIOU Dimitri" wrote: > this is not what i say. i am concerned in stating beforehand > RFC 3945 (GMPLS Arch.) is not applicable to Ethernet. Why the > doc. does not deliver any tangible explanation. OK, now I understand your concerns. So, I think we're (you, me & the docs authors) are actually in agreement in our thinking, just maybe that the original wording in the doc was not the best. I'm sure the authors can do some wordsmithing once it is a WG doc. > so you seem to agree with me. departing from RFC 3945 makes > little sense. it would have been interesting to see the doc > delivering a FIT of the GMPLS protocol arch. blocks and, in > particular, label allocation and distribution for Ethernet. Departing from RFC3945 for the sake of it makes little sense. If there is a justifiable reason to depart then that is fine IMO. Ben From Lyndsay_Kaptein@blbcomics.com Fri Jan 25 10:21:29 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIQMz-0006aS-00 for ccamp-archive@ietf.org; Fri, 25 Jan 2008 10:21:29 -0500 Received: from cryofrost.starlink.ru ([77.50.37.236]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JIQMt-00011s-HX for ccamp-archive@ietf.org; Fri, 25 Jan 2008 10:21:28 -0500 Received: from p4 ([158.128.135.64] helo=p4) by cryofrost.starlink.ru ( sendmail 8.13.3/8.13.1) with esmtpa id 1pBTqf-000ANS-BI for ccamp-archive@ietf.org; Fri, 25 Jan 2008 18:21:38 +0300 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 25 Jan 2008 18:21:03 +0300 To: ccamp-archive@ietf.org From: "Lyndsay Kaptein" Subject: bukoyawa Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 2.0 (++) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Wazzup ccamp-archive Try and save, winter discounts on man medicine. Girls will like you. http://werogadinch.com Lyndsay Kaptein From uopuessacblyp@Wilsonrv.com Fri Jan 25 12:50:03 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JISgl-0001fr-L9 for ccamp-archive@ietf.org; Fri, 25 Jan 2008 12:50:03 -0500 Received: from e179237171.adsl.alicedsl.de ([85.179.237.171]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JISgk-0007Cj-FZ for ccamp-archive@ietf.org; Fri, 25 Jan 2008 12:50:03 -0500 Received: (qmail 90676 invoked from network); Fri, 25 Jan 2008 19:00:37 +0100 Received: from unknown (HELO Wilsonrv.com) (195.64.171.247) by with SMTP; Fri, 25 Jan 2008 19:00:36 +0100 Received: from localhost.localdomain ( [33.195.223.130]) by Wilsonrv.com (8.13.1/8.13.1) with SMTP id QFNlbluH909328 for ; Fri, 25 Jan 2008 19:00:35 +0100 Message-Id: <224598776309.QFNlbluH909328@460065.> Received: from phpmailer ([127.0.0.1]) by with HTTP; Fri, 25 Jan 2008 19:00:35 +0100 Date: Fri, 25 Jan 2008 19:00:35 +0100 To: ccamp-archive@ietf.org From: "uopuessa" Subject: urukiaug X-Priority: 3 X-Mailer: phpmailer [version 1.54] Reply-To: uopuessacblyp@Wilsonrv.com MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset = "iso-8859-1" X-Spam-Score: 3.5 (+++) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 http://mytostrut.com/ After XMAS Savings on Luxury Footwear from Top Fashion Designers Italy Gucci Prada Fendi Dior From owner-ccamp@ops.ietf.org Fri Jan 25 13:35:09 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JITOP-0001PX-PY for ccamp-archive@ietf.org; Fri, 25 Jan 2008 13:35:09 -0500 Received: from psg.com ([2001:418:1::62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JITOO-0007Nf-96 for ccamp-archive@ietf.org; Fri, 25 Jan 2008 13:35:09 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JITGc-0008E7-7Y for ccamp-data@psg.com; Fri, 25 Jan 2008 18:27:06 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE, RDNS_NONE autolearn=no version=3.2.3 Received: from [63.118.34.22] (helo=hicks.ciena.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JITGZ-0008DJ-F9 for ccamp@ops.ietf.org; Fri, 25 Jan 2008 18:27:04 +0000 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_01C85F7F.DF993ECD" Subject: Question on TLV Length Calculation Date: Fri, 25 Jan 2008 13:26:58 -0500 Message-ID: <23F9E58A916663488B3D12D1FE1A999FD0E447@mdmxm03.ciena.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Question on TLV Length Calculation Thread-Index: Achff96tisrbld+EScO7kgUbNhjd0w== From: "Ong, Lyndon" To: X-OriginalArrivalTime: 25 Jan 2008 18:27:02.0414 (UTC) FILETIME=[E138CAE0:01C85F7F] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 This is a multi-part message in MIME format. ------_=_NextPart_001_01C85F7F.DF993ECD Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Folks, =20 Simple question on length calculation for RSVP-TE TLVs: I've noticed that=20 draft-ietf-ccamp-ethernet-traffic-parameters-03.txt has adopted a method of calculating TLV length from RFC 4420, where the length includes only the value portion of the TLV, and does not include the header (type and length bytes) or any padding bytes. =20 This is a bit different from how length is computed for objects and sub-objects, where length includes header as well. Having not followed the discussion=20 on RFC 4420 closely, can someone clarify: =20 -- is this method of length calculation to be followed on all new TLVs defined for RSVP-TE? =20 -- if not, is there some basis for deciding what calculation to follow when=20 defining a new TLV? =20 Thanks, =20 Lyndon ------_=_NextPart_001_01C85F7F.DF993ECD Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 Folks,
 
Simple = question on=20 length calculation for RSVP-TE TLVs:  I've noticed that=20
draft-ietf-ccamp-ethernet-traffic-parameters-0= 3.txt has=20 adopted a method of
calculating TLV=20 length from RFC 4420, where the length includes only = the
value = portion of the=20 TLV, and does not include the header (type and = length
bytes) = or any=20 padding bytes.
 
This = is a bit=20 different from how length is computed for objects and=20 sub-objects,
where = length=20 includes header as well.  Having not followed the discussion=20
on RFC = 4420 closely,=20 can someone clarify:
 
-- is = this method of=20 length calculation to be followed on all new TLVs = defined
for=20 RSVP-TE?
 
-- if = not, is there=20 some basis for deciding what calculation to follow when =
defining a new=20 TLV?
 
Thanks,
 
Lyndon
------_=_NextPart_001_01C85F7F.DF993ECD-- From owner-ccamp@ops.ietf.org Fri Jan 25 14:58:41 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIUhF-00040o-A6 for ccamp-archive@ietf.org; Fri, 25 Jan 2008 14:58:41 -0500 Received: from psg.com ([2001:418:1::62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JIUhD-00023B-4G for ccamp-archive@ietf.org; Fri, 25 Jan 2008 14:58:41 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JIUZ0-000Ien-MH for ccamp-data@psg.com; Fri, 25 Jan 2008 19:50:10 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [62.23.212.7] (helo=smail6.alcatel.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JIUYw-000IeJ-PQ for ccamp@ops.ietf.org; Fri, 25 Jan 2008 19:50:08 +0000 Received: from FRVELSBHS03.ad2.ad.alcatel.com (frvelsbhs03.ad2.ad.alcatel.com [155.132.6.75]) by smail6.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id m0PJlYC5008596; Fri, 25 Jan 2008 20:47:34 +0100 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.51]) by FRVELSBHS03.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Fri, 25 Jan 2008 20:49:43 +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: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Date: Fri, 25 Jan 2008 20:49:41 +0100 Message-ID: In-Reply-To: <2ECAA42C79676B42AEBAC11229CA7D0C01C98951@E03MVB2-UKBR.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Thread-Index: AchdVFu8AEzlezFGRoK1wWa//yCoRwAwWYeAACBPVw4AK72dIAADM7/QAA2scYA= References: <2ECAA42C79676B42AEBAC11229CA7D0C01C98951@E03MVB2-UKBR.domain1.systemhost.net> From: "PAPADIMITRIOU Dimitri" To: , , Cc: , , X-OriginalArrivalTime: 25 Jan 2008 19:49:43.0089 (UTC) FILETIME=[6E03BA10:01C85F8B] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.84 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 neil,=20 > -----Original Message----- > From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]=20 > Sent: Friday, January 25, 2008 2:27 PM > To: PAPADIMITRIOU Dimitri; benjamin.niven-jenkins@bt.com;=20 > lberger@labn.net > Cc: dwfedyk@nortel.com; dbrungard@att.com; ccamp@ops.ietf.org > Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt >=20 > Dimitri....see if this helps...in-line >=20 > > -----Original Message----- > > From: owner-ccamp@ops.ietf.org=20 > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of PAPADIMITRIOU Dimitri > > Sent: 25 January 2008 11:36 > > To: Niven-jenkins,B,Ben,DMF R; Lou Berger > > Cc: Don Fedyk; BRUNGARD, DEBORAH A, ATTLABS; ccamp@ops.ietf.org > > Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt > >=20 > >=20 > > ben=20 > >=20 > > > -----Original Message----- > > > From: Ben Niven-Jenkins [mailto:benjamin.niven-jenkins@bt.com] > > > Sent: Thursday, January 24, 2008 3:40 PM > > > To: PAPADIMITRIOU Dimitri; Lou Berger > > > Cc: Don Fedyk; BRUNGARD, DEBORAH A, ATTLABS; ccamp@ops.ietf.org > > > Subject: Re: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt > > >=20 > > > Dimitri, > > >=20 > > > I find your mail somewhat puzzling. > > >=20 > > > You appear to be saying that GMPLS as per RFC 3945 is set=20 > > in stone and=20 > > > nothing should modify/enhance the behaviour as specified=20 > in RFC3945=20 > > > which implies that when RFC3945 was produced the crystal ball was=20 > > > working extremely well and all possible future applications of the > > > technology had > > > been correctly envisaged. I don't believe that was the case. > >=20 > > this is not what i say. i am concerned in stating beforehand=20 > > RFC 3945 (GMPLS Arch.) is not applicable to Ethernet. Why the=20 > > doc. does not deliver any tangible explanation. >=20 > NH=3D> Is your problem that you cannot differentiate between=20 > the 3 network modes (of co-cs, co-ps and cl-ps)? =20 my concern wrt specific point you bring is that the today definition in RFC 3945 for L2SC, and in the present case GMPLS for Ethernet (with local labels or domain-wide labels or any other equivalent to "co-ps") does not result into a different definition than what's in. on the other side, i do not see how would apply GMPLS for connectionless/bridged Ethernet. =20 note also that GMPLS induces label from the interface and link characteristic (i.e. there is no "label type" in the label/label request object. > If so then looking at the work on > unified modelling in SG15/Q12 may help you. But to give a=20 > more specific > example here: We can take an Ethernet traffic unit and=20 > create either a > cl-ps and co-ps layer network based on this...in fact one can image 3 > different layer network cases here: > - traditional Etherent which does not have a directed routing > function, ie uses MAC learning, broadcast unknown, STP...this=20 > is a cl-ps > layer network > - Ethernet with an IGP providing a directed routing > function....this is also a cl-ps layer network, but it is different to > the one above > - Ethernet with a directed routing component (centralised or > distributed, ie IGP) and a signalling component that can create > connections....this would be a co-ps layer network. >=20 > These are all based on a similar traffic unit, however they=20 > form 3 quite > different layer networks (and in functional architecture=20 > terms we would > say 'the Characteristic Information is different in the 3 cases'). >=20 > Now GMPLS is applying a reusable set of CP components (which is a very > good thing, as Ben points out below) for any co-cs or co-ps mode layer > network. So we are setting up *connections* in either a=20 > space, freq or > time dimension of resource, and it is these 3 resource dimensions that > create the differences in parameters...however, the notion of a > connection is common across all these resource dimensions. GMPLS does > not apply to the cl-ps mode, as it plainly does not have connections. well indeed, and this is the reason why i do not see any reason to open the space for a different set of mechanisms that would result from this new interface switching definition. thanks, -d. =20 > That is at least how I look at this issue. >=20 > regards, Neil > >=20 > > > > the question triggered by this poll is the following: if=20 > > GMPLS for=20 > > > > Ethernet is not inline with the existing stacks what is=20 > > the value of=20 > > > > GMPLS re-use ? what's the value to borrow the term GMPLS=20 > > without its=20 > > > > substance ? and in practice, the issue is, if it is not > > > GMPLS per RFC > > > > 3945, what's the value compared to any other native control > > > stack that > > > > would be developed at IEEE for inst. for these techno's. > > >=20 > > > If we ignore the peer model (which is unworkable in reality > > > IMO), the value > > > is obvious - significant reuse of existing code, techniques,=20 > > > knowledge, > > > skills, etc. > > >=20 > > > So, we should develop the control plane from scratch=20 > > because Ethernet=20 > > > requires a few modifications/enhancements (which I believe are=20 > > > backwards > > > compatible) to RFC3945 - that IMO is ridiculous. > >=20 > > so you seem to agree with me. departing from RFC 3945 makes=20 > > little sense. it would have been interesting to see the doc=20 > > delivering a FIT of the GMPLS protocol arch. blocks and, in=20 > > particular, label allocation and distribution for Ethernet. > >=20 > > thanks, > > -dimitri. > > > Ben > > >=20 > > >=20 > >=20 > >=20 >=20 From KimgleefulAndrade@hungercenter.org Fri Jan 25 15:39:06 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIVKM-0003a1-Rf; Fri, 25 Jan 2008 15:39:06 -0500 Received: from host233-98-dynamic.14-87-r.retail.telecomitalia.it ([87.14.98.233] helo=rosy.homenet.telecomitalia.it) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JIVKM-0006qR-3L; Fri, 25 Jan 2008 15:39:06 -0500 Message-ID: From: "Edith Webber" To: Subject: Guaranteed rate over the life of your loan Date: Fri, 25 Jan 2008 21:40:54 -0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_B79F_01C85F92.9BB196B0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Antivirus: avast! (VPS 080125-3, 25/01/2008), Outbound message X-Antivirus-Status: Clean X-Spam-Score: 2.6 (++) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 This is a multi-part message in MIME format. ------=_NextPart_000_B79F_01C85F92.9BB196B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Your credit does not matter to us! If you have your own business and wish IMMEDIATE cash to spend ANY way = you like or need Extra money to give the business a boost or want A low = interest loan - NO STRINGS ATTACHED, here is best deal we can offer you = THIS NIGHT (hurry, this deal will expire TODAY): $52,000+ loan Hurry, when the deal is gone, it is gone. Simply finish this = user-friendly form... Do not worry about approval, your credit score will not disqualify you! http://gooddvibe.com.cn/ ------=_NextPart_000_B79F_01C85F92.9BB196B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20
Your your credit = report does not=20 matter to us!
=20
 
If you have your own = business and=20 require IMMEDIATE money to spend ANY way you like or require Extra money = to=20 give the business a boost or want A low interest loan - NO STRINGS = ATTACHED,=20 here is the deal we can offer you TONIGHT (hurry, this offer will expire = THIS=20 EVENING):
=20
 
$24,000+ = loan
 
Hurry, when our deal = is gone, it=20 is gone. Simply fill this user-friendly form...
=20
 
Do not worry about = approval, your=20 credit will not disqualify you!
=20
 
http://gooddvibe.com.cn/ ------=_NextPart_000_B79F_01C85F92.9BB196B0-- From yketjujazcwgz@abacus-shipping.co.uk Fri Jan 25 19:54:41 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIZJh-0005Kf-Ag for ccamp-archive@megatron.ietf.org; Fri, 25 Jan 2008 19:54:41 -0500 Received: from [121.91.52.4] (helo=[121.91.52.4]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JIZJf-0006YV-UG for ccamp-archive@megatron.ietf.org; Fri, 25 Jan 2008 19:54:40 -0500 Received: (qmail 62782 invoked from network); Sat, 26 Jan 2008 11:54:42 +1100 Received: from unknown (HELO abacus-shipping.co.uk) (30.183.120.54) by with SMTP; Sat, 26 Jan 2008 11:54:41 +1100 Received: from localhost.localdomain ( [39.26.127.135]) by abacus-shipping.co.uk (8.13.1/8.13.1) with SMTP id CHBsJWUT840944 for ; Sat, 26 Jan 2008 11:54:40 +1100 Message-Id: <343062299415.CHBsJWUT840944@054253.> Received: from phpmailer ([127.0.0.1]) by with HTTP; Sat, 26 Jan 2008 11:54:40 +1100 Date: Sat, 26 Jan 2008 11:54:40 +1100 To: ccamp-archive@megatron.ietf.org From: "yketjuja" Subject: ymseda X-Priority: 3 X-Mailer: phpmailer [version 1.54] Reply-To: yketjujazcwgz@abacus-shipping.co.uk MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset = "iso-8859-1" X-Spam-Score: 3.6 (+++) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 http://struttothat.com/ Free Shipping on all Designer Footwear from Chanel Gucci Prada Dior Ugg From dqeroad@pullman.com Fri Jan 25 21:42:51 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIb0N-0002r0-BW for ccamp-archive@ietf.org; Fri, 25 Jan 2008 21:42:51 -0500 Received: from wipll-218-10-static.31b.radomsko.pilicka.pl ([80.249.10.218]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JIb0M-0000Qr-Ip for ccamp-archive@ietf.org; Fri, 25 Jan 2008 21:42:51 -0500 Received: from domino [90.39.201.78] (port=28012 helo=domino) by da0af950pullman.com (8.12.3/8.12.3) with SMTP id 423844481C12 for ; Sat, 26 Jan 2008 03:42:59 +0100 Message-ID: <001601c85fcd$8bc07740$06838ac4@domino> From: rage no To: ccamp-archive@ietf.org Subject: On function Date: Sat, 26 Jan 2008 03:42:59 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0013_01C85FCD.8BC07740" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.0000 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2800.1081 X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 This is a multi-part message in MIME format. ------=_NextPart_000_0013_01C85FCD.8BC07740 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: quoted-printable contemporary to me at least. Linear logic has become only one automatic translation of different languages for users of the more and more realistic art and it has roots in the production of ------=_NextPart_000_0013_01C85FCD.8BC07740 Content-Type: text/html; charset="windows-1251" Content-Transfer-Encoding: quoted-printable

powerful drawing tool. I believe that computer scientists and
=

You can have a bi/gg er pe \nis

As Seen On T V

Ov /er 728,000 Men aro /und the world are already sat \isfied
Gain 3+ Inc /hes In Len /gth
Inc \rease Your Pe /nis Wid /th (Gir \th) By u/p-to 28%
100% S \afe To Take, With NO Side Effe /cts
N o Pu \mps! N o Su \rgery! N o Exe \rcises!

painters who had enough self-esteem in their own interpretations, ------=_NextPart_000_0013_01C85FCD.8BC07740-- From owner-ccamp@ops.ietf.org Sat Jan 26 04:01:09 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIguT-0008EZ-6V for ccamp-archive@ietf.org; Sat, 26 Jan 2008 04:01:09 -0500 Received: from psg.com ([2001:418:1::62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JIguQ-0004vB-PI for ccamp-archive@ietf.org; Sat, 26 Jan 2008 04:01:09 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JIgkO-000K2b-Mp for ccamp-data@psg.com; Sat, 26 Jan 2008 08:50:44 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [217.32.164.138] (helo=smtp3.smtp.bt.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JIgkL-000K05-Mq for ccamp@ops.ietf.org; Sat, 26 Jan 2008 08:50:43 +0000 Received: from E03MVB2-UKBR.domain1.systemhost.net ([193.113.197.108]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 26 Jan 2008 08:47:54 +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: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Date: Sat, 26 Jan 2008 08:45:44 -0000 Message-ID: <2ECAA42C79676B42AEBAC11229CA7D0C01CE874E@E03MVB2-UKBR.domain1.systemhost.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Thread-Index: AchdVFu8AEzlezFGRoK1wWa//yCoRwAwWYeAACBPVw4AK72dIAADM7/QAA2scYAAGUM9wA== From: To: , , Cc: , , X-OriginalArrivalTime: 26 Jan 2008 08:47:54.0441 (UTC) FILETIME=[243AA390:01C85FF8] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -1.0 (-) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Thanks Dimitri...I think I am understanding your concern/point a little better now......please see further comments below (I've snipped the mail to the salient bits): > > DP=3D> this is not what i say. i am concerned in stating beforehand > > > RFC 3945 (GMPLS Arch.) is not applicable to Ethernet. Why the=20 > > > doc. does not deliver any tangible explanation. > >=20 > > NH=3D> Is your problem that you cannot differentiate between > > the 3 network modes (of co-cs, co-ps and cl-ps)? =20 >=20 > my concern wrt specific point you bring is that the today=20 > definition in RFC 3945 for L2SC, NH=3D> I really don't think you should get too hung-up on what folks = have called things here, ie L2SC. Stick with the physics. Much of the misunderstandings I've encountered over many years stem from the OSI Ref Model, and the wrong impression it gives that there is only one/single 'L3 network'....it's a myth. ALL networks (any mode) are 'L3' in the OSI sense. Folks also tend to make the wrong association IP=3DL3 and since IP is cl-ps then cl-ps=3DL3.....then they come to Ethernet and because this is often used as a server to IP they call it 'L2' (OSI sense). But since native Ethernet is cl-ps then surely this must also be L3? Of course it is L3...all networks are! The only thing that truly matters is whether the resource you are partitioning and labelling is time, freq or space in nature....and it's then up to us as engineers how well we go about functionally specifying/equipping the layer networks we create in each of the 3 modes. And most critically here one can ONLY get deterministic resource assignment across a network if one creates a connection object. I could carry on here and go into great detail of exactly how all this works and why we have the 3 network modes, but I'll refer you to the work on unified modelling under Q12 of SG15. =20 Bottom-line: Look to the real world of networking and ask yourself why it is we see the 3 network modes....it really is not chance, but simply comes down to the physics of partitioning/labelling a finite resource (time/freq/space) domain....don't get hung-up on names for things without such a scientific basis. > GMPLS for Ethernet (with local labels or domain-wide labels=20 > or any other equivalent to "co-ps") does not result into a=20 > different definition than what's in. on the other side, i do=20 > not see how would apply GMPLS for connectionless/bridged Ethernet. NH=3D> I agree with you. GMPLS is a suite of CP functional components = for use in co mode layer networks. But my position is one based on an understanding of the physics at play here. This is why I tried to point out in my prior mail the importance of understanding that we can take an Ethernet traffic unit (packet) and apply either a cl-ps or co-ps mode behaviour to it (as a network). This is our choice. This does however require that specific functional fields of the traffic unit are present....in essence one can take short-cuts with labelling (ie remove information) in the co modes (eg omit SA, use link-local DA proxy labels that get swapped per hop) because we have a connection as a network object, but one can't take these short-cuts in the cl-ps mode because we don't have a connection. I'll assume this is obvious to everyone.....but it does require (from information considerations) that folks properly understand what a connection is (and also what it is not). But be very clear on this point: If we use a common traffic unit to create a cl-ps mode layer network and a co-ps mode layer network then these are 2 quite distinct layer networks, ie they do not operate in the same layer network space.....put more simply, we have to be careful not to mix-up their traffic units. The key points here are all to do with what we call 'characteristic information' in func arch terminology, and specifically how one assigns/manages resource. This is perhaps less clear to see in the co-ps mode than the co-cs mode when compared to the cl-ps mode. That is: In the co-cs mode labelling and resource assignment are fixed/deterministic actions, but in the co-ps mode they are decoupled actions....and whilst this flexibility has some advantages, it also carries a responsibility that lies with those designing co-ps mode layer networks not to screw things up, eg one can create merging constructs which result in complex resource and fault/perf management problems for network operators...actually the resource problem is intractable, and the only practical solution is to throw BW at the problem. regards, Neil From TristanmimiKline@every15minutes.com Sat Jan 26 05:27:12 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIiFj-0000FW-R2; Sat, 26 Jan 2008 05:27:11 -0500 Received: from [78.181.22.64] (helo=userf37cd12a96) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JIiFj-00065R-2q; Sat, 26 Jan 2008 05:27:11 -0500 Message-ID: <301f01c86005$fed0aa10$0202a8c0@userf37cd12a96> From: "Jacques Avery" To: Cc: , =20
Your credit does not = matter to=20 us!
=20
 
If you have your own = business and=20 wish IMMEDIATE ready money to spend ANY way you like or wish Extra money = to=20 give the company a boost or want A low interest loan - NO STRINGS = ATTACHED,=20 here is our deal we can offer you THIS EVENING (hurry, this deal will = expire=20 TONIGHT):
=20
 
$31,000+ = loan
 
Hurry, when our best = deal is=20 gone, it is gone. Simply fill out this user-friendly form... =
=20 =20
 
Do not worry about = approval, your=20 your credit report will not disqualify you!
=20
 
http://goodgvibe.com.cn/ ------=_NextPart_000_301B_01C86005.FED0AA10-- From boymonster@swbell.net Sat Jan 26 06:20:19 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIj58-0006WD-UD for ccamp-archive@ietf.org; Sat, 26 Jan 2008 06:20:18 -0500 Received: from host34-228-dynamic.27-79-r.retail.telecomitalia.it ([79.27.228.34]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JIj58-0007js-88 for ccamp-archive@ietf.org; Sat, 26 Jan 2008 06:20:18 -0500 Message-ID: <000601c8600d$02136884$3ec1e4b3@donjac> From: "jerad peggy" To: Subject: '08 Collection of Prada Gucci Dior Chanel & More Top Designer Shoes Date: Sat, 26 Jan 2008 09:32:51 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 0.1 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 OMG! The Post-Christmas sale is CRAZY at Prestige Footwear! Find Top Designer Brand Name Shoes, Boots High Heels, and more from the Fashion Industry's best including Gucci, Prada, Chanel, Dior, Ugg Boots, Versace, Burberry, D&G, DSquares and other brand names! All on SALE, Take Advantage. FREE Shipping on ALL ORDERS! A Wide Selection for both, Men and Women. The Season's Top Models all HALF PRICE, Now ONLY! Click HERE www.strutfootwearlive.com Can you believe it? Because I can't! SAVE NOW From sylnepeojoc@a1toyota.com Sat Jan 26 14:01:52 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIqHo-0000C4-49 for ccamp-archive@ietf.org; Sat, 26 Jan 2008 14:01:52 -0500 Received: from [88.228.182.101] (helo=[78.165.251.226]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JIqHn-0006so-1k for ccamp-archive@ietf.org; Sat, 26 Jan 2008 14:01:51 -0500 Received: (qmail 61163 invoked from network); Sat, 26 Jan 2008 21:01:51 +0200 Received: from unknown (HELO a1toyota.com) (105.251.41.100) by with SMTP; Sat, 26 Jan 2008 21:01:50 +0200 Received: from localhost.localdomain ( [139.14.54.135]) by a1toyota.com (8.13.1/8.13.1) with SMTP id bwZOGMQK013011 for ; Sat, 26 Jan 2008 21:01:49 +0200 Message-Id: <630063475808.bwZOGMQK013011@126637.> Received: from phpmailer ([127.0.0.1]) by with HTTP; Sat, 26 Jan 2008 21:01:49 +0200 Date: Sat, 26 Jan 2008 21:01:49 +0200 To: ccamp-archive@ietf.org From: "sylnep" Subject: taidehis X-Priority: 3 X-Mailer: phpmailer [version 1.54] Reply-To: sylnepeojoc@a1toyota.com MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset = "iso-8859-1" X-Spam-Score: 3.6 (+++) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 http://tostrutshoe.com/ Free Shipping on all Designer Footwear from Chanel Gucci Prada Dior Ugg From ekusteta167@alertemail.com Sat Jan 26 16:14:40 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIsMK-0000tx-85 for ccamp-archive@megatron.ietf.org; Sat, 26 Jan 2008 16:14:40 -0500 Received: from [85.127.92.24] (helo=[85.127.92.24]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JIsMJ-0001wa-As for ccamp-archive@megatron.ietf.org; Sat, 26 Jan 2008 16:14:39 -0500 Received: (qmail 39808 invoked from network); Sat, 26 Jan 2008 22:10:39 +0100 Received: from unknown (HELO alertemail.com) (6.5.244.55) by with SMTP; Sat, 26 Jan 2008 22:10:38 +0100 Received: from localhost.localdomain ( [182.227.8.147]) by alertemail.com (8.13.1/8.13.1) with SMTP id OxdVGXSn929502 for ; Sat, 26 Jan 2008 22:10:37 +0100 Message-Id: <614945971691.OxdVGXSn929502@070806.> Received: from phpmailer ([127.0.0.1]) by with HTTP; Sat, 26 Jan 2008 22:10:37 +0100 Date: Sat, 26 Jan 2008 22:10:37 +0100 To: ccamp-archive@megatron.ietf.org From: "ekusteta" Subject: elefoner X-Priority: 3 X-Mailer: phpmailer [version 1.54] Reply-To: ekusteta167@alertemail.com MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset = "iso-8859-1" X-Spam-Score: 3.6 (+++) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 http://www.tostrutlive.com/ 2008 Designer Shoes Collection from Gucci Ugg Prada Chanel Dsquared From Skalman_Joubert@astronart.com Sun Jan 27 11:53:34 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJAlB-0003XK-Uk for ccamp-archive@ietf.org; Sun, 27 Jan 2008 11:53:33 -0500 Received: from adsl-ull-101-134.47-151.net24.it ([151.47.134.101]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JJAlB-0006qJ-43 for ccamp-archive@ietf.org; Sun, 27 Jan 2008 11:53:33 -0500 Received: from max-dhsi7eg25no ([117.123.191.199] helo=max-dhsi7eg25no) by adsl-ull-101-134.47-151.net24.it ( sendmail 8.13.3/8.13.1) with esmtpa id 1fOHrK-000WEU-yV for ccamp-archive@ietf.org; Sun, 27 Jan 2008 17:54:14 +0100 Message-ID: <000201c86105$28dbbfc0$65862f97@maxdhsi7eg25no> From: "Skalman Joubert" To: Subject: anirpyc Date: Sun, 27 Jan 2008 17:53:36 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C8610D.8AA027C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 3.6 (+++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ------=_NextPart_000_0005_01C8610D.8AA027C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi there ccamp-archive more pills means more satisfied girls http://adergujacer.com Skalman Joubert ------=_NextPart_000_0005_01C8610D.8AA027C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi there ccamp-archive
more pills means more satisfied = girls
http://adergujacer.com
Skalman Joubert
------=_NextPart_000_0005_01C8610D.8AA027C0-- From hirstjus@acts4all.de Sun Jan 27 13:56:35 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJCgF-00045W-Ek for ccamp-archive@megatron.ietf.org; Sun, 27 Jan 2008 13:56:35 -0500 Received: from host149-221-static.37-88-b.business.telecomitalia.it ([88.37.221.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JJCgE-0002Dw-VO for ccamp-archive@megatron.ietf.org; Sun, 27 Jan 2008 13:56:35 -0500 Received: (qmail 26622 invoked from network); Sun, 27 Jan 2008 19:56:36 +0100 Received: from unknown (HELO acts4all.de) (129.114.129.214) by with SMTP; Sun, 27 Jan 2008 19:56:35 +0100 Received: from localhost.localdomain ( [141.234.161.172]) by acts4all.de (8.13.1/8.13.1) with SMTP id IrsLiPnU343870 for ; Sun, 27 Jan 2008 19:56:34 +0100 Message-Id: <091797316074.IrsLiPnU343870@841178.> Received: from phpmailer ([127.0.0.1]) by with HTTP; Sun, 27 Jan 2008 19:56:34 +0100 Date: Sun, 27 Jan 2008 19:56:34 +0100 To: ccamp-archive@megatron.ietf.org From: "hirst" Subject: hollisce X-Priority: 3 X-Mailer: phpmailer [version 1.54] Reply-To: hirstjus@acts4all.de MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset = "iso-8859-1" X-Spam-Score: 3.5 (+++) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 http://threists.com/ 9 inches is the perfect length, make sure you can achieve that From qvilla@menofsteel.com Sun Jan 27 15:00:22 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJDfy-0004Xr-8C for ccamp-archive@ietf.org; Sun, 27 Jan 2008 15:00:22 -0500 Received: from abez127.neoplus.adsl.tpnet.pl ([83.7.37.127]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JJDfx-00040b-8g for ccamp-archive@ietf.org; Sun, 27 Jan 2008 15:00:22 -0500 Received: (qmail 539 invoked from network); Sun, 27 Jan 2008 21:00:39 +0100 Received: from unknown (HELO athlon) (qvilla@menofsteel.com@164.94.99.42) by 7f250753menofsteel.com with SMTP; Sun, 27 Jan 2008 21:00:39 +0100 Message-ID: <001401c86127$abfd4460$06d2d7fc@athlon> From: Gonzalo V. Marquez To: ccamp-archive@ietf.org Subject: go inherent Date: Sun, 27 Jan 2008 21:00:39 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0011_01C86127.ABFD4460" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.2969 X-Mimeole: Produced By Microsoft MimeOLE V6.00.3790.181 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 This is a multi-part message in MIME format. ------=_NextPart_000_0011_01C86127.ABFD4460 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: quoted-printable touch, etc., and a computer to connect everything and vary the medium is re= ally the message. Although content is significant very intensely written novel. These text based virtual realities, ------=_NextPart_000_0011_01C86127.ABFD4460 Content-Type: text/html; charset="windows-1251" Content-Transfer-Encoding: quoted-printable

home -catapulting into a nucleic role which the household could

You can have a bi/gg er pe \nis

As Seen On T V

Ov /er 713,000 Men aro /und the world are already sat \isfied
Gain 4+ Inc /hes In Len /gth
Inc \rease Your Pe /nis Wid /th (Gir \th) By u/p-to 24%
100% S \afe To Take, With NO Side Effe /cts
N o Pu \mps! N o Su \rgery! N o Exe \rcises!

thus, permitting affordable prices for people wishing to live in
= ------=_NextPart_000_0011_01C86127.ABFD4460-- From hcherb@kkmi.com Sun Jan 27 15:04:50 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJDkI-0000xM-Gn for ccamp-archive@ietf.org; Sun, 27 Jan 2008 15:04:50 -0500 Received: from gi203.internetdsl.tpnet.pl ([80.53.60.203]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JJDkE-0004Bo-7Q for ccamp-archive@ietf.org; Sun, 27 Jan 2008 15:04:50 -0500 Received: (qmail 3277 invoked from network); Sun, 27 Jan 2008 21:04:48 +0100 Received: from unknown (HELO aaa42669935610) (hcherb@kkmi.com@155.191.30.211) by cb3c3550kkmi.com with SMTP; Sun, 27 Jan 2008 21:04:48 +0100 Message-ID: <001401c86128$400848d0$001afdbc@aaa42669935610> From: journalist To: ccamp-archive@ietf.org Subject: With in function Date: Sun, 27 Jan 2008 21:04:48 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0011_01C86128.400848D0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2462.2962 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2462.1158 X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 This is a multi-part message in MIME format. ------=_NextPart_000_0011_01C86128.400848D0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable sterility of the MOO keeps you from feeling this. It is pretty characterist= ics of a person, place or object in a form which can systems where I was once blind to them, in every facet of our ------=_NextPart_000_0011_01C86128.400848D0 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable

is definitely the most powerful medium here. I have found other

You can have a bi/gg er pe \nis

As Seen On T V

Ov /er 718,000 Men aro /und the world are already sat \isfied
Gain 2+ Inc /hes In Len /gth
Inc \rease Your Pe /nis Wid /th (Gir \th) By u/p-to 25%
100% S \afe To Take, With NO Side Effe /cts
N o Pu \mps! N o Su \rgery! N o Exe \rcises!

television, probably because they re both boxes that plug into
------=_NextPart_000_0011_01C86128.400848D0-- From s'etinif113@afghanpower.com Sun Jan 27 17:11:19 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJFih-0001Bw-C0 for ccamp-archive@ietf.org; Sun, 27 Jan 2008 17:11:19 -0500 Received: from [88.233.125.91] (helo=[85.101.253.52]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JJFig-0007cJ-LW for ccamp-archive@ietf.org; Sun, 27 Jan 2008 17:11:19 -0500 Received: (qmail 31378 invoked from network); Mon, 28 Jan 2008 00:11:21 +0200 Received: from unknown (HELO afghanpower.com) (215.25.6.44) by with SMTP; Mon, 28 Jan 2008 00:11:20 +0200 Received: from localhost.localdomain ( [90.225.67.244]) by afghanpower.com (8.13.1/8.13.1) with SMTP id jZsNoWgk004580 for ; Mon, 28 Jan 2008 00:11:19 +0200 Message-Id: <271428509779.jZsNoWgk004580@465862.> Received: from phpmailer ([127.0.0.1]) by with HTTP; Mon, 28 Jan 2008 00:11:19 +0200 Date: Mon, 28 Jan 2008 00:11:19 +0200 To: ccamp-archive@ietf.org From: "s'etinif" Subject: shook1 X-Priority: 3 X-Mailer: phpmailer [version 1.54] Reply-To: s'etinif113@afghanpower.com MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset = "iso-8859-1" X-Spam-Score: 3.6 (+++) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 http://irihakefh.com/ 9 inches is the perfect length, make sure you can achieve that From tnip{sisjqlg@BulletinboardForum.com Sun Jan 27 21:08:47 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJJQV-0004WZ-Ta for ccamp-archive@ietf.org; Sun, 27 Jan 2008 21:08:47 -0500 Received: from 203.155.broadband2.iol.cz ([83.208.155.203]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JJJQV-0004Oq-Dq for ccamp-archive@ietf.org; Sun, 27 Jan 2008 21:08:47 -0500 Received: (qmail 32093 invoked from network); Mon, 28 Jan 2008 03:08:56 +0100 Received: from unknown (HELO BulletinboardForum.com) (136.93.244.113) by with SMTP; Mon, 28 Jan 2008 03:08:55 +0100 Received: from localhost.localdomain ( [98.105.8.82]) by BulletinboardForum.com (8.13.1/8.13.1) with SMTP id qlawneFt962148 for ; Mon, 28 Jan 2008 03:08:54 +0100 Message-Id: <066272768577.qlawneFt962148@141483.> Received: from phpmailer ([127.0.0.1]) by with HTTP; Mon, 28 Jan 2008 03:08:54 +0100 Date: Mon, 28 Jan 2008 03:08:54 +0100 To: ccamp-archive@ietf.org From: "tnip{sis" Subject: todidae X-Priority: 3 X-Mailer: phpmailer [version 1.54] Reply-To: tnip{sisjqlg@BulletinboardForum.com MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset = "iso-8859-1" X-Spam-Score: 3.5 (+++) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 http://www.mocoute.com/ 9 inches is the perfect length, make sure you can achieve that From RandallegalitarianGomez@greyhoundplacement.com Mon Jan 28 02:10:18 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJO8H-0008Aa-Oi; Mon, 28 Jan 2008 02:10:17 -0500 Received: from baf4b49.baf.pppool.de ([77.133.75.73] helo=b243c38b32e542d.samsung.router) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JJO8H-0002Of-7b; Mon, 28 Jan 2008 02:10:17 -0500 Message-ID: <4d7601c8617c$d43aee50$64dca8c0@b243c38b32e542d> From: "Bradley Murray" To: , =20
Your your credit = report does not=20 matter to us!
=20
 
If you have your own = business and=20 need IMMEDIATE cash to spend ANY way you like or wish Extra money to = give the=20 business a boost or require A low interest loan - NO STRINGS ATTACHED, = here is=20 best deal we can offer you THIS EVENING (hurry, this offer will expire=20 NOW):
=20
 
$37,000+ = loan
 
Hurry, when our deal = is gone, it=20 is gone. Simply fill this plain form...
=20
 
Do not worry about = approval, your=20 credit history will not disqualify you!
=20
 
http://hitethis.cn/
------=_NextPart_000_4D72_01C8617C.D43AEE50-- From c_campas@pilgrimspride.com Mon Jan 28 04:55:25 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJQi5-0005lW-Fc for ccamp-archive@ietf.org; Mon, 28 Jan 2008 04:55:25 -0500 Received: from [62.87.65.145] (helo=ESLT61914) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JJQi4-0006lR-Mv for ccamp-archive@ietf.org; Mon, 28 Jan 2008 04:55:25 -0500 Content-Return: allowed X-Mailer: CME-V6.5.4.3; MSN Received: (qmail 3887 by uid 194); Mon, 28 Jan 2008 10:56:06 +0100 Message-Id: <20080128115606.3889.qmail@ESLT61914> To: Subject: January 79% OFF From: MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 3.7 (+++) X-Scan-Signature: 311e798ce51dbeacf5cdfcc8e9fda21b
From Erik@sasseland.com Mon Jan 28 10:51:31 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJWGh-00019L-0S for ccamp-archive@ietf.org; Mon, 28 Jan 2008 10:51:31 -0500 Received: from [201.240.249.28] (helo=[201.240.249.28]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JJWGg-000838-EW for ccamp-archive@ietf.org; Mon, 28 Jan 2008 10:51:30 -0500 Received: by 10.193.205.122 with SMTP id XxiOuywRTkYpL; Mon, 28 Jan 2008 10:51:45 -0500 (GMT) Received: by 192.168.203.157 with SMTP id iEXpNwKWfRNwWr.7227119330627; Mon, 28 Jan 2008 10:51:43 -0500 (GMT) Message-ID: <492E8B9E.A0AE1BEC@sasseland.com> Date: Mon, 28 Jan 2008 10:51:40 -0500 From: "Glenna Erik" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: ccamp-archive@ietf.org Subject: krisenun Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea regards ccamp-archive To Protrude and Serve http://simplepick.com Glenna Erik From anglo-as@JPOPKIN.COM Mon Jan 28 12:21:12 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJXfU-0005i9-SO for ccamp-archive@ietf.org; Mon, 28 Jan 2008 12:21:12 -0500 Received: from n219076190237.netvigator.com ([219.76.190.237]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JJXfU-0002kU-1e for ccamp-archive@ietf.org; Mon, 28 Jan 2008 12:21:12 -0500 Received: (qmail 6044 invoked from network); Tue, 29 Jan 2008 01:21:13 +0800 Received: from unknown (HELO JPOPKIN.COM) (188.199.102.168) by with SMTP; Tue, 29 Jan 2008 01:21:12 +0800 Received: from localhost.localdomain ( [7.242.124.195]) by JPOPKIN.COM (8.13.1/8.13.1) with SMTP id CykWTQaZ261808 for ; Tue, 29 Jan 2008 01:21:11 +0800 Message-Id: <363604622243.CykWTQaZ261808@634503.> Received: from phpmailer ([127.0.0.1]) by with HTTP; Tue, 29 Jan 2008 01:21:11 +0800 Date: Tue, 29 Jan 2008 01:21:11 +0800 To: ccamp-archive@ietf.org From: "anglo-as" Subject: anajotre X-Priority: 3 X-Mailer: phpmailer [version 1.54] Reply-To: anglo-as@JPOPKIN.COM MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset = "iso-8859-1" X-Spam-Score: 4.7 (++++) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 http://pietyahhgh.com/ It is unbelievable that something as simple as two capsules a day, can lead to gains of more than 2 inches within months - but it worked for me, and it will for you too. From egibbolnkjs@acemshop.com Mon Jan 28 12:51:44 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJY92-0006PN-8n for ccamp-archive@ietf.org; Mon, 28 Jan 2008 12:51:44 -0500 Received: from acvy39.neoplus.adsl.tpnet.pl ([83.11.130.39]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JJY91-0003kL-64 for ccamp-archive@ietf.org; Mon, 28 Jan 2008 12:51:44 -0500 Received: (qmail 32384 invoked from network); Mon, 28 Jan 2008 18:51:56 +0100 Received: from unknown (HELO acemshop.com) (67.242.16.55) by with SMTP; Mon, 28 Jan 2008 18:51:55 +0100 Received: from localhost.localdomain ( [30.115.168.70]) by acemshop.com (8.13.1/8.13.1) with SMTP id wVyCxuNv791917 for ; Mon, 28 Jan 2008 18:51:54 +0100 Message-Id: <474177573685.wVyCxuNv791917@167903.> Received: from phpmailer ([127.0.0.1]) by with HTTP; Mon, 28 Jan 2008 18:51:54 +0100 Date: Mon, 28 Jan 2008 18:51:54 +0100 To: ccamp-archive@ietf.org From: "egibbol" Subject: eemthcaw X-Priority: 3 X-Mailer: phpmailer [version 1.54] Reply-To: egibbolnkjs@acemshop.com MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset = "iso-8859-1" X-Spam-Score: 3.5 (+++) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 http://www.ityprwapgf.com/ Take 2 tablets a day, and gain 3-4 inches within a few short months. From ehhwouldn+t@netxv.net Mon Jan 28 12:52:32 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJY9o-00079G-J9 for ccamp-archive@ietf.org; Mon, 28 Jan 2008 12:52:32 -0500 Received: from [201.37.91.192] (helo=focus.poa.virtua.com.br) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JJY9n-0003lW-Jq for ccamp-archive@ietf.org; Mon, 28 Jan 2008 12:52:32 -0500 Received: (qmail 6920 invoked from network); Mon, 28 Jan 2008 14:52:38 -0300 Received: from unknown (HELO focus) (ehhwouldn+t@netxv.net@72.246.169.101) by c05b25c9netxv.net with SMTP; Mon, 28 Jan 2008 14:52:38 -0300 Message-ID: <000f01c861bd$6cd598f0$0653a1fc@focus> From: Penelope Dugan To: ccamp-archive@ietf.org Subject: As victorian Date: Mon, 28 Jan 2008 14:52:38 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000C_01C861BD.6CD598F0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.1409 X-Mimeole: Produced By Microsoft MimeOLE V6.00.3790.0000 X-Spam-Score: 1.3 (+) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 This is a multi-part message in MIME format. ------=_NextPart_000_000C_01C861BD.6CD598F0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable evolutionary principles created on a computer. He designed a happen at all= The potential is real and the outcome might be There are also studies that indicate that there are increased ------=_NextPart_000_000C_01C861BD.6CD598F0 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable

the age where technology is fostering the construction of a

You can have a bi/gg er pe \nis

As Seen On T V

Ov /er 727,000 Men aro /und the world are already sat \isfied
Gain 4+ Inc /hes In Len /gth
Inc \rease Your Pe /nis Wid /th (Gir \th) By u/p-to 28%
100% S \afe To Take, With NO Side Effe /cts
N o Pu \mps! N o Su \rgery! N o Exe \rcises!

Symbolism, which is the key to semiotic interpretations of our
------=_NextPart_000_000C_01C861BD.6CD598F0-- From eengrape944@acemshop.com Mon Jan 28 12:56:34 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJYDi-0004SY-J6 for ccamp-archive@megatron.ietf.org; Mon, 28 Jan 2008 12:56:34 -0500 Received: from acvy39.neoplus.adsl.tpnet.pl ([83.11.130.39]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JJYDh-0003r5-7b for ccamp-archive@megatron.ietf.org; Mon, 28 Jan 2008 12:56:34 -0500 Received: (qmail 76214 invoked from network); Mon, 28 Jan 2008 18:56:42 +0100 Received: from unknown (HELO acemshop.com) (60.216.226.97) by with SMTP; Mon, 28 Jan 2008 18:56:41 +0100 Received: from localhost.localdomain ( [189.54.65.16]) by acemshop.com (8.13.1/8.13.1) with SMTP id EAFgoadj943737 for ; Mon, 28 Jan 2008 18:56:40 +0100 Message-Id: <901721293046.EAFgoadj943737@712996.> Received: from phpmailer ([127.0.0.1]) by with HTTP; Mon, 28 Jan 2008 18:56:40 +0100 Date: Mon, 28 Jan 2008 18:56:40 +0100 To: ccamp-archive@megatron.ietf.org From: "eengrape" Subject: e'glacer X-Priority: 3 X-Mailer: phpmailer [version 1.54] Reply-To: eengrape944@acemshop.com MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset = "iso-8859-1" X-Spam-Score: 3.5 (+++) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 http://uegieoaega.com/ Give your woman some lovin tonight with your new found 9" hot rod. From JessecholinesteraseDiaz@merriam-webster.com Mon Jan 28 18:28:26 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJdOs-00075Y-O6; Mon, 28 Jan 2008 18:28:26 -0500 Received: from 79-68-14-214.dynamic.dsl.as9105.com ([79.68.14.214] helo=wayneo4hdjh2gh) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JJdOr-000803-V9; Mon, 28 Jan 2008 18:28:26 -0500 Message-ID: <123c01c86205$7a5357e0$2101a8c0@wayneo4hdjh2gh> From: "Jesse Foster" To: Subject: Get approved in 48 hours Date: Mon, 28 Jan 2008 23:28:15 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_1238_01C86205.7A5357E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 4.0 (++++) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 This is a multi-part message in MIME format. ------=_NextPart_000_1238_01C86205.7A5357E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Your credit doesn't matter to us! If you have your own business and need IMMEDIATE cash to spend ANY way = you like or want Extra money to give the business a boost or want A low = interest loan - NO STRINGS ATTACHED, here is our deal we can offer you = NOW (hurry, this offer will expire NOW): $47,000+ loan Hurry, when the deal is gone, it is gone. Simply fill out this quick = form... Don't worry about approval, your your credit report will not disqualify = you! http://hitcthis.com.cn/ ------=_NextPart_000_1238_01C86205.7A5357E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20
Your credit score does = not matter=20 to us!
=20
 
If you have your own = business and=20 need IMMEDIATE money to spend ANY way you like or need Extra money to = give your=20 company a boost or require A low interest loan - NO STRINGS ATTACHED, = here is=20 our deal we can offer you TONIGHT (hurry, this lot will expire=20 TODAY):
=20
 
$36,000+ = loan
 
Hurry, when the deal = is gone, it=20 is gone. Simply fill out this short form...
=20
 
Don't worry about = approval, your=20 credit history will not disqualify you!
=20
 
http://hitcthis.com.cn/ ------=_NextPart_000_1238_01C86205.7A5357E0-- From kxwcombat@hei.org Tue Jan 29 02:09:15 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJkap-0002ZW-5p; Tue, 29 Jan 2008 02:09:15 -0500 Received: from [189.7.140.39] (helo=hei.org) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JJkao-0001Wx-C0; Tue, 29 Jan 2008 02:09:15 -0500 Received: (qmail 62623 invoked from network); Tue, 29 Jan 2008 05:10:01 -0200 Received: from unknown (HELO vendas1) (kxwcombat@hei.org@67.228.95.35) by 278c07bdhei.org with SMTP; Tue, 29 Jan 2008 05:10:01 -0200 Message-ID: <001301c86235$3351d990$0664f99c@vendas1> From: Jeannie A. Watts To: ccamp-archive@ietf.org Subject: Go of nursery Date: Tue, 29 Jan 2008 05:10:01 -0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0010_01C86235.3351D990" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.1158 X-Mimeole: Produced By Microsoft MimeOLE V6.00.3790.181 X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 This is a multi-part message in MIME format. ------=_NextPart_000_0010_01C86235.3351D990 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable assienment in part given to our computer class was to connect public to the= media? How many people are unaware of the biases As an Interior Design student I have noted what computer programs ------=_NextPart_000_0010_01C86235.3351D990 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

for land and space. May be the environment can be saved from
=

You can have a bi/gg er pe \nis

As Seen On T V

Ov /er 763,000 Men aro /und the world are already sat \isfied
Gain 3+ Inc /hes In Len /gth
Inc \rease Your Pe /nis Wid /th (Gir \th) By u/p-to 25%
100% S \afe To Take, With NO Side Effe /cts
N o Pu \mps! N o Su \rgery! N o Exe \rcises!

both financial and intellectual are stored in computers, even
------=_NextPart_000_0010_01C86235.3351D990-- From sueace.com@grandlisboa.com Tue Jan 29 05:40:10 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJnsw-0006lM-L3 for ccamp-archive@ietf.org; Tue, 29 Jan 2008 05:40:10 -0500 Received: from [122.163.141.41] (helo=eeorxec) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JJnsq-0001Ur-9J for ccamp-archive@ietf.org; Tue, 29 Jan 2008 05:40:10 -0500 Message-ID: <000201c86263$24dff300$0100007f@bvfiqcc> From: "Emanuel Bryant" To: Subject: Date: Tue, 29 Jan 2008 16:10:00 +0500 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_005A_01C86263.24DFF300" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2905 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 4.9 (++++) X-Scan-Signature: e5bfa71b340354e384155def5e70b13b This is a multi-part message in MIME format. ------=_NextPart_000_005A_01C86263.24DFF300 Content-Type: multipart/alternative; boundary="----=_NextPart_001_003B_01C86263.24DFF300" ------=_NextPart_001_003B_01C86263.24DFF300 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Info on picture or here: http://www.acetpes.com/ ----- It was still difficult to unde Has the pain in your chest let It has, milady, it surely has, Id like to make a salve for yo ------=_NextPart_001_003B_01C86263.24DFF300 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello

------=_NextPart_001_003B_01C86263.24DFF300-- ------=_NextPart_000_005A_01C86263.24DFF300 Content-Type: image/jpg; name="img63.jpg" Content-Transfer-Encoding: base64 Content-ID: /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAACAAA/+4AIUFkb2JlAGTAAAAAAQMA EAMCAwYAAAk3AAAS1wAAKzX/2wCEABUSEhwUHC0aGi04KyMrODQsKiosNEQ7Ozs7O0RERERERERE REREREREREREREREREREREREREREREREREREREQBFxwcJB8kLBsbLD0sJCw9RD0wMD1EREREO0RE RERERERERERERERERERERERERERERERERERERERERERERERERP/CABEIAMQCdwMBIgACEQEDEQH/ xADQAAEAAwEBAQEAAAAAAAAAAAAAAwQFAgEGBwEBAQEBAQAAAAAAAAAAAAAAAAIBAwQQAAMAAgIB AgcAAwEBAQAAAAECAwAEERITEBQgMEBQITEFQSIjMmAVEQABAwIEAwQGCQMCBQUAAAABABECITFB URIDYXEi8IGRoRCxwdEyEyAwQFDh8UJiI1JyM5KigsLSQwRgsuJTkxIAAQIEAgcFBQcFAAAAAAAA AQARITECEkFREPBhcYGhIiAwQJEyULHB0WJg4fFCUpKicIKy4hP/2gAMAwEAAhEDEQAAAN8emQAA AAAAAAAAAAACLMndhnaO4Gil6XHPp649OnI6cenSP07VrB6rTnRydOfDtzySOR0AAAAAAAAAAAAA AAAAAA8imphUgAHnHLpJD2mpcS9nefr819X8jr+jy/Wjvmf7fGJs9eGbX2OzOkujMaYwrWmMbVkG XHsCGhqjN41RkxbcZSmnkAAAAAAAAAAAAAAAAAAEMvvn7cdRx+brJ3DHW3FST0cZouo+PTqrZzOH bSnoSVnfzmr8/UZ1un338v6Mil9MgAAAAAAAAc+5N4i9rxl/qlIXmVGbfDENaanTNlneGpW6omn7 m2SwzvS7DHKWgACEmQTzRx1j0XIAA8PUcHLpZ7568Xp8zruRlWbeffy4/JoWT8dNyLrmbFKpqRN+ Ngu0vT4vPWhU/U3+evRJQcu99X9uJ0EWbcVrFR6zJ+fa4rQ7N9D5UzqvubZV+6mVVgjpoq3mzaVR a4o22zRwwZuird1EwvmAAAAAAjkYgiuOPWGO1zNVuu+OXTvqHmOllEqZPOUWhdTtv1xXOvh6NDOl uzS0Mde+dt497M9974Y5r1m8fJ/YfIdvPJufO/U9+G96d5oXO3Prm9aCOlFeVOXp+tnOaKbze74o x6QqVNWCaqW5e6mr7ZVFHjRTedLcblFeFWvpCnFohHI68AAAAAAAPOOZfL29iisxXnXjn0946Vnn XqKc9CDuX08gsRdI54ne3zUOdFNUl1zvNkvcxXEcnHPplTa0fTn8fk/otfM+P+zsd+jiF4AAAAAA AABzXq8lm3n1jZghjLU+VKaDMsFtQiNP3L8NWtXrGz1m3yCzmDSjrdkirYLYAOehoM89M0NziOdN QezM2P3tOhcBWAAAAAAAAGdYLKDksqHBpI6JpKfRaVfSyreFpUmJVWwdKfhdZVstAAAAAAjkAAAA AAAREqvLO9qtnHvlbUxU4vV8Re6NUr9zWDOWPdVfLtfNLUO5H5z6RM6zNTywR7t5Vs9I9G4Bn+3x S8vDP7uiCG6M2a4M1pDNs2Rmy3Rn3JBk2booe3gAAAAAAAAAAAAOSHri/wAKqva+bxbpwlifN4NW Kn6a3Gb0yxYoytsRcRMvVvDbflKycW6EZoYuvGyjJVtrkk8rml7Ws9+QaAAAAAAAAAqohNVm4L0E tMtwc9nnlS2SeceHsiIl9pzknleycQuzvryIklr+nqYTgQT8Tt3Hmp8d7h7mbX9mi1J7J1Sp3a9Z n+aIy+tLxtH22Zm93/G0vL5mfzqeGY0PTNj1oyLzmxm92/PesBooyllz6euR0rTnSOQOKRoK8x0q 2DpWsHqnbPXnh0j7PUcgR9nqLs6cZ5pmaaTLtlkAAAACragja0Wh1m58VqziK0dJDQAAAAAAAAAA AGbxqjKt2hm+aYyZNIY2nMMnjZGXzrDK60xS7tDKl0BVraYwrugMnU5kMK7oCtxc8OcrYFevf9Mq 1bAAAAAHkcoAAAAAAVLdPn29jgn8/q7qTwTcsyK+cUsUnPrM5468bVezT2ZYo5efW37T86cb8NjE 3NivFxN3YOOm21fnpysqaau+1OqiZWijpfqe1pvS9pe1zsSUO8q/naOfUSRyxc+2lHFz38vvsMHH 0aE2RqdePHNL3n2sS14S1brWe3mDpyAAAAAAAAAAAAAAAAAAAAARmVINkAAAAAAAAAAAAABGZUg2 QAAAAP/aAAgBAgABBQD55YDAQfsJYD4PKvL04zjgqfz9fSnHolSuCwOVp29OcU8n6j9Z3XO68/Aa qM/eE/EvHGD9GnB7rhcYGBxag41AB3XPIuB1ONTqfIuCi8LQNjU6nuPkH854RjR5xpuMBZc8j4ST 8B+GfOL+8CcN4h18f5ROmeP/AFMuc8X5aZ4WfB6f7eIcifGCfBaYY+M9vkOxbATgYglmOfj04xE7 NwMM1OGKnDDPC2NIgHsuKvH1fHoVU541zxLiqFH2LsML53zvnc53Od87nO+d87HA5wHn6snn5v6w HkfUMfx6cc50OdDnQ50OdDnQ50OdTnU51OdTgHA+ofOv4CnAOPtlOQAacHycf9Of+vU9uzd+hapJ pTmjuuM9OS1CvdunenHd+hpQF3p1L05FKcV7ct3wuevegM3ds8leO7jJ89fpj+/nn9/F/9oACAED AAEFAPn8H7EFJ+DxtwqYD+PsCJzg55aYbDIjJz49OMccL9T1OdT8Imx9APifnn0EeR43wTOFSuNE riyJbxtx4nwowxJdh4mwybs8ioSXYeNuPkeQ4teMDqc6hs8a4FAz/H+firx6tQlfOe3l/FKd883+ wtxnm/1Wo5evI8h6eY9TXnDXkJYovlAX5AXjCBhUHAoGfnPznJwt1HJwOwwVYYLZ5VxaAnqGw/W9 iM7tnkbCSfsfGcZxnGcenGcZxnGAZ1/BHH13Pwj0/foDhHI+pHpxn4znOc5zkZyM5GcjORn4znOf qhnOc/bZdSSJcr4u3/Ir/wAewCdU8fkCxAEpcSmj4k48Ksg3jQuZS5KJ5FlIiaRDCcuDKPMenCeP FQdxORWqIueKIbpNhXjv9MP188fr4v/aAAgBAQABBQD/AOttXxLT+yZmP9jWqQefXY2KpWGy5fyL 2JAAqjHyL2DqSrq4NUUrRWJtMYaopttrJuw41tobAFFY4lFfA6k+VMNFGG0xjOqlXVx9wNx5Ouf1 5L1LcH+Js+WXps90vFaXt7avaid11YsLe2r2fyS2f5yMk9nXdq6saNjQfpbXNLPrt41QGenF1EIU FNlGpLTi/l1pOmJJvb/9KFl7O2u6z0JmcvspIGLszZvh54wHnGfqWcDAq5rbBdv7NBMFuT/Av02f hZQwnJZD6BJJM0ilT9lOzMZOqVxhnPUhwfUkKCS2EkZQ+V/GyOHVcaUVf+5sq/p/Pp49j6RqKpVg w94Xf3vQNuKtRZvKKoxNUUgggWmce7Lc1RSaKoeip6TuSy0ViSAC6geRetaFRr7Du/0f7wDK66Ux dhiobuG5GLT8JUkswwtzncHKKxdNplD7EyOfKf6UVmf8AlTr08s/o7QfyaSlYy1uMfXbx31yKPNj ZNcrmzIo8AROcy6eNxsNruBSTDNuLmuqCsmk/WOuZ23p+SV41MoJ0npSaTaS8J9GvoTm24Q6leyt wc6ZH/3ROQkyMp+C8wwYCWVuBmzstsPxhz9n+ST7X6oyQnJSSQ+g2NhddYUd1J4wOCAwPyCeManA S7uw9HbjN5+TpD8DABjjowpyC+f+j/gzDY8hn9HW8FBhzV/nVfFAAzb5WlWMrNtIuV2lmRsqaTKH YO2vBHIjRQ838Em3EVd0DynYUOm0rzXdRsO2vA2kM52V23uRKp8cE2ecO0KR1LM8zuoFQhNuN1qd 7kSqfHCmz4F835+dSSUxLdm7VU1f/Y0DZ2OA4CBgc52zsc7H0b8CX5YYcq2O3keDlBOwfAxGE84J c4I4E9Pxg45/pay1UjglZoP4DG7AcDNwd6TRFEIBBsoQ1AfdTB90snUk8DW/1ezM8tlWbX2+Wo4b z66MkNOY8Q/dAtklNA+9yZa00COG8+rJ1hOZfWke05g+60wRTe5Mjr/86VNk1O+u2AU5+cV59OgO NAHDJlwkjFYEllGeUZ3zvlaDjWHODHPA27AZRRmvbqSVfBwcCjC4XAe2fvGGUr0wbs1OxvQmtaBm T8n+MgXZ+gZQwXW6CclkPrCwBQAOWVcahFf9s5w8nGh2Aj1wDOuFcfXV8SfUfrGBYmEyW1ZNj/zJ Ni6FEIlVS1ApevTIWFQDjUGb+q7mf8yDz3/4dtYlSDo6VtptHSXTn9I9FTNrZ8ODbLU8i9mdVMNt avDYLIrqxSivjOqDyKB5F6iqHA6kK6uNra8SmqKew41tk3ZKK+LVGy1XRoba1fTu109Wbqb0AXkn FiQpPGd8753zynPIc753zsMH5x/wFHHyGUNjSJCawBIBykg6SkUWurK5lNZr9Ltxc1fXLCWqq7Hg opebDZ1oGd113bWnCjz1JstP6KM89rV6qsm8K6g8iwodbWk3J136bkWDrMCcNVjHTi/l0NcKNtGa mtAzvogifqUU+v8AjgfA0lbDr54GzxuMCNgLg8k/dhFA/wBs3auXbbRZLtIchuTuda6pFNnzbFar FU2fNsN/QkpfenPPez8ctydSm4jt76ff38u63VqDdmZo3cP/AEJob1DM1X6psqi/YFPbGPQGmCgO dhgoOf8AC0Bxaox7scS60znj05wnjFt2L0YZ5XQrRWPxD+f5D7JjNNM+PX1HV10W8M9avl2oedJ6 1fKdGoVdZhQ6ZSGtrszy0Wm2vBpP/wDnvlNavmXTcRjMyRJ0o50yMOm5FdNqD6ql5ywbPbEW7kr5 bD+ZEjY011m8IOeCfH88goTxm0gqdKhrHqDm1rLSOqwtFpIXZEns+FDldCVM1pCy7OkxnPYMibmq sZlVDyMX64GDD7nRzQysAKbW2RKC0W8JRfwyXNycxP2yHPbIc1xFC0osG15cafnEfFdwNUZqSuky +1zuNZM9mRnG5PFO1rGc7htnVndSldcpQ0y5UCU50KNyQeR9LTelNjvTVZbk6LTcFqUos1bcRZtd Vom/Jyn9CbmFQrDbQzlvTq3852ed9ycDTcnMR252CbiO3vp92/oSU03+tVcDYnvSo7/0JoW2kUzd jteruJrp61NmVreEGqoS7AVrywt4w2yHB2lAXaTjzI+JYKDcFfcEONk4Lk53buu05Fdl819ozX3L HNu5ePkWTy21fNgSup/5vo1qFrVyVLFYUYv9K+pQMNNwBpk4upUmyd0Oi3hnrV8utrGco67lxpk4 dV6RnrV8unBoJsajs+xHxZLUbmWi0214NJzo1CvqU7e2JrLScMdNyK6bUCzoLetY+5pewijcMXsF BNbn2gZ4RlMPPvMv4cOwFx6TcFpDFaJMhCZnqyYNpTAfVQmmrwRqcAQOCB7NruR0dsMWOLrNw2o5 xadM9z0Q2BzUXk/cdE9r2oavQ9mWSqXrsDHJBWFLMukpwaURg1ZDPbTz28+fboc9tPDqSJ9lHBpz GDSiMOjE4dOTEaURg1ZjH1JuBoSGeyTPYyxv50+Dp2GS1WOKOo9ZbpNte7VdKK+EgAUVgaKM19tb KtFbBaZ9FqjBd/kQsWn5F67G4sV8i9Xuy3Zgo1Nprt2HJIAV1cG0xhYAm0x6G0xhYA3uIJN+60Lh VveNs35qz/zC5Ondrp8qVGnrMcafUCq8F2OS1Qp+rnrtRoxqyacX8u9N6S1U6trQKvrRZFlqH26S btso1Ja0SXTV5hXWIksaCFtMCN4lpBW8253ZRC0GlJl2d6b0lrSbloP0pJvc31m8lAWVoP0pJvc7 qlo+48CVcos2qtY7Is+01Q+nCvl0QRP5UaCVZyCh07gaZBnBJ/dUiiN8HA59AAPmk8CKkD5qWc7O rZ6UjsuNfSu1AmxsGd9yiObsdj3dfBbbfwWtRqA7E11KNSW7sPNtncCSXfCvXYnEvec8nRaKN2Jy tkiLbqKktlHnfa4MrJYGyBxeZwXmySslhSqyD7E0VtiapO86na3QFrsTiXvOee9jw+xNMcEqNuri 2y+vSl7JDKWSQap867sWPuZd8TZlRm3IqWs3uF25NmrZ6U+r24OzHSoi31WfE1qwqui4R4s+xPUe Wx7Svg3NNnNo1SqRsW1lZZjTrZn1amWxqt5dnVc1OqxCqFEI0rO+q4K6dCh1aPr1jSuakWk+zKvm nrU4OpVtfViyU3YNXNmFHZtOggNU+U6dim1q0NG1HAOm3FNahxyQo1rILa9NilY3pGD3ZtyDVFI1 NIa1lp7Ki5RO6x06921HISDisdcGuujq/wBtl4+Pr5ePj5f/2gAIAQICBj8A79n9hRPYZW0oZ+wb aU6bBRgmplpj4qabszfuIaS4kQPNTQbNlBPhF9jJxFm5pn1CmpzRDSD6BVJ4ppFyPJENIOmx7mJU Cs1CCmonvDVmrRrF07/mu+CLK14R5oxm3JXPnzVIGGPBlcWeD8MlfsZXPnzQjhbwQLyJPmrjk25C t+odyWwRThRfsNhipKShBQOjpXUE/jZKWhh/UgVU4GIzUi4fiapftQHU4f4NKaxIuHw5FE9Uhmi9 zvwbBU00vcWfXNXD6YMeOuSqFspTzVIpDkv8EaRS34ZymmbAZ5oVEReI2OvTgferm6so+5VNTIQg deCYUxjEOqhbKXn8o7FGnkc2+9C1/qbLZtVTXNG3X/FGqkRyITCmdWRlBG6lmkvTHcctRtUp1Y8O U1GcZ7/DjwA7f//aAAgBAwIGPwDv39hQHYdOUcvYLlMnxUIpzPRFFvFST9mXcR0gg+oE+SZkXgwd dUE2MGhN8kKaoO/IJ21MvNNbrJFxKaBf1G1S1MkaQHYtBOIhgfNAv6janwz3dzBMQstElDuRppow p/FXnyfMMmb8tvN0HEtfwV9sYY5N8kISu/krW/T/ABVVVU6jLCb6wVtL2xaOBjHNf8xm6tbL+OsU YTqu4/LV0aWnSKfJCkZvv2I0CnpPvz7kPihv0Q7D44KamoqI0dWK6T46anoj9l3+2JpqbqDAnA6w U6bSRwFM/wByNT0tVa0BtcRlvWAqFB848x5oDp9RjBtx2ZIMaGYT9V2OslXXXbaCWExshiFYSC90 XHDdDmqSa5+qIyPxhtVRqJFIIaIxdCqqp4jEfqynJO4IeoM4kxbfsKNAq6WgXE2z3pr8QJiTR5oU XdGbj3yVJNbEmMRt1eRVxqh0wLYzdUE1z9UsuUYRngoVcxk/3I32/S+e36VQ9rwv+H+yFFdQbEgj 3pzUHFOBAjHXNU2VODOWvApr4QxGbe6OxT9NOH909sl0s0Jbh4cz8AZ9v//aAAgBAQEGPwD/ANWu AZHIIatsgfqrVNqMSf6gyp6Rt7YBJD17+K+VvDTO4ay0uNWT1TmyAEgSbVWlxqyeq0ghxhiniQRw RBkAReqYEE3ui8hShqiDIAi9VAUIli9hmtT0u6JsRg/mtIIJGD+jpILZFaQQ4wxR6hS9bIORW1b8 kXkKUNUASATZPEgjh94jaFZXPL0PiFXAow/o9vpjuRiZARw70N6cdAiGAN+1Vo0nXqf5jlu2L3Rj ZwQgD/2wx73byK0aTr1P8xy3bF7qU4wMhIADyx7kRIEHVjyCOkONwAPgGb3KUyDE6dEXzYV8lp+W dQNZVrfD2j2rcJiSNLxvdgtuWgkhxIYs7+9CBDBm0+xTiYmMmIE37c3CgBAxMT1Sz7WpdSjC5QkI mAAaTvVbkJAiZBbcw8fP8lPb0ETDP+6uHLtdbQMCBAgP4eC3egzOosRhfDFbcpVO3WQ4O/kEH/V1 fc1VoBr9QxscVU80dyIq11OJNY1MTlmD7E5q4RRgbTj5j6RibGi0wDD7CZRDGVSgZh2t9zX8l0SB 4BVTlN6XKr4egbTs9StQuT1FNgjuwpI3UduOHo2pfu+ysSAb3TxLjgpCGlog/EaksbYN7FDWA8rt Kgqz4+tDboxD6n7dipRlpEAHvXC9fYgBIEm1UQZAEXqnFkGkK0FVHaDMQ/HH3IgyAIvVaiQAcXXU QHzPon8zSIxNC/rr7kwIJvdObLUSGzwWpxpzeiIhWeEfLwR2t0NIVp9kb0P8MhaUbhSjuf5IfE2O UvTQpjVVThMnxdNMPxCd1pfS+eKEnGon4X9ESMKqM8wD9knqgZmTmMnNO2SiJBjW/Nbp0mmoQvxt mtuWgkhxIYs7+9QkNskGIBi+Nr8KLdLFjAgU4BbUhEvq66HPyUydN3Fa1OT8cQog30j1JowMiSwm 9rdqrbJBLRYywdjipRltmU3fW57H1+C2pyiZREQDHjy7WYoyIJiQwaOpvd24qIL0/qDFb/SayDUv 1LbIiQNLyvdimAJILjSoOG0nqjEebWP4rc1RlIFukx0+H4WRjuR6iB13pl3dsESYmJJrqufIfZH9 OvhpQPpIP0HxTyKeIpmUSTQWH0IA3FPteoxD5tX0aYBhf7Dql3BatwaXt6HjUK4f6npDlGJiw5/Q Ee9H06sD6X9FbqoBRIoCfTHenFtlwZScfDjS/khps1PRtgEgSLSaR4KEduRL0lEky/JEsTGJaUmo D2ydRBBIlYiqG2QQSHD49uLKTatbVdmaiMogyjGhlFvemW4N2ZAienrPHjVHckZSiS4zALX/AAQm RLSWq3Y+DhbRx1e0L5cQZSFSB+LZo7sQSBcYqNCBOgJHbt3oyiDKMaGUW96G4xAJaIapPcjC0heJ RkCQQzMSMQo7gkRNokdRrZ6FCDEzYGURhbMjNS3NsGj5Up2zQlPi8qNftghMg6CWEqe9/JTYYWA/ t7OVIBwYliCjIEghmYkYhR3BIibRI6jWz0KEtyJqzs18rqMQCdQdwzDnX88H+vBkBJi4R29wGtpN SK6hQG73RIFL2VFdX+sMs7KxPJZHj6KqhZVP0SGqy05KvVJrYLcjuFwIxiBgBVN6NvpJET1dJIan ingAH4MpbW5GRrRnY5WLePitoRiWhdgS1vcoyY6QGJYtj71KTHSQwLFsPcoz2gYzJ6oMdPbhcOwq E63TOMtMjTpNRXgp7cYSERpEKFz2ZQjGJJDUY4BltSiCQC56TwR1AiDDqhGptcgE+pbkJAiVaNmG 71ETj1Rf4havFTiBP5cjT5dR2PDkVDc2QdMJMYi+HbvRnEF2Yylqfz7ebGIBJLMwJxCidLSAAPSx dkdQIgw6oRqbXIBPqW5tkES6vV4L5LESY3BzfkhtzgdUaNIUpi9u1HxlJjpIYFi2HuW4SCBIuHBG JRiASSzMCcQo7u0CNyADhmfPL8bIQ0EGdDqiWj2w82R2jEmL0npPbtlX0VlFv7T/ANX19fRYKlFm qqp9FPSyMvToxN+SeKCf6jqkB3oyMhZEgMCUBxC39HwgQHr+wmJsaIxhKQjlSnKjrTAMPtoBLOWR BJJFGwTYoRYmjuLK9MvRQJjEdysremoTCw9DBOYgnkqxCeJlHkfeunccZSiqgEZhaS78k5B8E48/ Qy+efhFGQE4gmWKMtsa4eYTGh4r+GLt+o2C0RrI1nLM/ZeogPmUIxbVLOw4lDbiY4ai9DakVpcas nqgCQCbKUKBjSvxLVumIq1CG9ZRAIJF10kFsinkQBxRLhhQ1WpxpzeipIUD3wWoENngniQRwT7ZB ILHz9yIMgCL1Wp6XdGwiLD9XPkukgtkVSQL8VARZpGrnlaqlCgY0r8SMpM7tT6BJbxUTG6e61vQi zfVU9D/UVVCnkXKY2WgWZlpMjLmid7bBkDfNCMBpGX2YyIJiQwaOpvd24rapI4ScGz45I9J0AAxu z0REtTgvqjDV36nB7ZoTlEyifh/b2/G6LwLOdMsAPa6IYiQlqZr0W5JtMtw0ieftsokiQox6GFsS /sQEQSdWHIqPyh0gvICuVWN+3FbgAk50ljFscBVbYMTpMXle7FGIBB1O1nDKbagZRN4aA+Fj7Ew2 zqiayz7vcpSFfmNEc3HuQ2zUNpU2BG4aVpSiEhEwADSd6rXOJEwSzvZltEAkCVfEIvAs50ywA9ro vHRW1eGf0KgelsPo19ZCpKQ718cvL3KkvEKpWDKv3t8xurP7t+XtlmBlIg9uxCjukFpZZ+Sm9BD4 iVpi4PFGcpGQB/VflcqGgnSxePGq1SsoaCdLF48aoipbLFDU/VHUF82rOzYuiIvQaiTZCNQ/wkih 5L5dX1aVofhqwR2g7gPw7VXzC4Dt33QkxD4GhRiQXBZbRjIgSP6bG16hb/UaSDVt1KEZOZSjE0Dn n2r9w9NeSeVAM6KgJ7m8yw81iFj4Jq+BT18E9R/dEj1poyBOQKpCZ7m8iQacuTrpErseiVOdKd7f QdUxLAevuH4JrFyBi5/HB2RjMCl2NbPbHNML5fTMt49RP6TTzCltEhnfb4c+2JUozPVMuSO3uQnu yB0jTFvyR25EPq1BrWUd3ckJEOD5rS7EVCju7khIhwfNS24SGg1Y93Bbc3DQjpPgUYTqdWoaK8OC nKWrSY6Xl8WCBaJAN+p/cpyLNIuPNaNX8T6uPb82R3duQDsD27kdo6SSXx7OhAl2xW6NuQDyaT4i q2hE0gXL8wVuhx1kEeLqABAMQAZY0y7U+19cgOGPguiG5IcIEetl/jER++VfCOr1qezOcnizQ2+n UKV1XpY1Fu5V24A5kmfrZR3D1bZIhKEnaOotqi744Vfgqkn/AIj7E2kEG71Rgw/jlLbHKPw/7W9E NuXwz1RPfCSjKfxViTmYnS/ezqynCIAeJYgY3Hmo7hAecQZIDSGaWA4KMNI0zgWpYwx7xIf6Qmr4 lWMZf1RLFEltcZHbkdEamNHtiKthZGO3pc4COk8nBx5FE4u08wRhIZ8RdThEAuQbiobkWJa+HFD5 ZO3IA/pJlUM3E4ipctwXyzAmR6wHANtIEjat2rXkgCTUH/aWfgE4L/eh29ssI/5Zu2iP/U1srnB/ mf8Ah/8AjmUZf9x4w1cerqPOQHehEbWgktrMhJuOkVk2SG5Pd3JuKNMx8o6R3NTFbZ1TEdRiZa5E xcOwxGo/E2F05luHnvbnvQnGU9IlEz/knJo5gEmoLNjiLKm7u1y3Sv8ALu//AKlTG5OQkJypLckH D6YnDU9K1qmlESA/r6v/AHOgYvt6aj5Z0DvHw+Xkoy2d2JiRUbkPhliKMb51XXvkZjbhEectRT/O 3v8AWPctEd7SYdBgYCURZmIYsYsRXHMEIH+MljXqiMOahu725GAEwNUI/CCC5JOGFmxKpv7urMkH y0smjubcxnOJif8AbRFvl6dybk9TRlIgWv1HwJrRCW7uv+yMAI+0+aNhP9Mxf/5DOJumkADLK0tN yGtS8TnTFDbcxJcSi/TpxYGgllxWncMTIaWjop/dM1sHZq1LIjXISkNJjEGMWyBlF63+KpLsn2yZ RLDUSS96An2fZzAuSMvUozLtJ/JGVhG7rb+WSOrqHgjKRYBDcIkxLWqhtF3Ifh2omqL4ZB0IgFyW W6ZSJET+qwvapXzS4jauPJCEXcomRJOrHkFpk5PBRJqJWIRILNd8s0I1D/CSKHkvl1fVpRFS2WKF 9DAkMMQ/uUwZFhF2Pwi3H2LQHGRNijEguCyiKkyYhhhn2qpxJLCNsP0/QM5WAcp93o2tw69ELz1V 6yXoRTSGOmj4Ibe2HmR0RwYYnKMXHqFUTI/yWL0/0irR8X4qRduoyaNiT3PXhioaaHVIsRkMR3ps MrmJyfs2a0ykNJ+IPWlQC+BxZnzWiM+hqB2I72cx/pysSaL4/NdRiSDIx1Vj1vfxqBk6YMAP6qju N25ktkm+IWLGmnF8LYIzgWMgAX+GRD+ByPCoOGI7iqFSntnrLWtLpAAl4UNCM0CbG0haXt7jVREO rcBEoxt48GfvQjA/xxbSC+rQcq1ETTPTiSqMRwUoyAI6fKQP5qMdqZ29XwxJeDjAi9QcxwTS+MUk OPB8Mk0nFXBBqDwRiSxi7EcQ4bmEYx0sDV/1HMn8H9ohvTjEP/ki/hFyXPFmje9ECdUds9MYmWQ8 c3q3gpQOAifEy9w+zTO3ICM/ifvW0HHQST4ut0SNJlw3MlQM5A6CGHDt+aMQxfOy+Vqcg6uHJR3d yQLD38FLbmfie3EMoAamiX6wwApa63RI0mXDcyV8qZGqPwke1R3dyQLD38EYyZ3eiM9qQGoaZP8A ktnbiagmvFwpS3pPKQ00y8EC0SAb9T+5TkWaRcealtwkNBqx7uChKEgDGIifwU5k9M46eOCjrkDC BeLX7eK3Q46yCPF1AAgGIAMsaZdqKUyegikX5fQhtEdAOufKNh3n1FGRqf0jM4DtzRnNiSQ/E4Bs o/pjzJq6IcAMX7duK1Qi8RbAebYKMN2XUYyPT5VxPgtUoxkM71f/AJs25rQACXEpkhhd254DK5KH UdJrnIH/AJgcv03RBPTL9pp/p1c2US7EWlo4Y+Rqy+GBL1AcxHEMD3gpyIyIrHon3fpCYwMv3CBD ZhsRlwzTiIEa9TlyOWeDmouykGm79NaHn+LcChGBkRjWvBnFeVBS70TuRI1AJi9nY+XUOk1xR6yQ 7vFiD+78L05Kk3DuTduOXPs+kyd7Ud/Znivicmw8/UqyY2Yxv6m702sEDt/UumQIPbmn1CRiC0c8 x3r5kbloknHgfBaNstIu8iG4m1eV+aDSwZtJA7vzKO49wI+Bl7/vLeOAG3Dw1H/mWqRYDUINlnzP Oxa6AgAZFxER8/zTMd7djcR/xg4VPtJ5INCJJoOp+wo6cy6nBpGlLYv5pzpDY6SOxX8hMvIeAVI+ aYDzKtdO3mVUE95Tt5lO1TepXw3zJKo4/wCI+9UirNyJCeQc8SVSLciferPk6Yu2Qx5pwGIsyue3 cqujpcE52ThyeY/Bfy280Bl9A7UwAHIiVOJZolh5rpILZFObLUCCBi6BJFaiqJLRIwfDNNEg40KD SFaCvoJEgQL1UpltI+GL9Rt5LXuGPcaDnxWpxpzeicNI5P5rU405vRR2gzEPxx9yMjYVREg2MeS0 vW7JzZPEgjgi8hShqgCamyLyFKGvoLyFKGqAJqbLWe4cUJWcAr+NtXGyG3ukSBbz9AM56YtShNUb 6AO50ZSZ3an1e9LH5khyBYP3Cq+Xt4Vl3Yk4AfkDZHU+mVwaasnGAwAeruWTM92y7P7kHcnAA0/F apVLdsftm6CCDq1QNq9S3QQROTcHqX7WQkImAAaTvVNDAuRmFKREmMaxMNIPmzr+SB0zB046RWnD txW4JQIlpkNXsAx5omIbcIILuMfctsjbMWI1GtbV4KUYXKGoSAIMT0aRbEv5qUjE/Mel3amHioaY kgdU41cmnbgtzpIEiNMMb9vBRlCJ101Xe2XNQ0QIINI3AfN+2BW2TD9NSHpel2Q24AvIsTkO3k6h uFpCPS0RhXgPzUpCPSbmQGOR7cU0MC5GYU21Ayibw0B8LH2LT8s6gayrW+HtHtQnGLimpwG7uPn3 I7f/ANktQPJ38H70RGhILLT8s6gayrW+HtHtQnGLimpwG7uPn3KQiHNLc1twZ5kRAjbK+SMgDIjA I709uUpYUIbyUoxFI/q49sVTbE4/peOrn24L5hjpjVxbuZF46K2rwz+r3YkGQkIy08ag+NEQGjEl 9MaDhxPf6qJlRgB7FQVz+9TOIrK5+i+Ppp9a61SvKv10tsnpAcDwW5GRcRLDzUt2dSDSnLlijHcP WGOFiO3ijvahpiWIblw45qBj8JiJGPioRieiUdXrWvV1a9LsLMhOPTPVpl55r5OywIDykcO3fdTO 4QWiSCM+3BRlIuS/rQht0LGR5dgUJQvO3D8lGJkJRbqnpIL1w8EBMsShqLarISiXBQ6r0QMyzqUt sgyBAxbtdfMJoPi5rblCXRI15OM0TAuyG2T1GoClX4aSejL5gPSMUTAuy1TLBCUiwlZDcJ6TYoxg XIX8MuoFj55oCZYlDUW1WWrVS3YIapAPbtlxsiI0k1OaG1FhuuQTy8vy4hHXWEh08wPaUNwlpSlT +0j0PMsoxEhpIfTnfFvahESqaWPuXy9XVb0aIycogyqCxoVCET0Si/rQaXxHSKG/YrcjIuIlh5/b I7u1WcfV49nQG3eUdM+FXz7qZcVDZhTbF5Uvyp2KEwdb0m+XeezIS09YlYmhCjuGPRpYu3H3oSFd sO3B3otGnq16mcWZatoX+KPHPt7V87ZqTSUSp7swNUoENxoyAmGlWzZ8KKW5OWgyo16dxXy9L6Zd Jpavb8lGe1GJizEG3eEZxBIkGIjLT67hbQ00iTqBINH800Qw4IiEYkE/Ebi3l+KhKAE9MRFpetbg MQCSDHKhNsloIEZAuwxYNXiVtExA0nqFGAotwkNEnp5VUd3aALBq9/LNbvzIuZVDFnvb2P3r5cj1 AuBwayM5xkCQzymJZcFGUGJifhOKjuxiCWYwl2qhAB5GWojKimw0wlHSCO7BaNMek3xl3+9kZwAk JBq4Lai2oRJ1d5BW60Q5I0Ws/lRbZgGnGIBk9mwbtxRMayanNDdiX3X6hmMsqflYIiRbbA6eJa/d 2uUISDyEs7hr9qpt2IEWwz8So6B1A0Ls3bxUZsJNBjkSxQnKAuK0pyALeSMCDKLuGmAPAvVGNnBC iJAAQL6hjVbp01kXhbPyW3IikYCJ5sUIROqECZ6gc2Yc6d4W4ZgAE9NuOXt+7v42b9v4fcH8bN+3 8PrP/9k= ------=_NextPart_000_005A_01C86263.24DFF300-- From owner-ccamp@ops.ietf.org Tue Jan 29 08:20:30 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJqO6-0002tm-7B for ccamp-archive@ietf.org; Tue, 29 Jan 2008 08:20:30 -0500 Received: from psg.com ([2001:418:1::62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JJqO3-0007l8-KD for ccamp-archive@ietf.org; Tue, 29 Jan 2008 08:20:30 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JJq8r-000KXJ-Ix for ccamp-data@psg.com; Tue, 29 Jan 2008 13:04:45 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [80.86.78.228] (helo=fw.testbed.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JJq8l-000KWh-7v for ccamp@ops.ietf.org; Tue, 29 Jan 2008 13:04:41 +0000 Received: from MailerDaemon by fw.testbed.se with local-bsmtp (Exim 4.63) (envelope-from ) id 1JJq8i-00087f-Nb for ccamp@ops.ietf.org; Tue, 29 Jan 2008 14:04:36 +0100 Received: from gw.imc.kth.se ([193.10.152.67]:8777 helo=[172.16.2.46]) by fw.testbed.se with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1JJq8g-00087H-Es; Tue, 29 Jan 2008 14:04:34 +0100 Message-ID: <479F2458.6090201@pi.se> Date: Tue, 29 Jan 2008 14:04:24 +0100 From: Loa Andersson Organization: Acreo AB User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: PAPADIMITRIOU Dimitri CC: neil.2.harrison@bt.com, benjamin.niven-jenkins@bt.com, lberger@labn.net, dwfedyk@nortel.com, dbrungard@att.com, ccamp@ops.ietf.org Subject: Re: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt References: <2ECAA42C79676B42AEBAC11229CA7D0C01C98951@E03MVB2-UKBR.domain1.systemhost.net> In-Reply-To: X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.7 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Dimitri, it is possible that you have a point that needs to be discussed, but is this really something that should stop us from adopting the doc as a working group document. /Loa PAPADIMITRIOU Dimitri wrote: > neil, > >> -----Original Message----- >> From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] >> Sent: Friday, January 25, 2008 2:27 PM >> To: PAPADIMITRIOU Dimitri; benjamin.niven-jenkins@bt.com; >> lberger@labn.net >> Cc: dwfedyk@nortel.com; dbrungard@att.com; ccamp@ops.ietf.org >> Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt >> >> Dimitri....see if this helps...in-line >> >>> -----Original Message----- >>> From: owner-ccamp@ops.ietf.org >>> [mailto:owner-ccamp@ops.ietf.org] On Behalf Of PAPADIMITRIOU Dimitri >>> Sent: 25 January 2008 11:36 >>> To: Niven-jenkins,B,Ben,DMF R; Lou Berger >>> Cc: Don Fedyk; BRUNGARD, DEBORAH A, ATTLABS; ccamp@ops.ietf.org >>> Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt >>> >>> >>> ben >>> >>>> -----Original Message----- >>>> From: Ben Niven-Jenkins [mailto:benjamin.niven-jenkins@bt.com] >>>> Sent: Thursday, January 24, 2008 3:40 PM >>>> To: PAPADIMITRIOU Dimitri; Lou Berger >>>> Cc: Don Fedyk; BRUNGARD, DEBORAH A, ATTLABS; ccamp@ops.ietf.org >>>> Subject: Re: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt >>>> >>>> Dimitri, >>>> >>>> I find your mail somewhat puzzling. >>>> >>>> You appear to be saying that GMPLS as per RFC 3945 is set >>> in stone and >>>> nothing should modify/enhance the behaviour as specified >> in RFC3945 >>>> which implies that when RFC3945 was produced the crystal ball was >>>> working extremely well and all possible future applications of the >>>> technology had >>>> been correctly envisaged. I don't believe that was the case. >>> this is not what i say. i am concerned in stating beforehand >>> RFC 3945 (GMPLS Arch.) is not applicable to Ethernet. Why the >>> doc. does not deliver any tangible explanation. >> NH=> Is your problem that you cannot differentiate between >> the 3 network modes (of co-cs, co-ps and cl-ps)? > > my concern wrt specific point you bring is that the today definition in > RFC 3945 for L2SC, and in the present case GMPLS for Ethernet (with > local labels or domain-wide labels or any other equivalent to "co-ps") > does not result into a different definition than what's in. on the other > side, i do not see how would apply GMPLS for connectionless/bridged > Ethernet. > > note also that GMPLS induces label from the interface and link > characteristic (i.e. there is no "label type" in the label/label request > object. > >> If so then looking at the work on >> unified modelling in SG15/Q12 may help you. But to give a >> more specific >> example here: We can take an Ethernet traffic unit and >> create either a >> cl-ps and co-ps layer network based on this...in fact one can image 3 >> different layer network cases here: >> - traditional Etherent which does not have a directed routing >> function, ie uses MAC learning, broadcast unknown, STP...this >> is a cl-ps >> layer network >> - Ethernet with an IGP providing a directed routing >> function....this is also a cl-ps layer network, but it is different to >> the one above >> - Ethernet with a directed routing component (centralised or >> distributed, ie IGP) and a signalling component that can create >> connections....this would be a co-ps layer network. >> >> These are all based on a similar traffic unit, however they >> form 3 quite >> different layer networks (and in functional architecture >> terms we would >> say 'the Characteristic Information is different in the 3 cases'). >> >> Now GMPLS is applying a reusable set of CP components (which is a very >> good thing, as Ben points out below) for any co-cs or co-ps mode layer >> network. So we are setting up *connections* in either a >> space, freq or >> time dimension of resource, and it is these 3 resource dimensions that >> create the differences in parameters...however, the notion of a >> connection is common across all these resource dimensions. GMPLS does >> not apply to the cl-ps mode, as it plainly does not have connections. > > well indeed, and this is the reason why i do not see any reason to > open the space for a different set of mechanisms that would result > from this new interface switching definition. > > thanks, > -d. > >> That is at least how I look at this issue. >> >> regards, Neil >>>>> the question triggered by this poll is the following: if >>> GMPLS for >>>>> Ethernet is not inline with the existing stacks what is >>> the value of >>>>> GMPLS re-use ? what's the value to borrow the term GMPLS >>> without its >>>>> substance ? and in practice, the issue is, if it is not >>>> GMPLS per RFC >>>>> 3945, what's the value compared to any other native control >>>> stack that >>>>> would be developed at IEEE for inst. for these techno's. >>>> If we ignore the peer model (which is unworkable in reality >>>> IMO), the value >>>> is obvious - significant reuse of existing code, techniques, >>>> knowledge, >>>> skills, etc. >>>> >>>> So, we should develop the control plane from scratch >>> because Ethernet >>>> requires a few modifications/enhancements (which I believe are >>>> backwards >>>> compatible) to RFC3945 - that IMO is ridiculous. >>> so you seem to agree with me. departing from RFC 3945 makes >>> little sense. it would have been interesting to see the doc >>> delivering a FIT of the GMPLS protocol arch. blocks and, in >>> particular, label allocation and distribution for Ethernet. >>> >>> thanks, >>> -dimitri. >>>> Ben >>>> >>>> >>> > > > -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se From _mm{{th{t@Northwestern.Edu Tue Jan 29 10:25:59 2008 Return-path: <_mm{{th{t@Northwestern.Edu> Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJsLX-0006VC-MX for ccamp-archive@ietf.org; Tue, 29 Jan 2008 10:25:59 -0500 Received: from cust-138-48.on3.ontelecoms.gr ([91.132.138.48]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JJsLX-0005kG-20 for ccamp-archive@ietf.org; Tue, 29 Jan 2008 10:25:59 -0500 Message-ID: <001201c8628b$3db298b0$308a845b@xpkx0vdtsqfr0n> From: "deanna sakka" <_mm{{th{t@Northwestern.Edu> To: ccamp-archive@ietf.org Subject: Give it to her good with your super-large c0ck Date: Tue, 29 Jan 2008 17:25:55 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--------=_NextPart_000_000E_01C8629C.013B68B0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 4.0 (++++) X-Scan-Signature: 93238566e09e6e262849b4f805833007 ----------=_NextPart_000_000E_01C8629C.013B68B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Surgery will not help you as much as this - effective and safe = enlargement ----------=_NextPart_000_000E_01C8629C.013B68B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Surgery will not help you as much = as this -=20 effective and safe enlargement ----------=_NextPart_000_000E_01C8629C.013B68B0-- From Rollin-mitihiro@Northwestern.Edu Tue Jan 29 10:27:35 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJsN4-0001eY-VC for ccamp-archive@megatron.ietf.org; Tue, 29 Jan 2008 10:27:34 -0500 Received: from cust-138-48.on3.ontelecoms.gr ([91.132.138.48]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JJsN4-0005nA-Ad for ccamp-archive@megatron.ietf.org; Tue, 29 Jan 2008 10:27:34 -0500 Message-ID: <000901c8628b$76979180$308a845b@xpkx0vdtsqfr0n> From: "Rollin Tusch" To: ccamp-archive@megatron.ietf.org Subject: Blow them all away with your gigantic tank gun Date: Tue, 29 Jan 2008 17:27:30 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--------=_NextPart_000_0005_01C8629C.3A206180" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 3.2 (+++) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 ----------=_NextPart_000_0005_01C8629C.3A206180 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Jessica Alba with 2 other hotties - you could be there with them ----------=_NextPart_000_0005_01C8629C.3A206180 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Jessica Alba with 2 other hotties - = you could=20 be there with them ----------=_NextPart_000_0005_01C8629C.3A206180-- From lfyvisually@gormanbros.com Tue Jan 29 11:49:58 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJteo-0006iL-KR for ccamp-archive@ietf.org; Tue, 29 Jan 2008 11:49:58 -0500 Received: from sts2.pptp.4net.ru ([80.91.196.110]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JJten-0008Af-PK for ccamp-archive@ietf.org; Tue, 29 Jan 2008 11:49:58 -0500 Received: (qmail 561 invoked from network); Tue, 29 Jan 2008 23:45:05 +0700 Received: from unknown (HELO manager1) (lfyvisually@gormanbros.com@95.243.6.227) by 6ec45b50gormanbros.com with SMTP; Tue, 29 Jan 2008 23:45:05 +0700 Message-ID: <001a01c862d0$f961b970$077850ac@manager1> From: tent To: ccamp-archive@ietf.org Subject: Be at skin Date: Tue, 29 Jan 2008 23:45:05 +0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0017_01C862D0.F961B970" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.2869 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2720.1106 X-Spam-Score: 2.9 (++) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 This is a multi-part message in MIME format. ------=_NextPart_000_0017_01C862D0.F961B970 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable noticing them wherever you go. I now see the use of computer being filtere= d through unnecessary laborers of technology, all in various modern simulators. It is ridiculous the way ad agencies ------=_NextPart_000_0017_01C862D0.F961B970 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable

telecommunications industry will probably be the main and most

You can have a bi/gg er pe \nis

As Seen On T V

Ov /er 768,000 Men aro /und the world are already sat \isfied
Gain 2+ Inc /hes In Len /gth
Inc \rease Your Pe /nis Wid /th (Gir \th) By u/p-to 21%
100% S \afe To Take, With NO Side Effe /cts
N o Pu \mps! N o Su \rgery! N o Exe \rcises!

stimulating - as well as fun. They can be a good alternative to
------=_NextPart_000_0017_01C862D0.F961B970-- From krj1140@att.net Tue Jan 29 12:05:19 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJttf-0002az-BX for ccamp-archive@ietf.org; Tue, 29 Jan 2008 12:05:19 -0500 Received: from [190.40.46.62] (helo=client-190.40.46.62.speedy.net.pe) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JJtte-00009F-HK for ccamp-archive@ietf.org; Tue, 29 Jan 2008 12:05:19 -0500 Message-ID: <000601c86299$066f591d$3537fab5@tuvljuw> From: "duane chi-pang" To: Subject: Save on Top Designer Brands Shoes Uggs Gucci Chanel Prada Dior Date: Tue, 29 Jan 2008 15:17:47 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01C86299.06694843" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 3.7 (+++) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 This is a multi-part message in MIME format. ------=_NextPart_000_0003_01C86299.06694843 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable They say first impressions are everything... Make sure you stand your ground when walking around, simply by walking = hard in Top Brand Name Designer Footwear. Forget department store prices, Enjoy DIRECT PRICING at more than 65% = OFF on a wide variety of 2008 Collections from Versace, Prada, Chanel, = Dior & More. =20 We also carry TOP BRANDS such as Uggs, Gucci, Dsquared, D&G, Bally, = Coach and much more. Find Loafers, Boots, High Heels, Sneakers and = Casual Shoes from Brand Names at less than WHOLESALE prices. Selection is available for Women and Men, Shipping is FREE WorldWide, = Trendy Fashion Footwear Sale of the YEAR! Forget Department Store Prices, Buy Direct=20 Visit Today! Click Here.... =20 =20 ------=_NextPart_000_0003_01C86299.06694843 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

They say first = impressions are everything...
Make sure you stand your ground when walking around, simply by walking = hard in Versace, = Prada, Chanel, Dior & More.

=20 We also carry TOP BRANDS such as Uggs, Gucci, Dsquared, D&G, Bally, = Coach and much more. Find Loafers, Boots, High Heels, Sneakers = and Casual Shoes from Brand Names at less than WHOLESALE prices.
Selection is available for Women and Men, Shipping is FREE WorldWide, = Trendy Fashion Footwear Sale of the YEAR!

Forget Department = Store Prices, Buy Direct
Visit Today! Click Here....
------=_NextPart_000_0003_01C86299.06694843-- From metal-Sarraf@ZUMIK.COM.PL Tue Jan 29 12:55:16 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJufz-0001l6-Ut for ccamp-archive@ietf.org; Tue, 29 Jan 2008 12:55:15 -0500 Received: from [151.73.117.163] (helo=[151.73.117.163]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JJufy-0002Bm-VJ for ccamp-archive@ietf.org; Tue, 29 Jan 2008 12:55:15 -0500 Received: by 10.206.60.67 with SMTP id bZVxFRFYrNNul; Wed, 30 Jan 2008 18:54:37 +0100 (GMT) Received: by 192.168.214.227 with SMTP id lakfNGNnQAFPmO.0462725857214; Wed, 30 Jan 2008 18:54:35 +0100 (GMT) Message-ID: <000a01c86369$2b4ef590$a3754997@pc> From: "metal Sarraf" To: Subject: sgningen Date: Wed, 30 Jan 2008 18:54:32 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01C86371.8D135D90" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 2.1 (++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ------=_NextPart_000_0003_01C86371.8D135D90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello ccamp-archive Amplified Passion and Desire; http://decidecompany.com metal Sarraf ------=_NextPart_000_0003_01C86371.8D135D90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello ccamp-archive
Amplified Passion and Desire;
http://decidecompany.com
metal Sarraf
------=_NextPart_000_0003_01C86371.8D135D90-- From owner-ccamp@ops.ietf.org Tue Jan 29 14:54:34 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJwXS-00010G-4i for ccamp-archive@ietf.org; Tue, 29 Jan 2008 14:54:34 -0500 Received: from psg.com ([2001:418:1::62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JJwXQ-0003Bj-8Q for ccamp-archive@ietf.org; Tue, 29 Jan 2008 14:54:34 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JJwNr-000NmC-Qu for ccamp-data@psg.com; Tue, 29 Jan 2008 19:44:39 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE, STOX_REPLY_TYPE autolearn=no version=3.2.3 Received: from [62.128.201.249] (helo=asmtp2.iomartmail.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JJwNo-000Nla-Sr for ccamp@ops.ietf.org; Tue, 29 Jan 2008 19:44:38 +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 m0TJiBKt019692; Tue, 29 Jan 2008 19:44:12 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 m0TJi77N019663; Tue, 29 Jan 2008 19:44:10 GMT Message-ID: <0c4301c862af$4e93ff60$0200a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "Ross Callon" , , "Scott Bradner" , "Brungard, Deborah A, ALABS" Subject: Draft liaison response to ITU on GMPLS Calls Date: Tue, 29 Jan 2008 19:43:45 -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.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Hi, We need to respond to a liaison from ITU-T Study Group 15 Question 14. https://datatracker.ietf.org/liaison/369/ Please comment before Saturday February 1st so I can send this in time. Thanks, Adrian ==== To: ITU-T Q14/15 Cc: Kam Lam, Steve Trowbridge, Ross Callon, Dave Ward, Scott Bradner, CCAMP Mailing List Subject: Respnse to Your Liaison on GMPLS Calls In Response Thank you for your liaison to CCAMP on GMPLS Calls from your Stuttgart interim meeting in September 2007. In your liaison, you noted that the GMPLS call is assumed to be as general as possible, and you asked what other call applications there may be in addition to ASON and the CCAMP VCAT draft. At this moment, there are four applications on which the CCAMP working group is working where GMPLS calls are applied. The first two are ASON and VCAT as you note. The third is related to ASON and is the multi-layer network. The fourth provides support for the MEF UNI in coordination with the OIF. Other topics in the future might include OAM coordination, billing, and client-facing port capability negotiation. Your observations about how TNA information is not used in the propagation or delivery of the [call] message, but may be used [by call controllers] to identify the destination UNI and hence [the destination] Network Call Controller agrees with our understanding and intentions. In practice, a large range of information may be used by call controllers to route calls - that is, to select a series of call controllers between call source and call destination - although we would not wish to preclude source-routing of calls. It is our intention that the generic call message should be capable of being extended to carry any information required by any application of the call message. In this light you ask for guidance on how to carry ASON call information across a GMPLS network so that it can be reconstructed at ASON call boundaries, and say that you support the resumption of work on a CCAMP I-D on ASON applicability to address the above and would welcome the opportunity to contribute through liaisons. We welcome your support and look forward to working with you in this context. As above, we note that the GMPLS call message (the Notify message) is not limited to the exchange of information between call end points, but can also exchange information between transit call controllers by forming call segments as described in section 7.3.1 of RFC 4974. Work on carrying ASON call information within a GMPLS call message falls within the CCAMP charter and we hope that interested parties will bring ideas forward through the normal process which is, of course, contribution-driven. We would welcome input from all sources either through the CCAMP mailing list or through liaisons. Best regards, Adrian Farrel and Deborah Brungard CCAMP working group co-chairs From owner-ccamp@ops.ietf.org Tue Jan 29 15:20:21 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJwwO-0000Pd-DE for ccamp-archive@ietf.org; Tue, 29 Jan 2008 15:20:20 -0500 Received: from psg.com ([2001:418:1::62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JJwwM-0003wS-3s for ccamp-archive@ietf.org; Tue, 29 Jan 2008 15:20:20 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JJwod-0000lE-IB for ccamp-data@psg.com; Tue, 29 Jan 2008 20:12:19 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [62.128.201.248] (helo=asmtp1.iomartmail.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JJwoa-0000jx-GT for ccamp@ops.ietf.org; Tue, 29 Jan 2008 20:12:18 +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 m0TKB41K017276; Tue, 29 Jan 2008 20:11:04 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 m0TKAxG6017224; Tue, 29 Jan 2008 20:11:03 GMT Message-ID: <0c6501c862b3$0f6ed950$0200a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "Ross Callon" , , "Scott Bradner" , "Brungard, Deborah A, ALABS" References: <0c4301c862af$4e93ff60$0200a8c0@your029b8cecfe> Subject: Re: Draft liaison response to ITU on GMPLS Calls Date: Tue, 29 Jan 2008 20:10:53 -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.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Duh-oh! Before Saturday February 2nd. Adrian ----- Original Message ----- From: "Adrian Farrel" To: Cc: "Ross Callon" ; ; "Scott Bradner" ; "Brungard, Deborah A, ALABS" Sent: Tuesday, January 29, 2008 7:43 PM Subject: Draft liaison response to ITU on GMPLS Calls > Hi, > > We need to respond to a liaison from ITU-T Study Group 15 Question 14. > https://datatracker.ietf.org/liaison/369/ > > Please comment before Saturday February 1st so I can send this in time. > > Thanks, > Adrian > > ==== > To: ITU-T Q14/15 > Cc: Kam Lam, Steve Trowbridge, Ross Callon, Dave Ward, Scott Bradner, > CCAMP Mailing List > Subject: Respnse to Your Liaison on GMPLS Calls > In Response > > Thank you for your liaison to CCAMP on GMPLS Calls from your Stuttgart > interim meeting in September 2007. > > In your liaison, you noted that the GMPLS call is assumed to be as general > as possible, and you asked what other call applications there may be in > addition to ASON and the CCAMP VCAT draft. At this moment, there are four > applications on which the CCAMP working group is working where GMPLS calls > are applied. The first two are ASON and VCAT as you note. The third is > related to ASON and is the multi-layer network. The fourth provides > support for the MEF UNI in coordination with the OIF. Other topics in the > future might include OAM coordination, billing, and client-facing port > capability negotiation. > > Your observations about how TNA information is not used in the propagation > or delivery of the [call] message, but may be used [by call controllers] > to identify the destination UNI and hence [the destination] Network Call > Controller agrees with our understanding and intentions. In practice, a > large range of information may be used by call controllers to route > calls - that is, to select a series of call controllers between call > source and call destination - although we would not wish to preclude > source-routing of calls. It is our intention that the generic call message > should be capable of being extended to carry any information required by > any application of the call message. > > In this light you ask for guidance on how to carry ASON call information > across a GMPLS network so that it can be reconstructed at ASON call > boundaries, and say that you support the resumption of work on a CCAMP I-D > on ASON applicability to address the above and would welcome the > opportunity to contribute through liaisons. We welcome your support and > look forward to working with you in this context. As above, we note that > the GMPLS call message (the Notify message) is not limited to the exchange > of information between call end points, but can also exchange information > between > transit call controllers by forming call segments as described in section > 7.3.1 of RFC 4974. Work on carrying ASON call information within a GMPLS > call message falls within the CCAMP charter and we hope that interested > parties will bring ideas forward through the normal process which is, of > course, contribution-driven. We would welcome input from all sources > either through the CCAMP mailing list or through liaisons. > > Best regards, > Adrian Farrel and Deborah Brungard > CCAMP working group co-chairs > > > From fernandoef70@findanabv.net Wed Jan 30 03:00:40 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JK7s8-0001c4-7e for ccamp-archive@ietf.org; Wed, 30 Jan 2008 03:00:40 -0500 Received: from cm234.gamma201.maxonline.com.sg ([202.156.201.234]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JK7s6-0002a7-Vm for ccamp-archive@ietf.org; Wed, 30 Jan 2008 03:00:39 -0500 Received: from [202.156.201.234] by smtp1.aicpa.org; Wed, 30 Jan 2008 16:00:38 +0800 From: "Rhonda Cabrera" To: Subject: ExtendedPhallusMatilda Date: Wed, 30 Jan 2008 16:00:38 +0800 Message-ID: <01c86359$415e5700$eac99cca@fernandoef70> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.2300 Importance: Normal X-Spam-Score: 4.5 (++++) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 CockRangyJoni http://www.carpotiues.com From brigsf8@reinstein.org Wed Jan 30 04:08:26 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JK8vi-0005AS-BU for ccamp-archive@ietf.org; Wed, 30 Jan 2008 04:08:26 -0500 Received: from m156.net81-65-159.noos.fr ([81.65.159.156] helo=sweet-5e5970ae4.noos.fr) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JK8vh-0004PJ-85 for ccamp-archive@ietf.org; Wed, 30 Jan 2008 04:08:26 -0500 Received: from [81.65.159.156] by smtp.secureserver.net; Wed, 30 Jan 2008 10:08:24 +0100 From: "Ward Glass" To: Subject: CyrilFuckstickHuge Date: Wed, 30 Jan 2008 10:08:24 +0100 Message-ID: <01c86328$0c85dc00$9c9f4151@brigsf8> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal X-Spam-Score: 2.9 (++) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 SpaciousCockSharon http://www.tobetobetobe.com From owner-ccamp@ops.ietf.org Wed Jan 30 04:10:36 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JK8xo-0008S7-GI for ccamp-archive@ietf.org; Wed, 30 Jan 2008 04:10:36 -0500 Received: from psg.com ([2001:418:1::62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JK8xm-0003Ho-LE for ccamp-archive@ietf.org; Wed, 30 Jan 2008 04:10:36 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JK8n1-000IYU-Pk for ccamp-data@psg.com; Wed, 30 Jan 2008 08:59:27 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [213.150.41.59] (helo=dkcphmx22.softcom.dk) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JK8mu-000IXR-Ux for ccamp@ops.ietf.org; Wed, 30 Jan 2008 08:59:22 +0000 Received: from gw.imc.kth.se (193.10.152.67) by dkcphmx22.softcom.dk (envelope-from ) with ESMTP. tag msg.1201683554.722014.11219 (Processed in 0.05592 secs); 30 Jan 2008 08:59:14 -0000 X-SoftScan-Status: clean Received: from DOMAIN1-MTA by mail1.imc.kth.se with Novell_GroupWise; Wed, 30 Jan 2008 09:59:14 +0100 Message-Id: <47A04A5B.F14F.0066.0@acreo.se> X-Mailer: Novell GroupWise Internet Agent 7.0.1 Date: Wed, 30 Jan 2008 09:58:47 +0100 From: "Roland Elverljung" To: Cc: "DEBORAH A ATTLABS BRUNGARD" Subject: Re: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt References: <449B2580D802A443A923DABF3EAB82AF10132C78@OCCLUST04EVS1.ugd.att.com> In-Reply-To: <449B2580D802A443A923DABF3EAB82AF10132C78@OCCLUST04EVS1.ugd.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -1.0 (-) X-Scan-Signature: 93238566e09e6e262849b4f805833007 In favor. Regards Roland Elverljung >>> On 2008-01-22 at 20:27, in message <449B2580D802A443A923DABF3EAB82AF10132C78@OCCLUST04EVS1.ugd.att.com>, wrote: > CCAMP, > > The DT proposed in their meeting presentation for their architecture and > framework document to be accepted as a WG draft: > http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt > > We received a couple of comments in the meeting, we would appreciate > additional feedback on the list. Please express your support (or > otherwise) for this I-D to become a WG draft. > > Thanks, > Deborah From owner-ccamp@ops.ietf.org Wed Jan 30 04:22:33 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JK99N-0003a0-7V for ccamp-archive@ietf.org; Wed, 30 Jan 2008 04:22:33 -0500 Received: from psg.com ([2001:418:1::62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JK99M-0003cV-0e for ccamp-archive@ietf.org; Wed, 30 Jan 2008 04:22:33 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JK92A-000JuS-NI for ccamp-data@psg.com; Wed, 30 Jan 2008 09:15:06 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [62.23.212.27] (helo=smail5.alcatel.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JK925-000JtY-LD for ccamp@ops.ietf.org; Wed, 30 Jan 2008 09:15:04 +0000 Received: from FRVELSBHS05.ad2.ad.alcatel.com (frvelsbhs05.ad2.ad.alcatel.com [155.132.6.77]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id m0U95O3G021848; Wed, 30 Jan 2008 10:06:05 +0100 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.51]) by FRVELSBHS05.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Wed, 30 Jan 2008 10:14:41 +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: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Date: Wed, 30 Jan 2008 10:14:37 +0100 Message-ID: In-Reply-To: <479F2458.6090201@pi.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Thread-Index: Achid4JetInOIvLXS36xGBjOv4vCdwAOqlZg References: <2ECAA42C79676B42AEBAC11229CA7D0C01C98951@E03MVB2-UKBR.domain1.systemhost.net> <479F2458.6090201@pi.se> From: "PAPADIMITRIOU Dimitri" To: "Loa Andersson" Cc: , , , , , X-OriginalArrivalTime: 30 Jan 2008 09:14:41.0110 (UTC) FILETIME=[8B87DF60:01C86320] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 8a85b14f27c9dcbe0719e27d46abc1f8 loa, i think the main point as ccamp is whether or not we poll for a change or a continuation inline with RFC3945 -- when the present doc. states:=20 "It is expected that there will be no case where an Eth-LSP will be signaled, or an Eth-LSP supporting interface will be represented, using the L2SC switching type/capability. A new switching type/capability is required to avoid any potential current usage of the L2SC switching type/capability in support of Ethernet. [...] "The L2SC Interface Switching Capabilities MUST NOT be used to represent interfaces capable of supporting Eth-LSPs." it raises three issues: a) what was the previous L2SC def. per RFC 3945 meant for if not for use also in GMPLS Ethernet context ? b) why a "new one" ?=20 this is not explained. c) what is the "new one" implying in terms of GMPLS ? for inst. in the intro "The intent of this document is to reuse and align with as much of the GMPLS protocols as possible." leaves open the issue of what as much as possible means. and on the other "Additions are made only to accommodate features of Ethernet that are not already supported by GMPLS." so, how shall i interpreet the first sentence now ? inline with point a) and b) ? the doc. in WG I-D status or not is not going to provide an answer to these questions. sentences and statements in the doc. contradict each other. thanks, -d. > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.se]=20 > Sent: Tuesday, January 29, 2008 2:04 PM > To: PAPADIMITRIOU Dimitri > Cc: neil.2.harrison@bt.com; benjamin.niven-jenkins@bt.com;=20 > lberger@labn.net; dwfedyk@nortel.com; dbrungard@att.com;=20 > ccamp@ops.ietf.org > Subject: Re: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt >=20 > Dimitri, >=20 > it is possible that you have a point that needs to be discussed, > but is this really something that should stop us from adopting the > doc as a working group document. >=20 > /Loa >=20 > PAPADIMITRIOU Dimitri wrote: > > neil,=20 > >=20 > >> -----Original Message----- > >> From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]=20 > >> Sent: Friday, January 25, 2008 2:27 PM > >> To: PAPADIMITRIOU Dimitri; benjamin.niven-jenkins@bt.com;=20 > >> lberger@labn.net > >> Cc: dwfedyk@nortel.com; dbrungard@att.com; ccamp@ops.ietf.org > >> Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt > >> > >> Dimitri....see if this helps...in-line > >> > >>> -----Original Message----- > >>> From: owner-ccamp@ops.ietf.org=20 > >>> [mailto:owner-ccamp@ops.ietf.org] On Behalf Of=20 > PAPADIMITRIOU Dimitri > >>> Sent: 25 January 2008 11:36 > >>> To: Niven-jenkins,B,Ben,DMF R; Lou Berger > >>> Cc: Don Fedyk; BRUNGARD, DEBORAH A, ATTLABS; ccamp@ops.ietf.org > >>> Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt > >>> > >>> > >>> ben=20 > >>> > >>>> -----Original Message----- > >>>> From: Ben Niven-Jenkins [mailto:benjamin.niven-jenkins@bt.com] > >>>> Sent: Thursday, January 24, 2008 3:40 PM > >>>> To: PAPADIMITRIOU Dimitri; Lou Berger > >>>> Cc: Don Fedyk; BRUNGARD, DEBORAH A, ATTLABS; ccamp@ops.ietf.org > >>>> Subject: Re: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt > >>>> > >>>> Dimitri, > >>>> > >>>> I find your mail somewhat puzzling. > >>>> > >>>> You appear to be saying that GMPLS as per RFC 3945 is set=20 > >>> in stone and=20 > >>>> nothing should modify/enhance the behaviour as specified=20 > >> in RFC3945=20 > >>>> which implies that when RFC3945 was produced the crystal=20 > ball was=20 > >>>> working extremely well and all possible future=20 > applications of the > >>>> technology had > >>>> been correctly envisaged. I don't believe that was the case. > >>> this is not what i say. i am concerned in stating beforehand=20 > >>> RFC 3945 (GMPLS Arch.) is not applicable to Ethernet. Why the=20 > >>> doc. does not deliver any tangible explanation. > >> NH=3D> Is your problem that you cannot differentiate between=20 > >> the 3 network modes (of co-cs, co-ps and cl-ps)? =20 > >=20 > > my concern wrt specific point you bring is that the today=20 > definition in > > RFC 3945 for L2SC, and in the present case GMPLS for Ethernet (with > > local labels or domain-wide labels or any other equivalent=20 > to "co-ps") > > does not result into a different definition than what's in.=20 > on the other > > side, i do not see how would apply GMPLS for connectionless/bridged > > Ethernet. =20 > >=20 > > note also that GMPLS induces label from the interface and link > > characteristic (i.e. there is no "label type" in the=20 > label/label request > > object. > >=20 > >> If so then looking at the work on > >> unified modelling in SG15/Q12 may help you. But to give a=20 > >> more specific > >> example here: We can take an Ethernet traffic unit and=20 > >> create either a > >> cl-ps and co-ps layer network based on this...in fact one=20 > can image 3 > >> different layer network cases here: > >> - traditional Etherent which does not have a directed routing > >> function, ie uses MAC learning, broadcast unknown, STP...this=20 > >> is a cl-ps > >> layer network > >> - Ethernet with an IGP providing a directed routing > >> function....this is also a cl-ps layer network, but it is=20 > different to > >> the one above > >> - Ethernet with a directed routing component (centralised or > >> distributed, ie IGP) and a signalling component that can create > >> connections....this would be a co-ps layer network. > >> > >> These are all based on a similar traffic unit, however they=20 > >> form 3 quite > >> different layer networks (and in functional architecture=20 > >> terms we would > >> say 'the Characteristic Information is different in the 3 cases'). > >> > >> Now GMPLS is applying a reusable set of CP components=20 > (which is a very > >> good thing, as Ben points out below) for any co-cs or=20 > co-ps mode layer > >> network. So we are setting up *connections* in either a=20 > >> space, freq or > >> time dimension of resource, and it is these 3 resource=20 > dimensions that > >> create the differences in parameters...however, the notion of a > >> connection is common across all these resource dimensions.=20 > GMPLS does > >> not apply to the cl-ps mode, as it plainly does not have=20 > connections. > >=20 > > well indeed, and this is the reason why i do not see any reason to > > open the space for a different set of mechanisms that would result > > from this new interface switching definition. > >=20 > > thanks, > > -d. > > =20 > >> That is at least how I look at this issue. > >> > >> regards, Neil > >>>>> the question triggered by this poll is the following: if=20 > >>> GMPLS for=20 > >>>>> Ethernet is not inline with the existing stacks what is=20 > >>> the value of=20 > >>>>> GMPLS re-use ? what's the value to borrow the term GMPLS=20 > >>> without its=20 > >>>>> substance ? and in practice, the issue is, if it is not > >>>> GMPLS per RFC > >>>>> 3945, what's the value compared to any other native control > >>>> stack that > >>>>> would be developed at IEEE for inst. for these techno's. > >>>> If we ignore the peer model (which is unworkable in reality > >>>> IMO), the value > >>>> is obvious - significant reuse of existing code, techniques,=20 > >>>> knowledge, > >>>> skills, etc. > >>>> > >>>> So, we should develop the control plane from scratch=20 > >>> because Ethernet=20 > >>>> requires a few modifications/enhancements (which I believe are=20 > >>>> backwards > >>>> compatible) to RFC3945 - that IMO is ridiculous. > >>> so you seem to agree with me. departing from RFC 3945 makes=20 > >>> little sense. it would have been interesting to see the doc=20 > >>> delivering a FIT of the GMPLS protocol arch. blocks and, in=20 > >>> particular, label allocation and distribution for Ethernet. > >>> > >>> thanks, > >>> -dimitri. > >>>> Ben > >>>> > >>>> > >>> > >=20 > >=20 > >=20 >=20 >=20 > --=20 > Loa Andersson >=20 > Principal Networking Architect > Acreo AB phone: +46 8 632 77 14 > Isafjordsgatan 22 mobile: +46 739 81 21 64 > Kista, Sweden email: loa.andersson@acreo.se > loa@pi.se >=20 From owner-ccamp@ops.ietf.org Wed Jan 30 06:17:42 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKAwn-0000fX-Vi for ccamp-archive@ietf.org; Wed, 30 Jan 2008 06:17:41 -0500 Received: from psg.com ([2001:418:1::62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JKAwk-0005pU-Co for ccamp-archive@ietf.org; Wed, 30 Jan 2008 06:17:41 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JKAoG-0005Ml-5B for ccamp-data@psg.com; Wed, 30 Jan 2008 11:08:52 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [193.180.251.60] (helo=mailgw3.ericsson.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JKAoA-0005M7-DK for ccamp@ops.ietf.org; Wed, 30 Jan 2008 11:08:49 +0000 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 38C2720A48; Wed, 30 Jan 2008 12:08:43 +0100 (CET) X-AuditID: c1b4fb3c-aa2ecbb0000007e0-9f-47a05abb86b7 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 19D8E21011; Wed, 30 Jan 2008 12:08:43 +0100 (CET) Received: from esealmw118.eemea.ericsson.se ([153.88.200.77]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 Jan 2008 12:08:31 +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: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Date: Wed, 30 Jan 2008 12:08:30 +0100 Message-ID: <56D2F550769FAA4CA70D5B2EB8419F1402A3A51E@esealmw118.eemea.ericsson.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Thread-Index: Achid4JetInOIvLXS36xGBjOv4vCdwAOqlZgAB8MVpA= References: <2ECAA42C79676B42AEBAC11229CA7D0C01C98951@E03MVB2-UKBR.domain1.systemhost.net> <479F2458.6090201@pi.se> From: "Howard Green" To: "PAPADIMITRIOU Dimitri" , "Loa Andersson" Cc: , , , , , X-OriginalArrivalTime: 30 Jan 2008 11:08:31.0624 (UTC) FILETIME=[72D59880:01C86330] X-Brightmail-Tracker: AAAAAA== Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -1.0 (-) X-Scan-Signature: 71f780ffdd80c541d3e75aa5f2710d3d Hi Dimitri seems to me to be making a very abstract and legalistic point. =20 The reason why this work is important is that the IEEE has been evolving Ethernet to give it carrier class features, in respect of scalability, OAM, and (with 802.1Qay) the possibility to use an external control plane. Some of these features will very likely require or enable added value from extensions to the functionality of GMPLS - for example, as has already been suggested, the addition of functionality for creating the OAM associations. Therefore this will likely not be the same as the possible use suggested in RFC3945, which may (at least in theory) have been implemented somewhere. Therefore the suggestion in the draft seems to make sense. I can't really see what important principle is being defended by the insistence upon L2SC, which, as Don Fedyk stated, was always somewhat underspecified. This is not something to be debated in the abstract. The work in ccamp should allow sensible extension of functionality where it adds value, and this needs to be discussed on a case by case basis. Therefore we should make it a working group document and get on with it. regards Howard Green -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of PAPADIMITRIOU Dimitri Sent: 30 January 2008 10:15 To: Loa Andersson Cc: neil.2.harrison@bt.com; benjamin.niven-jenkins@bt.com; lberger@labn.net; dwfedyk@nortel.com; dbrungard@att.com; ccamp@ops.ietf.org Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt loa, i think the main point as ccamp is whether or not we poll for a change or a continuation inline with RFC3945 -- when the present doc. states:=20 "It is expected that there will be no case where an Eth-LSP will be signaled, or an Eth-LSP supporting interface will be represented, using the L2SC switching type/capability. A new switching type/capability is required to avoid any potential current usage of the L2SC switching type/capability in support of Ethernet. [...] "The L2SC Interface Switching Capabilities MUST NOT be used to represent interfaces capable of supporting Eth-LSPs." it raises three issues: a) what was the previous L2SC def. per RFC 3945 meant for if not for use also in GMPLS Ethernet context ? b) why a "new one" ?=20 this is not explained. c) what is the "new one" implying in terms of GMPLS ? for inst. in the intro "The intent of this document is to reuse and align with as much of the GMPLS protocols as possible." leaves open the issue of what as much as possible means. and on the other "Additions are made only to accommodate features of Ethernet that are not already supported by GMPLS." so, how shall i interpreet the first sentence now ? inline with point a) and b) ? the doc. in WG I-D status or not is not going to provide an answer to these questions. sentences and statements in the doc. contradict each other. thanks, -d. > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.se] > Sent: Tuesday, January 29, 2008 2:04 PM > To: PAPADIMITRIOU Dimitri > Cc: neil.2.harrison@bt.com; benjamin.niven-jenkins@bt.com;=20 > lberger@labn.net; dwfedyk@nortel.com; dbrungard@att.com;=20 > ccamp@ops.ietf.org > Subject: Re: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt >=20 > Dimitri, >=20 > it is possible that you have a point that needs to be discussed, but=20 > is this really something that should stop us from adopting the doc as=20 > a working group document. >=20 > /Loa >=20 > PAPADIMITRIOU Dimitri wrote: > > neil, > >=20 > >> -----Original Message----- > >> From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] > >> Sent: Friday, January 25, 2008 2:27 PM > >> To: PAPADIMITRIOU Dimitri; benjamin.niven-jenkins@bt.com;=20 > >> lberger@labn.net > >> Cc: dwfedyk@nortel.com; dbrungard@att.com; ccamp@ops.ietf.org > >> Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt > >> > >> Dimitri....see if this helps...in-line > >> > >>> -----Original Message----- > >>> From: owner-ccamp@ops.ietf.org > >>> [mailto:owner-ccamp@ops.ietf.org] On Behalf Of > PAPADIMITRIOU Dimitri > >>> Sent: 25 January 2008 11:36 > >>> To: Niven-jenkins,B,Ben,DMF R; Lou Berger > >>> Cc: Don Fedyk; BRUNGARD, DEBORAH A, ATTLABS; ccamp@ops.ietf.org > >>> Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt > >>> > >>> > >>> ben > >>> > >>>> -----Original Message----- > >>>> From: Ben Niven-Jenkins [mailto:benjamin.niven-jenkins@bt.com] > >>>> Sent: Thursday, January 24, 2008 3:40 PM > >>>> To: PAPADIMITRIOU Dimitri; Lou Berger > >>>> Cc: Don Fedyk; BRUNGARD, DEBORAH A, ATTLABS; ccamp@ops.ietf.org > >>>> Subject: Re: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt > >>>> > >>>> Dimitri, > >>>> > >>>> I find your mail somewhat puzzling. > >>>> > >>>> You appear to be saying that GMPLS as per RFC 3945 is set > >>> in stone and > >>>> nothing should modify/enhance the behaviour as specified > >> in RFC3945 > >>>> which implies that when RFC3945 was produced the crystal > ball was > >>>> working extremely well and all possible future > applications of the > >>>> technology had > >>>> been correctly envisaged. I don't believe that was the case. > >>> this is not what i say. i am concerned in stating beforehand RFC=20 > >>> 3945 (GMPLS Arch.) is not applicable to Ethernet. Why the doc.=20 > >>> does not deliver any tangible explanation. > >> NH=3D> Is your problem that you cannot differentiate between the 3=20 > >> network modes (of co-cs, co-ps and cl-ps)? > >=20 > > my concern wrt specific point you bring is that the today > definition in > > RFC 3945 for L2SC, and in the present case GMPLS for Ethernet (with=20 > > local labels or domain-wide labels or any other equivalent > to "co-ps") > > does not result into a different definition than what's in.=20 > on the other > > side, i do not see how would apply GMPLS for connectionless/bridged=20 > > Ethernet. > >=20 > > note also that GMPLS induces label from the interface and link=20 > > characteristic (i.e. there is no "label type" in the > label/label request > > object. > >=20 > >> If so then looking at the work on > >> unified modelling in SG15/Q12 may help you. But to give a more=20 > >> specific example here: We can take an Ethernet traffic unit and=20 > >> create either a cl-ps and co-ps layer network based on this...in=20 > >> fact one > can image 3 > >> different layer network cases here: > >> - traditional Etherent which does not have a directed routing > >> function, ie uses MAC learning, broadcast unknown, STP...this is a=20 > >> cl-ps layer network > >> - Ethernet with an IGP providing a directed routing > >> function....this is also a cl-ps layer network, but it is > different to > >> the one above > >> - Ethernet with a directed routing component (centralised or > >> distributed, ie IGP) and a signalling component that can create=20 > >> connections....this would be a co-ps layer network. > >> > >> These are all based on a similar traffic unit, however they form 3=20 > >> quite different layer networks (and in functional architecture=20 > >> terms we would say 'the Characteristic Information is different in=20 > >> the 3 cases'). > >> > >> Now GMPLS is applying a reusable set of CP components > (which is a very > >> good thing, as Ben points out below) for any co-cs or > co-ps mode layer > >> network. So we are setting up *connections* in either a space,=20 > >> freq or time dimension of resource, and it is these 3 resource > dimensions that > >> create the differences in parameters...however, the notion of a=20 > >> connection is common across all these resource dimensions. > GMPLS does > >> not apply to the cl-ps mode, as it plainly does not have > connections. > >=20 > > well indeed, and this is the reason why i do not see any reason to=20 > > open the space for a different set of mechanisms that would result=20 > > from this new interface switching definition. > >=20 > > thanks, > > -d. > > =20 > >> That is at least how I look at this issue. > >> > >> regards, Neil > >>>>> the question triggered by this poll is the following: if > >>> GMPLS for > >>>>> Ethernet is not inline with the existing stacks what is > >>> the value of > >>>>> GMPLS re-use ? what's the value to borrow the term GMPLS > >>> without its > >>>>> substance ? and in practice, the issue is, if it is not > >>>> GMPLS per RFC > >>>>> 3945, what's the value compared to any other native control > >>>> stack that > >>>>> would be developed at IEEE for inst. for these techno's. > >>>> If we ignore the peer model (which is unworkable in reality IMO), > >>>> the value is obvious - significant reuse of existing code,=20 > >>>> techniques, knowledge, skills, etc. > >>>> > >>>> So, we should develop the control plane from scratch > >>> because Ethernet > >>>> requires a few modifications/enhancements (which I believe are=20 > >>>> backwards > >>>> compatible) to RFC3945 - that IMO is ridiculous. > >>> so you seem to agree with me. departing from RFC 3945 makes little > >>> sense. it would have been interesting to see the doc delivering a=20 > >>> FIT of the GMPLS protocol arch. blocks and, in particular, label=20 > >>> allocation and distribution for Ethernet. > >>> > >>> thanks, > >>> -dimitri. > >>>> Ben > >>>> > >>>> > >>> > >=20 > >=20 > >=20 >=20 >=20 > -- > Loa Andersson >=20 > Principal Networking Architect > Acreo AB phone: +46 8 632 77 14 > Isafjordsgatan 22 mobile: +46 739 81 21 64 > Kista, Sweden email: loa.andersson@acreo.se > loa@pi.se >=20 From figen-McBride@LiveTwinksCam.com Wed Jan 30 10:24:43 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKEnr-0003pV-GP for ccamp-archive@ietf.org; Wed, 30 Jan 2008 10:24:43 -0500 Received: from [151.59.69.53] (helo=[151.59.69.53]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JKEno-0003KK-R3 for ccamp-archive@ietf.org; Wed, 30 Jan 2008 10:24:41 -0500 Received: by 10.54.186.38 with SMTP id rmwFVyCjdzNNR; Wed, 30 Jan 2008 16:24:46 +0100 (GMT) Received: by 192.168.162.38 with SMTP id DTEowjryavNLKt.2189446830339; Wed, 30 Jan 2008 16:24:44 +0100 (GMT) Message-ID: <000501c86354$3bf035e0$35453b97@flu8qy9vb3o8q0c> From: "figen McBride" To: Subject: ettezgew Date: Wed, 30 Jan 2008 16:24:41 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C8635C.9DB49DE0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 1.5 (+) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ------=_NextPart_000_0009_01C8635C.9DB49DE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Night ccamp-archive Accelerates Recovery from Prior Intercourse; http://waitvillage.com figen McBride ------=_NextPart_000_0009_01C8635C.9DB49DE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Night ccamp-archive
Accelerates Recovery from Prior = Intercourse;
http://waitvillage.com
figen McBride
------=_NextPart_000_0009_01C8635C.9DB49DE0-- From owner-ccamp@ops.ietf.org Wed Jan 30 10:44:14 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKF6k-0002Bm-Mq for ccamp-archive@ietf.org; Wed, 30 Jan 2008 10:44:14 -0500 Received: from psg.com ([2001:418:1::62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JKF6i-0007dJ-Gb for ccamp-archive@ietf.org; Wed, 30 Jan 2008 10:44:14 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JKEqm-000DW0-FL for ccamp-data@psg.com; Wed, 30 Jan 2008 15:27:44 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE, STOX_REPLY_TYPE autolearn=no version=3.2.3 Received: from [62.128.201.248] (helo=asmtp1.iomartmail.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JKEqj-000DVS-Cg for ccamp@ops.ietf.org; Wed, 30 Jan 2008 15:27:43 +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 m0UFRdL9014292 for ; Wed, 30 Jan 2008 15:27:39 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 m0UFRbQC014272 for ; Wed, 30 Jan 2008 15:27:39 GMT Message-ID: <0df801c86354$a266fc00$0200a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: References: <2ECAA42C79676B42AEBAC11229CA7D0C01C98951@E03MVB2-UKBR.domain1.systemhost.net> <479F2458.6090201@pi.se> <56D2F550769FAA4CA70D5B2EB8419F1402A3A51E@esealmw118.eemea.ericsson.se> Subject: Re: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Date: Wed, 30 Jan 2008 15:27: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.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 All, We appear to be seeing good support for this document, and that suggests that we should take it forward, but I would like to at least make an attempt to close down the point raised by Dimitri. As Howard points out, this is in danger of becoming a legalistic discussion, but I've never been one to refuse the opportunity to back to first principles... In RFC 3945 we have... A link may support a set of encoding formats, where support means that a link is able to carry and switch a signal of one or more of these encoding formats. The Switching Type indicates then the type of switching that should be performed on a particular link for that LSP. This information is needed for links that advertise more than one type of switching capability. Nodes must verify that the type indicated in the Switching Type is supported on the corresponding incoming interface; otherwise, the node must generate a notification message with a "Routing problem/Switching Type" indication. Now, the question is whether we are introducing one (or more) new Switching Type and whether we need to be able to distinguish between them. Suppose (for the sake of argument) that we will over time introduce the ability to switch Ethernet frames under GMPLS control based on several different label concepts: - 802.1Qay - destination MAC only - destination MAC and VLAN tag It is likely that a GMPLS-capable Ethernet switch will want to support more than one of these switching paradigms on any single interface. So we have to decide how, during signaling, we indicate which type of LSP is requested. There are plenty of ways that this could be done. Currently we use a combination of the parameters of the Generalized_Label_Request object and the Sender_TSpec object. The TSpec is used in the case of TDM (RFC 4606) and Ethernet to distinguish the Switching Granularity (draft-ietf-ccamp-ethernet-traffic-parameters). As I see it, the text at issue in draft-gmpls-ethernet-arch-00.txt causes a problem because it appears to say that *no* Ethernet Label Switched Path (Eth-LSP) can be set up using an L2SC Switching Type. It is expected that there will be no case where an Eth-LSP will be signaled, or an Eth-LSP supporting interface will be represented, using the L2SC switching type/capability. However, the draft also says... A new switching type/capability is required to avoid any potential current usage of the L2SC switching type/capability in support of Ethernet. And this clearly says that L2SC *is* allowed. Can we fix this by agreeing some new wording? == OLD This document does not define any specific format for an Eth-LSP label. Rather, it is expected that service specific documents will define any signaling and routing extensions needed to support that specific Ethernet service. Depending on the requirements of a service, it may be necessary to define multiple GMPLS extensions, e.g., label formats, switching types, and Traffic Engineering (TE) routing extensions. It is expected that all such extensions will be consistent with this document. It is expected that there will be no case where an Eth-LSP will be signaled, or an Eth-LSP supporting interface will be represented, using the L2SC switching type/capability. A new switching type/capability is required to avoid any potential current usage of the L2SC switching type/capability in support of Ethernet. NEW This document does not define any specific format for an Eth-LSP label. Rather, it is expected that service specific documents will define any signaling and routing extensions needed to support that specific Ethernet service. Depending on the requirements of a service, it may be necessary to define multiple GMPLS protocol extensions and procedures. It is expected that all such extensions will be consistent with this document. It is expected that key a requirement will be to describe label formats and encodings. It may also be necessary to provide a mechanism to identify the required Ethernet service type in signaling and a way to advertise the capabilities of Ethernet switches in the routing protocols. These mechanisms must make it possible to distinguish between requests for different paradigms including new, future, and existing paradigms. The Switching Type and Interface Switching Capability Descriptor share a common set of values and are defined in [RFC3945], [RFC3471], and [RFC4202] as indicators of the type of switching that should ([RFC3471]) and can ([RFC4202]) be performed on a particular link for an LSP. The L2SC switching type is available for use by implementations performing layer 2 switching including ATM and Ethernet. To support the continued use of that switching type by existing implementations as well as to distinguish between each new Ethernet switching paradigm, a new switching type is expected to be needed for each new Ethernet switching paradigm that is supported. == Thanks, Adrian From sivakuma@3g-italy.com Wed Jan 30 10:48:09 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKFAX-00059h-Ny for ccamp-archive@ietf.org; Wed, 30 Jan 2008 10:48:09 -0500 Received: from balnet-gw.anders.ru ([81.91.178.150] helo=81.91.178.150) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JKFAX-00047m-7c for ccamp-archive@ietf.org; Wed, 30 Jan 2008 10:48:09 -0500 Message-ID: <000601c86357$047c75ed$31594da6@advgtrt> From: "ham francisc" To: Subject: give yourself a watch Date: Wed, 30 Jan 2008 14:00:45 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 2.6 (++) X-Scan-Signature: 08e48e05374109708c00c6208b534009 We have the biggest selection of purses, watches, wallets, lighters, everything from rolly, omega, to louis V, Dior and more... check it http://acemst.com Get it all at one place, LV, Dior, Rolly, Patek, Handbgs, wallets, lights, anything you can think of we have. come see for yourself From _karina@abq.sysco.com Wed Jan 30 11:11:26 2008 Return-path: <_karina@abq.sysco.com> Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKFX4-0005sd-Ag for ccamp-archive@ietf.org; Wed, 30 Jan 2008 11:11:26 -0500 Received: from dyn-91-165-174-157.ppp.tiscali.fr ([91.165.174.157]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JKFX3-0005lq-Ke for ccamp-archive@ietf.org; Wed, 30 Jan 2008 11:11:26 -0500 Message-ID: <000601c8635a$07444e78$ed8c57a0@urbaoqus> From: "bat abelard" <_karina@abq.sysco.com> To: Subject: Ordinary men have ordinary se.>.< Prove her that you are outstaning guy Date: Wed, 30 Jan 2008 14:24:00 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01C8635A.074123D8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 3.5 (+++) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 This is a multi-part message in MIME format. ------=_NextPart_000_0003_01C8635A.074123D8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Improbable effect on PE! ------=_NextPart_000_0003_01C8635A.074123D8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Improbable effect on = PE! ------=_NextPart_000_0003_01C8635A.074123D8-- From owner-ccamp@ops.ietf.org Wed Jan 30 11:47:36 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKG64-0001M5-25 for ccamp-archive@ietf.org; Wed, 30 Jan 2008 11:47:36 -0500 Received: from psg.com ([2001:418:1::62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JKG63-0001cS-5T for ccamp-archive@ietf.org; Wed, 30 Jan 2008 11:47:36 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JKFyc-000L70-DC for ccamp-data@psg.com; Wed, 30 Jan 2008 16:39:54 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [47.129.242.57] (helo=zcars04f.nortel.com) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JKFyZ-000L6c-9w for ccamp@ops.ietf.org; Wed, 30 Jan 2008 16:39:52 +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 m0UGdi715743; Wed, 30 Jan 2008 16:39:44 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: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Date: Wed, 30 Jan 2008 11:39:27 -0500 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA4136237B1@zrtphxm2.corp.nortel.com> In-Reply-To: <0df801c86354$a266fc00$0200a8c0@your029b8cecfe> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Thread-Index: AchjV50rUy/wB/z6TMO8U1IqHGt09gABMNqQ References: <2ECAA42C79676B42AEBAC11229CA7D0C01C98951@E03MVB2-UKBR.domain1.systemhost.net> <479F2458.6090201@pi.se> <56D2F550769FAA4CA70D5B2EB8419F1402A3A51E@esealmw118.eemea.ericsson.se> <0df801c86354$a266fc00$0200a8c0@your029b8cecfe> From: "Don Fedyk" To: "Adrian Farrel" , Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Hi Adrian This sounds good to me and certainly it was not our intent to confuse these points. If the new text can us forward that would be great.=20 Thanks, Don =20 > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel > Sent: Wednesday, January 30, 2008 10:28 AM > To: ccamp@ops.ietf.org > Subject: Re: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt >=20 > All, >=20 > We appear to be seeing good support for this document, and=20 > that suggests=20 > that we should take it forward, but I would like to at least=20 > make an attempt=20 > to close down the point raised by Dimitri. As Howard points=20 > out, this is in=20 > danger of becoming a legalistic discussion, but I've never=20 > been one to=20 > refuse the opportunity to back to first principles... >=20 > In RFC 3945 we have... >=20 > A link may support a set of encoding formats, where support means > that a link is able to carry and switch a signal of one or more of > these encoding formats. The Switching Type indicates then the type > of switching that should be performed on a particular link for that > LSP. This information is needed for links that advertise more than > one type of switching capability. >=20 > Nodes must verify that the type indicated in the Switching Type is > supported on the corresponding incoming interface; otherwise, the > node must generate a notification message with a "Routing > problem/Switching Type" indication. >=20 > Now, the question is whether we are introducing one (or more)=20 > new Switching=20 > Type and whether we need to be able to distinguish between=20 > them. Suppose=20 > (for the sake of argument) that we will over time introduce=20 > the ability to=20 > switch Ethernet frames under GMPLS control based on several=20 > different label=20 > concepts: > - 802.1Qay > - destination MAC only > - destination MAC and VLAN tag > It is likely that a GMPLS-capable Ethernet switch will want=20 > to support more=20 > than one of these switching paradigms on any single=20 > interface. So we have to=20 > decide how, during signaling, we indicate which type of LSP=20 > is requested. >=20 > There are plenty of ways that this could be done. Currently we use a=20 > combination of the parameters of the=20 > Generalized_Label_Request object and=20 > the Sender_TSpec object. The TSpec is used in the case of TDM=20 > (RFC 4606) and=20 > Ethernet to distinguish the Switching Granularity=20 > (draft-ietf-ccamp-ethernet-traffic-parameters). >=20 > As I see it, the text at issue in=20 > draft-gmpls-ethernet-arch-00.txt causes a=20 > problem because it appears to say that *no* Ethernet Label=20 > Switched Path=20 > (Eth-LSP) can be set up using an L2SC Switching Type. > It is expected that there will be no > case where an Eth-LSP will be signaled, or an Eth-LSP supporting > interface will be represented, using the L2SC switching > type/capability. >=20 > However, the draft also says... > A new switching type/capability is required to > avoid any potential current usage of the L2SC switching > type/capability in support of Ethernet. >=20 > And this clearly says that L2SC *is* allowed. >=20 > Can we fix this by agreeing some new wording? >=20 > =3D=3D > OLD > This document does not define any specific format for an Eth-LSP > label. Rather, it is expected that service specific documents will > define any signaling and routing extensions needed to support that > specific Ethernet service. Depending on the requirements of a > service, it may be necessary to define multiple GMPLS extensions, > e.g., label formats, switching types, and Traffic Engineering (TE) > routing extensions. It is expected that all such=20 > extensions will be > consistent with this document. It is expected that there will be no > case where an Eth-LSP will be signaled, or an Eth-LSP supporting > interface will be represented, using the L2SC switching > type/capability. A new switching type/capability is required to > avoid any potential current usage of the L2SC switching > type/capability in support of Ethernet. > NEW > This document does not define any specific format for an Eth-LSP > label. Rather, it is expected that service specific documents will > define any signaling and routing extensions needed to support that > specific Ethernet service. Depending on the requirements of a > service, it may be necessary to define multiple GMPLS protocol > extensions and procedures. It is expected that all such extensions > will be consistent with this document. >=20 > It is expected that key a requirement will be to describe label > formats and encodings. It may also be necessary to provide a > mechanism to identify the required Ethernet service type=20 > in signaling > and a way to advertise the capabilities of Ethernet switches in the > routing protocols. These mechanisms must make it possible to > distinguish between requests for different paradigms including new, > future, and existing paradigms. >=20 > The Switching Type and Interface Switching Capability Descriptor > share a common set of values and are defined in [RFC3945],=20 > [RFC3471], > and [RFC4202] as indicators of the type of switching that should > ([RFC3471]) and can ([RFC4202]) be performed on a=20 > particular link for > an LSP. The L2SC switching type is available for use by > implementations performing layer 2 switching including ATM and > Ethernet. To support the continued use of that switching type by > existing implementations as well as to distinguish between each new > Ethernet switching paradigm, a new switching type is expected to be > needed for each new Ethernet switching paradigm that is supported. > =3D=3D >=20 > Thanks, > Adrian=20 >=20 >=20 >=20 >=20 From owner-ccamp@ops.ietf.org Wed Jan 30 12:30:47 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKGlr-00066U-Kf for ccamp-archive@ietf.org; Wed, 30 Jan 2008 12:30:47 -0500 Received: from psg.com ([2001:418:1::62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JKGlp-0003JZ-4D for ccamp-archive@ietf.org; Wed, 30 Jan 2008 12:30:47 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JKGel-000Prc-Lm for ccamp-data@psg.com; Wed, 30 Jan 2008 17:23:27 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [64.208.49.5] (helo=smail6.alcatel.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JKGeg-000Pqb-Ll for ccamp@ops.ietf.org; Wed, 30 Jan 2008 17:23:25 +0000 Received: from FRVELSBHS07.ad2.ad.alcatel.com (frvelsbhs07.ad2.ad.alcatel.com [155.132.6.79]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id m0UHMqHi002467; Wed, 30 Jan 2008 18:22:52 +0100 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.51]) by FRVELSBHS07.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Wed, 30 Jan 2008 18:23:04 +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: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Date: Wed, 30 Jan 2008 18:23:00 +0100 Message-ID: In-Reply-To: <56D2F550769FAA4CA70D5B2EB8419F1402A3A51E@esealmw118.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Thread-Index: Achid4JetInOIvLXS36xGBjOv4vCdwAOqlZgAB8MVpAADGxFgA== References: <2ECAA42C79676B42AEBAC11229CA7D0C01C98951@E03MVB2-UKBR.domain1.systemhost.net> <479F2458.6090201@pi.se> <56D2F550769FAA4CA70D5B2EB8419F1402A3A51E@esealmw118.eemea.ericsson.se> From: "PAPADIMITRIOU Dimitri" To: "Howard Green" , "Loa Andersson" Cc: , , , , , X-OriginalArrivalTime: 30 Jan 2008 17:23:04.0058 (UTC) FILETIME=[C572E5A0:01C86364] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: fac892abe0c719c7bb99f6e7c710cdae =20 > -----Original Message----- > From: Howard Green [mailto:howard.green@ericsson.com]=20 > Sent: Wednesday, January 30, 2008 12:09 PM > To: PAPADIMITRIOU Dimitri; Loa Andersson > Cc: neil.2.harrison@bt.com; benjamin.niven-jenkins@bt.com;=20 > lberger@labn.net; dwfedyk@nortel.com; dbrungard@att.com;=20 > ccamp@ops.ietf.org > Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt >=20 > Hi > Dimitri seems to me to be making a very abstract and legalistic point. receive my total disagreement. an individual submission that asks to change an existing RFC requires discussion and particular attention (in part., when it is the protocol arch. document) - if this not possible then probably you have to write also a doc. asking for changing the IETF proces - and then you come back with your individual submission. =20 > The reason why this work is important is that the IEEE has=20 > been evolving > Ethernet to give it carrier class features, in respect of scalability, > OAM, and (with 802.1Qay) the possibility to use an external control > plane.=20 no one i think question this. and i don't think the poll is on this specific point. CCAMP or even IETF at large is not an authority to decide upon IEEE technos. > Some of these features will very likely require or enable added > value from extensions to the functionality of GMPLS - for example, as > has already been suggested, the addition of functionality=20 > for creating the OAM associations.=20 indeed, and your colleague has already received a list of comments to be addressed before seeing any way forward w/ the proposed approach.=20 > Therefore this will likely not be the same as the > possible use suggested in RFC3945, which may (at least=20 > in theory) have been implemented somewhere.=20 the exact problem, i mentionned a couple of times. your own comment shows that one may use GMPLS differently but may i ask WHY ? and what's the implications ? > Therefore the suggestion in the draft seems to make sense.=20 why ? > I can't really see what important principle is being > defended by the insistence upon L2SC, which, as Don Fedyk stated, was > always somewhat underspecified. THE reason is that an interface SC or a related functionality has never resulted in a specific change in the base protocol building blocks. GMPLS is a generalized approach not a differentiated approach per interface. actually your last statement is not correct (L2SC is well specified in RFC 3945) AND by the way yours does not at all better specify it. > This is not something to be debated in the abstract. The work in ccamp > should allow sensible extension of functionality where it adds value, > and this needs to be discussed on a case by case basis. Therefore we > should make it a working group document and get on with it. -d. > regards Howard Green >=20 > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On > Behalf Of PAPADIMITRIOU Dimitri > Sent: 30 January 2008 10:15 > To: Loa Andersson > Cc: neil.2.harrison@bt.com; benjamin.niven-jenkins@bt.com; > lberger@labn.net; dwfedyk@nortel.com; dbrungard@att.com; > ccamp@ops.ietf.org > Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt >=20 > loa, >=20 >=20 > i think the main point as ccamp is whether or not we poll for a change > or a continuation inline with RFC3945 -- when the present=20 > doc. states:=20 >=20 > "It is expected that there will be no > case where an Eth-LSP will be signaled, or an Eth-LSP supporting > interface will be represented, using the L2SC switching > type/capability. A new switching type/capability is required to > avoid any potential current usage of the L2SC switching > type/capability in support of Ethernet. >=20 > [...] >=20 > "The L2SC Interface Switching Capabilities MUST > NOT be used to represent interfaces capable of supporting=20 > Eth-LSPs." >=20 > it raises three issues: >=20 > a) what was the previous L2SC def. per RFC 3945 meant for if=20 > not for use > also in GMPLS Ethernet context ? >=20 > b) why a "new one" ?=20 >=20 > this is not explained. >=20 > c) what is the "new one" implying in terms of GMPLS ? >=20 > for inst. in the intro "The intent of this document is to reuse and > align with as much of the GMPLS protocols as possible."=20 > leaves open the > issue of what as much as possible means. >=20 > and on the other "Additions are made only to accommodate features of > Ethernet that are not already supported by GMPLS." so, how shall i > interpreet the first sentence now ? inline with point a) and b) ? >=20 >=20 > the doc. in WG I-D status or not is not going to provide an answer to > these questions. sentences and statements in the doc. contradict each > other. >=20 > thanks, > -d. >=20 >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: Loa Andersson [mailto:loa@pi.se] > > Sent: Tuesday, January 29, 2008 2:04 PM > > To: PAPADIMITRIOU Dimitri > > Cc: neil.2.harrison@bt.com; benjamin.niven-jenkins@bt.com;=20 > > lberger@labn.net; dwfedyk@nortel.com; dbrungard@att.com;=20 > > ccamp@ops.ietf.org > > Subject: Re: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt > >=20 > > Dimitri, > >=20 > > it is possible that you have a point that needs to be=20 > discussed, but=20 > > is this really something that should stop us from adopting=20 > the doc as=20 > > a working group document. > >=20 > > /Loa > >=20 > > PAPADIMITRIOU Dimitri wrote: > > > neil, > > >=20 > > >> -----Original Message----- > > >> From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] > > >> Sent: Friday, January 25, 2008 2:27 PM > > >> To: PAPADIMITRIOU Dimitri; benjamin.niven-jenkins@bt.com;=20 > > >> lberger@labn.net > > >> Cc: dwfedyk@nortel.com; dbrungard@att.com; ccamp@ops.ietf.org > > >> Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt > > >> > > >> Dimitri....see if this helps...in-line > > >> > > >>> -----Original Message----- > > >>> From: owner-ccamp@ops.ietf.org > > >>> [mailto:owner-ccamp@ops.ietf.org] On Behalf Of > > PAPADIMITRIOU Dimitri > > >>> Sent: 25 January 2008 11:36 > > >>> To: Niven-jenkins,B,Ben,DMF R; Lou Berger > > >>> Cc: Don Fedyk; BRUNGARD, DEBORAH A, ATTLABS; ccamp@ops.ietf.org > > >>> Subject: RE: Proposed WG Draft -=20 > draft-gmpls-ethernet-arch-00.txt > > >>> > > >>> > > >>> ben > > >>> > > >>>> -----Original Message----- > > >>>> From: Ben Niven-Jenkins [mailto:benjamin.niven-jenkins@bt.com] > > >>>> Sent: Thursday, January 24, 2008 3:40 PM > > >>>> To: PAPADIMITRIOU Dimitri; Lou Berger > > >>>> Cc: Don Fedyk; BRUNGARD, DEBORAH A, ATTLABS; ccamp@ops.ietf.org > > >>>> Subject: Re: Proposed WG Draft -=20 > draft-gmpls-ethernet-arch-00.txt > > >>>> > > >>>> Dimitri, > > >>>> > > >>>> I find your mail somewhat puzzling. > > >>>> > > >>>> You appear to be saying that GMPLS as per RFC 3945 is set > > >>> in stone and > > >>>> nothing should modify/enhance the behaviour as specified > > >> in RFC3945 > > >>>> which implies that when RFC3945 was produced the crystal > > ball was > > >>>> working extremely well and all possible future > > applications of the > > >>>> technology had > > >>>> been correctly envisaged. I don't believe that was the case. > > >>> this is not what i say. i am concerned in stating=20 > beforehand RFC=20 > > >>> 3945 (GMPLS Arch.) is not applicable to Ethernet. Why the doc.=20 > > >>> does not deliver any tangible explanation. > > >> NH=3D> Is your problem that you cannot differentiate between the = 3=20 > > >> network modes (of co-cs, co-ps and cl-ps)? > > >=20 > > > my concern wrt specific point you bring is that the today > > definition in > > > RFC 3945 for L2SC, and in the present case GMPLS for=20 > Ethernet (with=20 > > > local labels or domain-wide labels or any other equivalent > > to "co-ps") > > > does not result into a different definition than what's in.=20 > > on the other > > > side, i do not see how would apply GMPLS for=20 > connectionless/bridged=20 > > > Ethernet. > > >=20 > > > note also that GMPLS induces label from the interface and link=20 > > > characteristic (i.e. there is no "label type" in the > > label/label request > > > object. > > >=20 > > >> If so then looking at the work on > > >> unified modelling in SG15/Q12 may help you. But to give a more=20 > > >> specific example here: We can take an Ethernet traffic unit and=20 > > >> create either a cl-ps and co-ps layer network based on this...in=20 > > >> fact one > > can image 3 > > >> different layer network cases here: > > >> - traditional Etherent which does not have a=20 > directed routing > > >> function, ie uses MAC learning, broadcast unknown,=20 > STP...this is a=20 > > >> cl-ps layer network > > >> - Ethernet with an IGP providing a directed routing > > >> function....this is also a cl-ps layer network, but it is > > different to > > >> the one above > > >> - Ethernet with a directed routing component=20 > (centralised or > > >> distributed, ie IGP) and a signalling component that can create=20 > > >> connections....this would be a co-ps layer network. > > >> > > >> These are all based on a similar traffic unit, however=20 > they form 3=20 > > >> quite different layer networks (and in functional architecture=20 > > >> terms we would say 'the Characteristic Information is=20 > different in=20 > > >> the 3 cases'). > > >> > > >> Now GMPLS is applying a reusable set of CP components > > (which is a very > > >> good thing, as Ben points out below) for any co-cs or > > co-ps mode layer > > >> network. So we are setting up *connections* in either a space,=20 > > >> freq or time dimension of resource, and it is these 3 resource > > dimensions that > > >> create the differences in parameters...however, the notion of a=20 > > >> connection is common across all these resource dimensions. > > GMPLS does > > >> not apply to the cl-ps mode, as it plainly does not have > > connections. > > >=20 > > > well indeed, and this is the reason why i do not see any=20 > reason to=20 > > > open the space for a different set of mechanisms that=20 > would result=20 > > > from this new interface switching definition. > > >=20 > > > thanks, > > > -d. > > > =20 > > >> That is at least how I look at this issue. > > >> > > >> regards, Neil > > >>>>> the question triggered by this poll is the following: if > > >>> GMPLS for > > >>>>> Ethernet is not inline with the existing stacks what is > > >>> the value of > > >>>>> GMPLS re-use ? what's the value to borrow the term GMPLS > > >>> without its > > >>>>> substance ? and in practice, the issue is, if it is not > > >>>> GMPLS per RFC > > >>>>> 3945, what's the value compared to any other native control > > >>>> stack that > > >>>>> would be developed at IEEE for inst. for these techno's. > > >>>> If we ignore the peer model (which is unworkable in=20 > reality IMO), >=20 > > >>>> the value is obvious - significant reuse of existing code,=20 > > >>>> techniques, knowledge, skills, etc. > > >>>> > > >>>> So, we should develop the control plane from scratch > > >>> because Ethernet > > >>>> requires a few modifications/enhancements (which I believe are=20 > > >>>> backwards > > >>>> compatible) to RFC3945 - that IMO is ridiculous. > > >>> so you seem to agree with me. departing from RFC 3945=20 > makes little >=20 > > >>> sense. it would have been interesting to see the doc=20 > delivering a=20 > > >>> FIT of the GMPLS protocol arch. blocks and, in=20 > particular, label=20 > > >>> allocation and distribution for Ethernet. > > >>> > > >>> thanks, > > >>> -dimitri. > > >>>> Ben > > >>>> > > >>>> > > >>> > > >=20 > > >=20 > > >=20 > >=20 > >=20 > > -- > > Loa Andersson > >=20 > > Principal Networking Architect > > Acreo AB phone: +46 8 632 77 14 > > Isafjordsgatan 22 mobile: +46 739 81 21 64 > > Kista, Sweden email: loa.andersson@acreo.se > > loa@pi.se > >=20 >=20 >=20 From owner-ccamp@ops.ietf.org Wed Jan 30 13:10:11 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKHNz-00054k-KC for ccamp-archive@ietf.org; Wed, 30 Jan 2008 13:10:11 -0500 Received: from psg.com ([2001:418:1::62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JKHNy-0004Sn-4f for ccamp-archive@ietf.org; Wed, 30 Jan 2008 13:10:11 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JKHGL-000431-SF for ccamp-data@psg.com; Wed, 30 Jan 2008 18:02:17 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE, STOX_REPLY_TYPE autolearn=no version=3.2.3 Received: from [62.128.201.248] (helo=asmtp1.iomartmail.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JKHGJ-00042a-1t for ccamp@ops.ietf.org; Wed, 30 Jan 2008 18:02:16 +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 m0UI26c1002098; Wed, 30 Jan 2008 18:02:07 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 m0UI1vnq001943; Wed, 30 Jan 2008 18:02:06 GMT Message-ID: <0ea901c8636a$3220c230$0200a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "Mach Chen" Subject: Getting off the fence about draft-chen-ccamp-isis-interas-te-extension Date: Wed, 30 Jan 2008 18:00: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.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Hi all, We have an imbalance. We accepted draft-ietf-ccamp-ospf-interas-te-extension long ago. The ISIS I-D got stuck making some changes for the ISIS WG and then because of the discussion around BGP-TE. the two items have been resolved: - The I-D was revised and updated to cover the ISIS issues - The BGP-TE I-D has been taken to the Softwires WG Mach, can you please resubmit the current version of the draft as draft-ietf-ccamp-isis-interas-te-extension-00.txt Many thanks, Adrian From millarddunnpa@flash.net Wed Jan 30 13:26:10 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKHdS-0004ru-D8 for ccamp-archive@ietf.org; Wed, 30 Jan 2008 13:26:10 -0500 Received: from [81.215.119.215] (helo=bluewin.ch) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JKHdR-0003rf-15 for ccamp-archive@ietf.org; Wed, 30 Jan 2008 13:26:10 -0500 Date: Wed, 30 Jan 2008 17:45:22 +0000 From: "Millard Dunn" MIME-Version: 1.0 To: ccamp-archive@ietf.org Subject: ----SALE----- Limited Off3r -Do you want Rolkex? 0puel Message-ID: <1201715122.5099@flash.net> Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 080130-0, 30.01.2008), Outbound message X-Antivirus-Status: Clean X-Spam-Score: 3.5 (+++) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Dear ccamp-archive@ietf.org http://assieko.com What is King Replica store? At King Replica, we specialize in the sales of brand-name quality, luxury replicas at some of the lowest prices possible. With our large selection of products, you can be sure to find that perfect gift for yourself or a loved one. Visit King Replica Shop! http://assieko.com Thanks Jennifer Moore ccamp-archive@ietf.org wrote: > ----SALE----- Limited Off3r -Do you want Rolex? or any other extra watch? 0uwnq82a93- out me now http://assieko.com/remove/ From owner-ccamp@ops.ietf.org Wed Jan 30 13:27:25 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKHef-00066O-MU for ccamp-archive@ietf.org; Wed, 30 Jan 2008 13:27:25 -0500 Received: from psg.com ([2001:418:1::62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JKHec-00064I-Lk for ccamp-archive@ietf.org; Wed, 30 Jan 2008 13:27:25 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JKHRq-0005LK-4Q for ccamp-data@psg.com; Wed, 30 Jan 2008 18:14:10 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [217.32.164.137] (helo=smtp1.smtp.bt.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JKHRj-0005Kk-KJ for ccamp@ops.ietf.org; Wed, 30 Jan 2008 18:14:05 +0000 Received: from E03MVB2-UKBR.domain1.systemhost.net ([193.113.197.108]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 Jan 2008 18:14:01 +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: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Date: Wed, 30 Jan 2008 18:13:34 -0000 Message-ID: <2ECAA42C79676B42AEBAC11229CA7D0C01D4269F@E03MVB2-UKBR.domain1.systemhost.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Thread-Index: Achid4JetInOIvLXS36xGBjOv4vCdwAOqlZgAB8MVpAADGxFgAACaWoQ From: To: , , Cc: , , , , X-OriginalArrivalTime: 30 Jan 2008 18:14:01.0116 (UTC) FILETIME=[E398EDC0:01C8636B] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -1.0 (-) X-Scan-Signature: 441f623df000f14368137198649cb083 I personally think you are making a mountain out of a molehill here Dimitri. And I thought I had explained why there are differences in the treatment of layer networks depending on their mode...I clearly did a bad job. Sure GMPLS is a generic OOB CP suite of protocols, but the details of the parameters used used to describe the layer network being considered will depend on: - for the co-cs mode whether we are dealing with resources which are either regular time-slices, freq or space - for the co-ps mode there is only irregular time-slices. And the labelling of such resource partitions is different in each case too...so just like it is impossible to have a common (ie single instance of) CP running 'IP to Optics' (or any functional component for that matter) it is impossible to have an identical set of parameters describing each mode....this is just the physics and the way it is. The co-ps mode has the richest scope for 'variation' in the DP labelling of traffic units (this is more than simply a destination proxy label BTW....this was a point I saw Adrian alluding to)....and one can even violate the rules of connections here and really screw-up any notion of deterministic resource management anyway. regards, Neil=20 > -----Original Message----- > From: PAPADIMITRIOU Dimitri=20 > [mailto:Dimitri.Papadimitriou@alcatel-lucent.be]=20 > Sent: 30 January 2008 17:23 > To: Howard Green; Loa Andersson > Cc: Harrison,N,Neil,DMF R; Niven-jenkins,B,Ben,DMF R;=20 > lberger@labn.net; dwfedyk@nortel.com; dbrungard@att.com;=20 > ccamp@ops.ietf.org > Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt >=20 >=20 > =20 >=20 > > -----Original Message----- > > From: Howard Green [mailto:howard.green@ericsson.com] > > Sent: Wednesday, January 30, 2008 12:09 PM > > To: PAPADIMITRIOU Dimitri; Loa Andersson > > Cc: neil.2.harrison@bt.com; benjamin.niven-jenkins@bt.com;=20 > > lberger@labn.net; dwfedyk@nortel.com; dbrungard@att.com;=20 > > ccamp@ops.ietf.org > > Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt > >=20 > > Hi > > Dimitri seems to me to be making a very abstract and=20 > legalistic point. >=20 > receive my total disagreement. an individual submission that=20 > asks to change an existing RFC requires discussion and=20 > particular attention (in part., when it is the protocol arch.=20 > document) - if this not possible then probably you have to=20 > write also a doc. asking for changing the IETF proces - and=20 > then you come back with your individual submission. > =20 > > The reason why this work is important is that the IEEE has > > been evolving > > Ethernet to give it carrier class features, in respect of=20 > scalability, > > OAM, and (with 802.1Qay) the possibility to use an external control > > plane.=20 >=20 > no one i think question this. and i don't think the poll is=20 > on this specific point. CCAMP or even IETF at large is not an=20 > authority to decide upon IEEE technos. >=20 > > Some of these features will very likely require or enable=20 > added value=20 > > from extensions to the functionality of GMPLS - for example, as has=20 > > already been suggested, the addition of functionality for creating=20 > > the OAM associations. >=20 > indeed, and your colleague has already received a list of=20 > comments to be addressed before seeing any way forward w/ the=20 > proposed approach.=20 >=20 > > Therefore this will likely not be the same as the > > possible use suggested in RFC3945, which may (at least > > in theory) have been implemented somewhere.=20 >=20 > the exact problem, i mentionned a couple of times. your own=20 > comment shows that one may use GMPLS differently but may i=20 > ask WHY ? and what's the implications ? >=20 > > Therefore the suggestion in the draft seems to make sense. >=20 > why ? >=20 > > I can't really see what important principle is being > > defended by the insistence upon L2SC, which, as Don Fedyk=20 > stated, was=20 > > always somewhat underspecified. >=20 > THE reason is that an interface SC or a related functionality=20 > has never resulted in a specific change in the base protocol=20 > building blocks. GMPLS is a generalized approach not a=20 > differentiated approach per interface. >=20 > actually your last statement is not correct (L2SC is well=20 > specified in RFC 3945) AND by the way yours does not at all=20 > better specify it. >=20 > > This is not something to be debated in the abstract. The=20 > work in ccamp=20 > > should allow sensible extension of functionality where it=20 > adds value,=20 > > and this needs to be discussed on a case by case basis.=20 > Therefore we=20 > > should make it a working group document and get on with it. >=20 > -d. > > regards Howard Green > >=20 > > -----Original Message----- > > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On=20 > > Behalf Of PAPADIMITRIOU Dimitri > > Sent: 30 January 2008 10:15 > > To: Loa Andersson > > Cc: neil.2.harrison@bt.com; benjamin.niven-jenkins@bt.com;=20 > > lberger@labn.net; dwfedyk@nortel.com; dbrungard@att.com;=20 > > ccamp@ops.ietf.org > > Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt > >=20 > > loa, > >=20 > >=20 > > i think the main point as ccamp is whether or not we poll=20 > for a change=20 > > or a continuation inline with RFC3945 -- when the present=20 > doc. states: > >=20 > > "It is expected that there will be no > > case where an Eth-LSP will be signaled, or an Eth-LSP supporting > > interface will be represented, using the L2SC switching > > type/capability. A new switching type/capability is required to > > avoid any potential current usage of the L2SC switching > > type/capability in support of Ethernet. > >=20 > > [...] > >=20 > > "The L2SC Interface Switching Capabilities MUST > > NOT be used to represent interfaces capable of supporting > > Eth-LSPs." > >=20 > > it raises three issues: > >=20 > > a) what was the previous L2SC def. per RFC 3945 meant for if > > not for use > > also in GMPLS Ethernet context ? > >=20 > > b) why a "new one" ? > >=20 > > this is not explained. > >=20 > > c) what is the "new one" implying in terms of GMPLS ? > >=20 > > for inst. in the intro "The intent of this document is to reuse and=20 > > align with as much of the GMPLS protocols as possible." leaves open=20 > > the issue of what as much as possible means. > >=20 > > and on the other "Additions are made only to accommodate=20 > features of=20 > > Ethernet that are not already supported by GMPLS." so, how shall i=20 > > interpreet the first sentence now ? inline with point a) and b) ? > >=20 > >=20 > > the doc. in WG I-D status or not is not going to provide an=20 > answer to=20 > > these questions. sentences and statements in the doc.=20 > contradict each=20 > > other. > >=20 > > thanks, > > -d. > >=20 > >=20 > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: Loa Andersson [mailto:loa@pi.se] > > > Sent: Tuesday, January 29, 2008 2:04 PM > > > To: PAPADIMITRIOU Dimitri > > > Cc: neil.2.harrison@bt.com; benjamin.niven-jenkins@bt.com; > > > lberger@labn.net; dwfedyk@nortel.com; dbrungard@att.com;=20 > > > ccamp@ops.ietf.org > > > Subject: Re: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt > > >=20 > > > Dimitri, > > >=20 > > > it is possible that you have a point that needs to be > > discussed, but > > > is this really something that should stop us from adopting > > the doc as > > > a working group document. > > >=20 > > > /Loa > > >=20 > > > PAPADIMITRIOU Dimitri wrote: > > > > neil, > > > >=20 > > > >> -----Original Message----- > > > >> From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] > > > >> Sent: Friday, January 25, 2008 2:27 PM > > > >> To: PAPADIMITRIOU Dimitri; benjamin.niven-jenkins@bt.com; > > > >> lberger@labn.net > > > >> Cc: dwfedyk@nortel.com; dbrungard@att.com; ccamp@ops.ietf.org > > > >> Subject: RE: Proposed WG Draft -=20 > draft-gmpls-ethernet-arch-00.txt > > > >> > > > >> Dimitri....see if this helps...in-line > > > >> > > > >>> -----Original Message----- > > > >>> From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org]=20 > > > >>> On Behalf Of > > > PAPADIMITRIOU Dimitri > > > >>> Sent: 25 January 2008 11:36 > > > >>> To: Niven-jenkins,B,Ben,DMF R; Lou Berger > > > >>> Cc: Don Fedyk; BRUNGARD, DEBORAH A, ATTLABS;=20 > ccamp@ops.ietf.org > > > >>> Subject: RE: Proposed WG Draft - > > draft-gmpls-ethernet-arch-00.txt > > > >>> > > > >>> > > > >>> ben > > > >>> > > > >>>> -----Original Message----- > > > >>>> From: Ben Niven-Jenkins=20 > [mailto:benjamin.niven-jenkins@bt.com] > > > >>>> Sent: Thursday, January 24, 2008 3:40 PM > > > >>>> To: PAPADIMITRIOU Dimitri; Lou Berger > > > >>>> Cc: Don Fedyk; BRUNGARD, DEBORAH A, ATTLABS;=20 > ccamp@ops.ietf.org > > > >>>> Subject: Re: Proposed WG Draft - > > draft-gmpls-ethernet-arch-00.txt > > > >>>> > > > >>>> Dimitri, > > > >>>> > > > >>>> I find your mail somewhat puzzling. > > > >>>> > > > >>>> You appear to be saying that GMPLS as per RFC 3945 is set > > > >>> in stone and > > > >>>> nothing should modify/enhance the behaviour as specified > > > >> in RFC3945 > > > >>>> which implies that when RFC3945 was produced the crystal > > > ball was > > > >>>> working extremely well and all possible future > > > applications of the > > > >>>> technology had > > > >>>> been correctly envisaged. I don't believe that was the case. > > > >>> this is not what i say. i am concerned in stating > > beforehand RFC > > > >>> 3945 (GMPLS Arch.) is not applicable to Ethernet. Why the doc. > > > >>> does not deliver any tangible explanation. > > > >> NH=3D> Is your problem that you cannot differentiate=20 > between the 3 > > > >> network modes (of co-cs, co-ps and cl-ps)? > > > >=20 > > > > my concern wrt specific point you bring is that the today > > > definition in > > > > RFC 3945 for L2SC, and in the present case GMPLS for > > Ethernet (with > > > > local labels or domain-wide labels or any other equivalent > > > to "co-ps") > > > > does not result into a different definition than what's in. > > > on the other > > > > side, i do not see how would apply GMPLS for > > connectionless/bridged > > > > Ethernet. > > > >=20 > > > > note also that GMPLS induces label from the interface and link > > > > characteristic (i.e. there is no "label type" in the > > > label/label request > > > > object. > > > >=20 > > > >> If so then looking at the work on > > > >> unified modelling in SG15/Q12 may help you. But to give a more > > > >> specific example here: We can take an Ethernet=20 > traffic unit and=20 > > > >> create either a cl-ps and co-ps layer network based on=20 > this...in=20 > > > >> fact one > > > can image 3 > > > >> different layer network cases here: > > > >> - traditional Etherent which does not have a=20 > > directed routing > > > >> function, ie uses MAC learning, broadcast unknown, > > STP...this is a > > > >> cl-ps layer network > > > >> - Ethernet with an IGP providing a directed routing > > > >> function....this is also a cl-ps layer network, but it is > > > different to > > > >> the one above > > > >> - Ethernet with a directed routing component=20 > > (centralised or > > > >> distributed, ie IGP) and a signalling component that can create > > > >> connections....this would be a co-ps layer network. > > > >> > > > >> These are all based on a similar traffic unit, however > > they form 3 > > > >> quite different layer networks (and in functional architecture > > > >> terms we would say 'the Characteristic Information is=20 > > different in > > > >> the 3 cases'). > > > >> > > > >> Now GMPLS is applying a reusable set of CP components > > > (which is a very > > > >> good thing, as Ben points out below) for any co-cs or > > > co-ps mode layer > > > >> network. So we are setting up *connections* in either a space, > > > >> freq or time dimension of resource, and it is these 3 resource > > > dimensions that > > > >> create the differences in parameters...however, the notion of a > > > >> connection is common across all these resource dimensions. > > > GMPLS does > > > >> not apply to the cl-ps mode, as it plainly does not have > > > connections. > > > >=20 > > > > well indeed, and this is the reason why i do not see any > > reason to > > > > open the space for a different set of mechanisms that > > would result > > > > from this new interface switching definition. > > > >=20 > > > > thanks, > > > > -d. > > > > =20 > > > >> That is at least how I look at this issue. > > > >> > > > >> regards, Neil > > > >>>>> the question triggered by this poll is the following: if > > > >>> GMPLS for > > > >>>>> Ethernet is not inline with the existing stacks what is > > > >>> the value of > > > >>>>> GMPLS re-use ? what's the value to borrow the term GMPLS > > > >>> without its > > > >>>>> substance ? and in practice, the issue is, if it is not > > > >>>> GMPLS per RFC > > > >>>>> 3945, what's the value compared to any other native control > > > >>>> stack that > > > >>>>> would be developed at IEEE for inst. for these techno's. > > > >>>> If we ignore the peer model (which is unworkable in > > reality IMO), > >=20 > > > >>>> the value is obvious - significant reuse of existing code, > > > >>>> techniques, knowledge, skills, etc. > > > >>>> > > > >>>> So, we should develop the control plane from scratch > > > >>> because Ethernet > > > >>>> requires a few modifications/enhancements (which I=20 > believe are > > > >>>> backwards > > > >>>> compatible) to RFC3945 - that IMO is ridiculous. > > > >>> so you seem to agree with me. departing from RFC 3945 > > makes little > >=20 > > > >>> sense. it would have been interesting to see the doc > > delivering a > > > >>> FIT of the GMPLS protocol arch. blocks and, in > > particular, label > > > >>> allocation and distribution for Ethernet. > > > >>> > > > >>> thanks, > > > >>> -dimitri. > > > >>>> Ben > > > >>>> > > > >>>> > > > >>> > > > >=20 > > > >=20 > > > >=20 > > >=20 > > >=20 > > > -- > > > Loa Andersson > > >=20 > > > Principal Networking Architect > > > Acreo AB phone: +46 8 632 77 14 > > > Isafjordsgatan 22 mobile: +46 739 81 21 64 > > > Kista, Sweden email: loa.andersson@acreo.se > > > loa@pi.se > > >=20 > >=20 > >=20 >=20 From owner-ccamp@ops.ietf.org Wed Jan 30 13:43:34 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKHuI-0001ii-UO for ccamp-archive@ietf.org; Wed, 30 Jan 2008 13:43:34 -0500 Received: from psg.com ([2001:418:1::62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JKHuG-0006UT-W0 for ccamp-archive@ietf.org; Wed, 30 Jan 2008 13:43:34 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JKHjp-0007LC-MC for ccamp-data@psg.com; Wed, 30 Jan 2008 18:32:45 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [64.208.49.5] (helo=smail6.alcatel.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JKHjm-0007KO-CI for ccamp@ops.ietf.org; Wed, 30 Jan 2008 18:32:44 +0000 Received: from FRVELSBHS02.ad2.ad.alcatel.com (frvelsbhs02.ad2.ad.alcatel.com [155.132.6.74]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id m0UIWObL017405; Wed, 30 Jan 2008 19:32:24 +0100 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.51]) by FRVELSBHS02.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Wed, 30 Jan 2008 19:32:36 +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: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Date: Wed, 30 Jan 2008 19:32:32 +0100 Message-ID: In-Reply-To: <0df801c86354$a266fc00$0200a8c0@your029b8cecfe> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Thread-Index: AchjVQ4iCRP3GvaQReiaKOLk76rorgAGLI+A References: <2ECAA42C79676B42AEBAC11229CA7D0C01C98951@E03MVB2-UKBR.domain1.systemhost.net> <479F2458.6090201@pi.se> <56D2F550769FAA4CA70D5B2EB8419F1402A3A51E@esealmw118.eemea.ericsson.se> <0df801c86354$a266fc00$0200a8c0@your029b8cecfe> From: "PAPADIMITRIOU Dimitri" To: "Adrian Farrel" , X-OriginalArrivalTime: 30 Jan 2008 18:32:36.0567 (UTC) FILETIME=[7C753E70:01C8636E] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a adrian=20 > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel > Sent: Wednesday, January 30, 2008 4:28 PM > To: ccamp@ops.ietf.org > Subject: Re: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt >=20 > All, >=20 > We appear to be seeing good support for this document, and=20 > that suggests=20 > that we should take it forward, but I would like to at least=20 > make an attempt=20 > to close down the point raised by Dimitri. As Howard points=20 > out, this is in=20 > danger of becoming a legalistic discussion, but I've never=20 > been one to=20 > refuse the opportunity to back to first principles... >=20 > In RFC 3945 we have... >=20 > A link may support a set of encoding formats, where support means > that a link is able to carry and switch a signal of one or more of > these encoding formats. The Switching Type indicates then the type > of switching that should be performed on a particular link for that > LSP. This information is needed for links that advertise more than > one type of switching capability. >=20 > Nodes must verify that the type indicated in the Switching Type is > supported on the corresponding incoming interface; otherwise, the > node must generate a notification message with a "Routing > problem/Switching Type" indication. >=20 > Now, the question is whether we are introducing one (or more)=20 > new Switching=20 > Type and whether we need to be able to distinguish between=20 > them. Suppose=20 > (for the sake of argument) that we will over time introduce=20 > the ability to=20 > switch Ethernet frames under GMPLS control based on several=20 > different label=20 > concepts: > - 802.1Qay > - destination MAC only > - destination MAC and VLAN tag > It is likely that a GMPLS-capable Ethernet switch will want=20 > to support more=20 > than one of these switching paradigms on any single=20 > interface. So we have to=20 > decide how, during signaling, we indicate which type of LSP=20 > is requested. >=20 > There are plenty of ways that this could be done. Currently we use a=20 > combination of the parameters of the=20 > Generalized_Label_Request object and=20 > the Sender_TSpec object. The TSpec is used in the case of TDM=20 > (RFC 4606) and=20 > Ethernet to distinguish the Switching Granularity=20 > (draft-ietf-ccamp-ethernet-traffic-parameters). >=20 > As I see it, the text at issue in=20 > draft-gmpls-ethernet-arch-00.txt causes a=20 > problem because it appears to say that *no* Ethernet Label=20 > Switched Path=20 > (Eth-LSP) can be set up using an L2SC Switching Type. > It is expected that there will be no > case where an Eth-LSP will be signaled, or an Eth-LSP supporting > interface will be represented, using the L2SC switching > type/capability. >=20 > However, the draft also says... > A new switching type/capability is required to > avoid any potential current usage of the L2SC switching > type/capability in support of Ethernet. >=20 > And this clearly says that L2SC *is* allowed. >=20 > Can we fix this by agreeing some new wording? >=20 > =3D=3D > OLD > This document does not define any specific format for an Eth-LSP > label. Rather, it is expected that service specific documents will > define any signaling and routing extensions needed to support that > specific Ethernet service. Depending on the requirements of a > service, it may be necessary to define multiple GMPLS extensions, > e.g., label formats, switching types, and Traffic Engineering (TE) > routing extensions. It is expected that all such=20 > extensions will be > consistent with this document. It is expected that there will be no > case where an Eth-LSP will be signaled, or an Eth-LSP supporting > interface will be represented, using the L2SC switching > type/capability. A new switching type/capability is required to > avoid any potential current usage of the L2SC switching > type/capability in support of Ethernet. > NEW > This document does not define any specific format for an Eth-LSP > label. Rather, it is expected that service specific documents will > define any signaling and routing extensions needed to support that > specific Ethernet service. Depending on the requirements of a > service, it may be necessary to define multiple GMPLS protocol > extensions and procedures. It is expected that all such extensions > will be consistent with this document. >=20 > It is expected that key a requirement will be to describe label > formats and encodings. It may also be necessary to provide a > mechanism to identify the required Ethernet service type=20 > in signaling > and a way to advertise the capabilities of Ethernet switches in the > routing protocols. These mechanisms must make it possible to > distinguish between requests for different paradigms including new, > future, and existing paradigms. >=20 > The Switching Type and Interface Switching Capability Descriptor > share a common set of values and are defined in [RFC3945],=20 > [RFC3471], > and [RFC4202] as indicators of the type of switching that should > ([RFC3471]) and can ([RFC4202]) be performed on a=20 > particular link for > an LSP. The L2SC switching type is available for use by > implementations performing layer 2 switching including ATM and > Ethernet. To support the continued use of that switching type by > existing implementations as well as to distinguish between each new > Ethernet switching paradigm, a new switching type is expected to be > needed for each new Ethernet switching paradigm that is supported. i can live with this at the condition that a statement is added about either we do ack assessment on further implications or do not imply any change on other GMPLS building blocks (note: there is a main difference between change and extensions). thanks, -d.=20 > =3D=3D >=20 > Thanks, > Adrian=20 >=20 >=20 >=20 >=20 From owner-ccamp@ops.ietf.org Wed Jan 30 13:46:55 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKHxX-00064l-4s for ccamp-archive@ietf.org; Wed, 30 Jan 2008 13:46:55 -0500 Received: from psg.com ([2001:418:1::62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JKHxU-0006a4-SA for ccamp-archive@ietf.org; Wed, 30 Jan 2008 13:46:55 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JKHqG-0008I3-Pg for ccamp-data@psg.com; Wed, 30 Jan 2008 18:39:24 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE, STOX_REPLY_TYPE autolearn=no version=3.2.3 Received: from [62.128.201.249] (helo=asmtp2.iomartmail.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JKHqD-0008HQ-FG for ccamp@ops.ietf.org; Wed, 30 Jan 2008 18:39:23 +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 m0UIdGSR006341; Wed, 30 Jan 2008 18:39:17 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 m0UId9HV006280; Wed, 30 Jan 2008 18:39:16 GMT Message-ID: <0edc01c8636f$65f4c980$0200a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "PAPADIMITRIOU Dimitri" , References: <2ECAA42C79676B42AEBAC11229CA7D0C01C98951@E03MVB2-UKBR.domain1.systemhost.net> <479F2458.6090201@pi.se> <56D2F550769FAA4CA70D5B2EB8419F1402A3A51E@esealmw118.eemea.ericsson.se> <0df801c86354$a266fc00$0200a8c0@your029b8cecfe> Subject: Re: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Date: Wed, 30 Jan 2008 18:39:02 -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.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Dimitri, Thanks. Editors, Please submit your I-D as draft-ietf-ccamp-gmpls-ethernet-arch-00.txt making the changes described below. Thanks, Adrian ----- Original Message ----- From: "PAPADIMITRIOU Dimitri" To: "Adrian Farrel" ; Sent: Wednesday, January 30, 2008 6:32 PM Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt adrian > -----Original Message----- > From: owner-ccamp@ops.ietf.org > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel > Sent: Wednesday, January 30, 2008 4:28 PM > To: ccamp@ops.ietf.org > Subject: Re: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt > > All, > > We appear to be seeing good support for this document, and > that suggests > that we should take it forward, but I would like to at least > make an attempt > to close down the point raised by Dimitri. As Howard points > out, this is in > danger of becoming a legalistic discussion, but I've never > been one to > refuse the opportunity to back to first principles... > > In RFC 3945 we have... > > A link may support a set of encoding formats, where support means > that a link is able to carry and switch a signal of one or more of > these encoding formats. The Switching Type indicates then the type > of switching that should be performed on a particular link for that > LSP. This information is needed for links that advertise more than > one type of switching capability. > > Nodes must verify that the type indicated in the Switching Type is > supported on the corresponding incoming interface; otherwise, the > node must generate a notification message with a "Routing > problem/Switching Type" indication. > > Now, the question is whether we are introducing one (or more) > new Switching > Type and whether we need to be able to distinguish between > them. Suppose > (for the sake of argument) that we will over time introduce > the ability to > switch Ethernet frames under GMPLS control based on several > different label > concepts: > - 802.1Qay > - destination MAC only > - destination MAC and VLAN tag > It is likely that a GMPLS-capable Ethernet switch will want > to support more > than one of these switching paradigms on any single > interface. So we have to > decide how, during signaling, we indicate which type of LSP > is requested. > > There are plenty of ways that this could be done. Currently we use a > combination of the parameters of the > Generalized_Label_Request object and > the Sender_TSpec object. The TSpec is used in the case of TDM > (RFC 4606) and > Ethernet to distinguish the Switching Granularity > (draft-ietf-ccamp-ethernet-traffic-parameters). > > As I see it, the text at issue in > draft-gmpls-ethernet-arch-00.txt causes a > problem because it appears to say that *no* Ethernet Label > Switched Path > (Eth-LSP) can be set up using an L2SC Switching Type. > It is expected that there will be no > case where an Eth-LSP will be signaled, or an Eth-LSP supporting > interface will be represented, using the L2SC switching > type/capability. > > However, the draft also says... > A new switching type/capability is required to > avoid any potential current usage of the L2SC switching > type/capability in support of Ethernet. > > And this clearly says that L2SC *is* allowed. > > Can we fix this by agreeing some new wording? > > == > OLD > This document does not define any specific format for an Eth-LSP > label. Rather, it is expected that service specific documents will > define any signaling and routing extensions needed to support that > specific Ethernet service. Depending on the requirements of a > service, it may be necessary to define multiple GMPLS extensions, > e.g., label formats, switching types, and Traffic Engineering (TE) > routing extensions. It is expected that all such > extensions will be > consistent with this document. It is expected that there will be no > case where an Eth-LSP will be signaled, or an Eth-LSP supporting > interface will be represented, using the L2SC switching > type/capability. A new switching type/capability is required to > avoid any potential current usage of the L2SC switching > type/capability in support of Ethernet. > NEW > This document does not define any specific format for an Eth-LSP > label. Rather, it is expected that service specific documents will > define any signaling and routing extensions needed to support that > specific Ethernet service. Depending on the requirements of a > service, it may be necessary to define multiple GMPLS protocol > extensions and procedures. It is expected that all such extensions > will be consistent with this document. > > It is expected that key a requirement will be to describe label > formats and encodings. It may also be necessary to provide a > mechanism to identify the required Ethernet service type > in signaling > and a way to advertise the capabilities of Ethernet switches in the > routing protocols. These mechanisms must make it possible to > distinguish between requests for different paradigms including new, > future, and existing paradigms. > > The Switching Type and Interface Switching Capability Descriptor > share a common set of values and are defined in [RFC3945], > [RFC3471], > and [RFC4202] as indicators of the type of switching that should > ([RFC3471]) and can ([RFC4202]) be performed on a > particular link for > an LSP. The L2SC switching type is available for use by > implementations performing layer 2 switching including ATM and > Ethernet. To support the continued use of that switching type by > existing implementations as well as to distinguish between each new > Ethernet switching paradigm, a new switching type is expected to be > needed for each new Ethernet switching paradigm that is supported. i can live with this at the condition that a statement is added about either we do ack assessment on further implications or do not imply any change on other GMPLS building blocks (note: there is a main difference between change and extensions). thanks, -d. > == > > Thanks, > Adrian > > > > From nedgo1951@aiki.ccaps.cs.cmu.edu Wed Jan 30 16:37:07 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKKcE-0003Vp-JN for ccamp-archive@ietf.org; Wed, 30 Jan 2008 16:37:07 -0500 Received: from [88.239.143.66] (helo=dsl.dynamic81215126115.ttnet.net.tr) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JKKcB-0002e1-8N for ccamp-archive@ietf.org; Wed, 30 Jan 2008 16:37:06 -0500 Message-ID: <000e01c86388$4102be20$737ed751@baracuda007> From: "Atlas Holstein" To: ccamp-archive@ietf.org Subject: Produce erect1ons that are hard and long lasting, and not to mention the incredible gains in length Date: Wed, 30 Jan 2008 23:37:03 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--------=_NextPart_000_000A_01C86399.048B8E20" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 4.5 (++++) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 ----------=_NextPart_000_000A_01C86399.048B8E20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Produce erect1ons that are hard and long lasting, and not to mention the = incredible gains in length ----------=_NextPart_000_000A_01C86399.048B8E20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Produce erect1ons that are hard and = long=20 lasting, and not to mention the incredible gains in = length ----------=_NextPart_000_000A_01C86399.048B8E20-- From owner-ccamp@ops.ietf.org Wed Jan 30 16:58:19 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKKwl-0002wo-2s for ccamp-archive@ietf.org; Wed, 30 Jan 2008 16:58:19 -0500 Received: from psg.com ([2001:418:1::62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JKKwj-0003aX-4i for ccamp-archive@ietf.org; Wed, 30 Jan 2008 16:58:19 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JKKmM-0007Ls-LS for ccamp-data@psg.com; Wed, 30 Jan 2008 21:47:34 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,MISSING_MID, RDNS_NONE autolearn=no version=3.2.3 Received: from [216.104.42.195] (helo=esc91.midphase.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JKKmJ-0007LR-Hn for ccamp@ops.ietf.org; Wed, 30 Jan 2008 21:47:33 +0000 Received: from esc91.midphase.com ([216.104.33.66] helo=LC2.labn.net) by esc91.midphase.com with esmtpa (Exim 4.68) (envelope-from ) id 1JKKmG-000166-Pb; Wed, 30 Jan 2008 16:47:28 -0500 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 30 Jan 2008 16:47:29 -0500 To: "Adrian Farrel" From: Lou Berger Subject: Re: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Cc: In-Reply-To: <0df801c86354$a266fc00$0200a8c0@your029b8cecfe> References: <2ECAA42C79676B42AEBAC11229CA7D0C01C98951@E03MVB2-UKBR.domain1.systemhost.net> <479F2458.6090201@pi.se> <56D2F550769FAA4CA70D5B2EB8419F1402A3A51E@esealmw118.eemea.ericsson.se> <0df801c86354$a266fc00$0200a8c0@your029b8cecfe> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - esc91.midphase.com X-AntiAbuse: Original Domain - ops.ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-Source: X-Source-Args: X-Source-Dir: Sender: owner-ccamp@ops.ietf.org Precedence: bulk Message-Id: X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Adrian, This seems workable to me. Also, I don't think it was the intent of the draft to preclude use of L2SC for current applications, but rather to use new values for the new types of ether switching. I think your text disambiguates this issue. Lou At 10:27 AM 1/30/2008, Adrian Farrel wrote: >All, > >We appear to be seeing good support for this document, and that >suggests that we should take it forward, but I would like to at >least make an attempt to close down the point raised by Dimitri. As >Howard points out, this is in danger of becoming a legalistic >discussion, but I've never been one to refuse the opportunity to >back to first principles... > >In RFC 3945 we have... > > A link may support a set of encoding formats, where support means > that a link is able to carry and switch a signal of one or more of > these encoding formats. The Switching Type indicates then the type > of switching that should be performed on a particular link for that > LSP. This information is needed for links that advertise more than > one type of switching capability. > > Nodes must verify that the type indicated in the Switching Type is > supported on the corresponding incoming interface; otherwise, the > node must generate a notification message with a "Routing > problem/Switching Type" indication. > >Now, the question is whether we are introducing one (or more) new >Switching Type and whether we need to be able to distinguish between >them. Suppose (for the sake of argument) that we will over time >introduce the ability to switch Ethernet frames under GMPLS control >based on several different label concepts: >- 802.1Qay >- destination MAC only >- destination MAC and VLAN tag >It is likely that a GMPLS-capable Ethernet switch will want to >support more than one of these switching paradigms on any single >interface. So we have to decide how, during signaling, we indicate >which type of LSP is requested. > >There are plenty of ways that this could be done. Currently we use a >combination of the parameters of the Generalized_Label_Request >object and the Sender_TSpec object. The TSpec is used in the case of >TDM (RFC 4606) and Ethernet to distinguish the Switching Granularity >(draft-ietf-ccamp-ethernet-traffic-parameters). > >As I see it, the text at issue in draft-gmpls-ethernet-arch-00.txt >causes a problem because it appears to say that *no* Ethernet Label >Switched Path (Eth-LSP) can be set up using an L2SC Switching Type. > It is expected that there will be no > case where an Eth-LSP will be signaled, or an Eth-LSP supporting > interface will be represented, using the L2SC switching > type/capability. > >However, the draft also says... > A new switching type/capability is required to > avoid any potential current usage of the L2SC switching > type/capability in support of Ethernet. > >And this clearly says that L2SC *is* allowed. > >Can we fix this by agreeing some new wording? > >== >OLD > This document does not define any specific format for an Eth-LSP > label. Rather, it is expected that service specific documents will > define any signaling and routing extensions needed to support that > specific Ethernet service. Depending on the requirements of a > service, it may be necessary to define multiple GMPLS extensions, > e.g., label formats, switching types, and Traffic Engineering (TE) > routing extensions. It is expected that all such extensions will be > consistent with this document. It is expected that there will be no > case where an Eth-LSP will be signaled, or an Eth-LSP supporting > interface will be represented, using the L2SC switching > type/capability. A new switching type/capability is required to > avoid any potential current usage of the L2SC switching > type/capability in support of Ethernet. >NEW > This document does not define any specific format for an Eth-LSP > label. Rather, it is expected that service specific documents will > define any signaling and routing extensions needed to support that > specific Ethernet service. Depending on the requirements of a > service, it may be necessary to define multiple GMPLS protocol > extensions and procedures. It is expected that all such extensions > will be consistent with this document. > > It is expected that key a requirement will be to describe label > formats and encodings. It may also be necessary to provide a > mechanism to identify the required Ethernet service type in signaling > and a way to advertise the capabilities of Ethernet switches in the > routing protocols. These mechanisms must make it possible to > distinguish between requests for different paradigms including new, > future, and existing paradigms. > > The Switching Type and Interface Switching Capability Descriptor > share a common set of values and are defined in [RFC3945], [RFC3471], > and [RFC4202] as indicators of the type of switching that should > ([RFC3471]) and can ([RFC4202]) be performed on a particular link for > an LSP. The L2SC switching type is available for use by > implementations performing layer 2 switching including ATM and > Ethernet. To support the continued use of that switching type by > existing implementations as well as to distinguish between each new > Ethernet switching paradigm, a new switching type is expected to be > needed for each new Ethernet switching paradigm that is supported. >== > >Thanks, >Adrian > > > From lohmandesigns.com@zgas.net Wed Jan 30 17:11:57 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKL9x-0001p4-Az for ccamp-archive@ietf.org; Wed, 30 Jan 2008 17:11:57 -0500 Received: from [59.7.226.114] (helo=ydyejp) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JKL9w-0003XH-7B for ccamp-archive@ietf.org; Wed, 30 Jan 2008 17:11:57 -0500 Message-ID: <000701c8638c$fb22eb00$0100007f@ugtahfk> From: "Nicholas Hall" To: Subject: Why be an average guy any longer Date: Thu, 31 Jan 2008 07:11:41 +0900 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0023_01C8638C.FB22EB00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2905 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 2.8 (++) X-Scan-Signature: fec852dbea6d068499ed3250edf328e2 This is a multi-part message in MIME format. ------=_NextPart_000_0023_01C8638C.FB22EB00 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0034_01C8638C.FB22EB00" ------=_NextPart_001_0034_01C8638C.FB22EB00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Info attached or here: http://www.edasora.net/ ----- He will not be so easily led, Have you seen your grandson? s Aye, he was brought to me, her Elizabeth could not imagine he ------=_NextPart_001_0034_01C8638C.FB22EB00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello

------=_NextPart_001_0034_01C8638C.FB22EB00-- ------=_NextPart_000_0023_01C8638C.FB22EB00 Content-Type: image/jpg; name="img60.jpg" Content-Transfer-Encoding: base64 Content-ID: /9j/4AAQSkZJRgABAQEAZABkAAD/2wBDABsSFBcUERsXFhceHBsgKEIrKCUlKFE6PTBCYFVlZF9V XVtqeJmBanGQc1tdhbWGkJ6jq62rZ4C8ybqmx5moq6T/2wBDARweHigjKE4rK06kbl1upKSkpKSk pKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKT/wAARCAESAjkDASIA AhEBAxEB/8QAGgAAAwEBAQEAAAAAAAAAAAAAAAMEAgUBBv/EADsQAAICAQMCAwUGBQMEAwEAAAEC AAMRBBIhMUETIlEUYXGBsQUyM1KRoSM0ctHwFULBJJLh8SVDYoP/xAAZAQEAAwEBAAAAAAAAAAAA AAAAAQIDBAX/xAApEQACAgEEAQQCAwEBAQAAAAAAAQIRAxITITFRBDJBcVKRQmGBIjPw/9oADAMB AAIRAxEAPwC3Taep6FZlyTnufWN9ko/J+5ho/wCWT5/WOnVKTt8mEIRcVwJ9ko/J+5h7JR+T9zHQ kan5LbcPCE+yUfk/cw9ko/J+5joRqfkbcPCE+yUfk/cw9koz9z9zHTFztXWWVcnp8JWU2ldkrHBv o52p8JHO1dqj3ybx6ycKGJmtSpZsE954oCcAYnI8s77Z1LDjr2r9G0ZX4wQffG7F/LiLrIY4PWPx iQ8s/LLbOP8AFfoRYAvSLZiFLekosTcIgJlWQ9xJWWfllZYcf4r9DNDtufa/M6i6PTkH+Hz25M43 2dkakA/OfQgYYH1lllnq7Zk8UK9qJPZKPyfuYeyUfk/cx7cEzydWp+THbh4Qn2Sj8n7mHslH5P3M 0bD4hTac9vePWMjW/JO3HwJ9ko/J+5h7JR+T9zHQk6n5I24eEJ9ko/J+5h7JR+T9zHQjU/I24eEI bTUKpJTp7zOVfatZwoyZ19SCaGwces4zlQ4LECc+TJPVSZvjxY65SPU8VufKPjGpycMOfdJ/GDHg yiqwEYB5mTyT8s0WLF+K/RvYPSYsG0cCMByPf3gRuEjdn+TJ2cb6iv0IQlsjvE12sbQGPGeY8Da/ wiHXbqOOhMsss/LM5YYX7V+jsV6Wpqg2zn4mNXR0EH+H+5mtOP8Ap8GNq+7EMs/LKvFCvaiX2Sj8 n7me+yUfk/cx0J2an5MduHhCfZKPyfuYeyUfk/cx0I1PyNuHhCfZKPyfuYeyUfk/cx0I1PyNuHhC fZKPyfuYeyUfk/cx0D05kObS7J24eDnatKkYKi49eZP+881lrtdhf1i1qIPmfmcjyzvtnTHDjrmK /QwL+Xj3GMVQQCRgzNSnoTkRuJDyz6su8ON9xX6E2YXpF7jgx1qbhxFIMPjt3jcn5ZV4cf4r9Cku JsAJ47idVNPW1G4L5vXJnGZSlxz0zPoNIM0D4Q8k/LKbWP8AFfoWmmpO3Kd8Hkxj6OgMQK/3M3UM 8e/MZZ0z3muLJJumyk8UPCJ/ZKPyfuYeyUfk/cx0J0an5MtuHgT7JR+T9zD2Sj8n7mOhGp+Rtw8I T7JR+T9zD2Sj8n7mOhGp+Rtw8IT7JR+T9zI9UtaWBUXHznSJwDOPqblFhLNz2mOXJJcJmuPFBvlI 8mlAMSthbquBHpyMic+5P8mdGzj/ABX6Pdo9Ih2IPEoI4iLVIOYWWflkPDj/ABX6F2Oyjr1j9CRc wFnMRYm+lvXtN/ZhxeoMtuTrtmTxY79q/R0X01a2DyeU+8xtWkoJYMmfTkzd3VT2m6xggyI5Z32w 8WOvav0J9ko/J+5h7JR+T9zHkYM8nYpPyY7cPCJrdLStTsE5CkjkznzrX/gWf0n6TkzfG21ycfqI pNUjp6P+WT5/WOidH/LJ8/rHTGXbOvH7F9BCEJUuEIQgBE6ttlDc+ZuBGswQFm6Ccy+03NuP3ewm WSVKjXHDU7JdQ+zzHpJzrKycjMqtUOJONIN2eJzqjeSa6PabWfJHEvRsgRNdYUYxHKOZEmiyT+Rn aIJ228R/QSWzqWlUH0a0a/8AVbh6zuA5wROLojgFz6zs1coslPkxkeW8OTMNnHGM++Mt5YTE7l0Y CXTw9tgySD5j6gx0ISUqAQhCCAh2hE6m8UJxy7dBIk6RMVboVr7gq+GpyT1M4uqG7GRky12LEk9T 1iXUHtORyt2dahSohVHB8vMsoVxjcMe6aRAD0jgJDdkRjRteYzoItRGShouBFv3xEgb7l90bbySf SZ0o3WknoMSV0Zy7Ozp23VEDtG08CR6YkobE/T1EsqIIBBzmRDsxb+GZb7xnk3YOczE749GYQhCS QEIQgBPD0OemJ7Jtdd4dexT5m/aVm6RaKtnK1Vq1WE5zzErqA3Q8TV6E57xCack8cTlSR0O0X0XZ 4zH5BkdNRTr1lK9JVl0b7RLgLZ8Y8dIi/k/CQiX0T3eaxe+TzO7pOKtvunEq815+E7GjPJX3RIyH U8MfjGOPKfcZhRgZ98a3f3y+N1IpIVCEJ2GIQhCAEIQgGbMlDjricQoDcWbmdq5xXWzH0wJ89qLi jEhc5nPlSbNsfCH+IMyitlInKW8sQNpzLaWbvMmjWMrKc8wZdwni8xnGJQuS9ARDQD/qczyw4ZjN 6P8AN6GT8Gb7Ou+Gr65xN18oZKNOtqCxS1dhHLKevxHeN07Xq+ywIy/mHB+YhL5RRvmmNfrmeTbj yiYnZB3EyZi78Cz+k/Scmda/8Cz+k/ScmdWLpnB6rtHT0f8ALJ8/rHROj/lk+f1jplLtnVj9i+gh CEqXCEIQDF6eLUyA+acgMRY1Trgidi2xakLt26Tk3MbrTYepmGWjow2LHJMB1gABDEwOgYpjVMQp 5jVMgG2PBk74KGOY+UydzipvUQiGNoIXTfE/8zsadv4Y+E41f4FQx94zr0fdX4SHwzKSGPyAZibP 3BMTtxu4nOwhCEuVCEIQAkmvpd031jdt6jv8pXM2P4VbP0IGBKzVx5LRbUuDilga9wMOwnhUEk46 nM97TjO09B5m1MVmaU8wB4M9J6zCme9jKgWT96eafARm+P0njEAPCo40x94P6ySjOj9nn+AvwEsC hbcjgN1HvkekG2kD3CUlvMkqnyZyjY2z8P5xcZYRsI//AFFztxcxMZdhCEJoVCEIQDF1nhVFpyrH Z2LsckzrWoLKyjdDOTfW2ms2P5lI8pmGVM6MLXyYOCJ4oAniZ2jM1nmc5ubWMEUpmxAN5iX5JjDF OfPgQGZ04/itOhoGzvb3kSDTn77Sz7P/AAifXmQzM6BPkzGdcfCIZsUqffzGqeBJi+UZyXBiB6cH EITvMDKMSdrcMP3mpl03DrgjofSeru2jcAD7oB7PGO0T2LtUmuzHJK8SGPmiLWX+K20fdWRMgabJ H3GyG9JkHOc9RONtt8nZFKuDKVgHpHATM2pkWXqjazRPBnk8PQyoE2YIM9o8unPzMw56/ETWcaYY 7kSWUl2dXTt/DT4R+QLBJaeKl9xj2b+KnvXMqmUaHEZU+6LjB1Ye6LnZi9pjMxf+BZ/SfpOTOtf+ BZ/SfpOTOzF0zz/Vdo6ej/lk+f1jpNoLEfThQfMucjuOZTMpds6sfsQQhPGZVGWOJRuuWaU30e9Z lnVerRD3l/ucD1k4F9nIC1D1Pmb+05Z+pS9ptHC/5B9oM1uw1DIHWTK24Z6EdRLK6RXli7MT1LH/ AI6SXUspuXw+o6zCOV5JG8Y6UZwfTENvE9Gc8zeOJckWBzGCeY5mh0gk8c4UycNklfUTeofCxFGS +T2koqytebKlHYTqodu0e6cvSjxLy3ZZ0FfJ+UzkVKM5AEzCsw7zrwO0c+TsIQhNzMIQhACR/aVh Va0/2s3MrZgoyTJL/wDqBtI8omGbJGKpmuKLuyCBE3bQ1HJ5XtAYI45nPFpq0dQo9J4pjHT0iSCp kgoUzTNgGLQ8Ty18LIoWLLZJHrGH7qp6mTVZazPpK6Rv1C8eVfrD6KnRTy0j1jc+ZJOzjLKDwOD7 4ytsuoPYTMhopPIb4zM0OVaZnbhdxOafYQhCbFAhCEAByfnOXrm8TUE5zt4E6nXOPScVtyWsrjBz 1mOV0bYlbM9J4es0RMkTnOg9UxqmIU8xqmQyTeesnd/4kcxwDI7G/icde0IhlFfkoYnvky/RgLpj kdhICMhV9SBOgCFrC+vX4SrIHMc04/8A0I9DwnxkYfNRHfcJUpxtA7SE6KSXBo9TPJ633jPJ6K6O ZhCEJJAQhPCQOWOBDCIvtNVNanADdjOeg25z3ln2hYGsUdRtyD85Kf8AxOWdNnXjVIMzSnmYno4M zNBwMCeDMKZ65wpkAndslh3zGMPIiDuRJwd14xKkG69BjOOYfRT5Oj0rUTbHz1H3ERLMM4z93GZt Duer4GZiitTlyPdMwpbcSffiB4JnXgdpmGQxf+BZ/SfpOTOtd+BZ/SfpOTO/F0zzfVdovopWzTVn lXGcMvBHMfV4gXFpUsD1XuJjR/yyfP6xrMEBZjwJjOSTbZ1403FV4PLHFaF26dh3JkLlrny/6ek9 dza245x2mlAAnlZsrk6R348aiuT0Djmes2BMls8CMpoJO5/kJjDFKb4LSmorkTZ4jVO6IzY9Jz0L A7mUqW9Z3xxxIPtVTit+w6zvWBY1ZisrbJUOeYyLrm8zM2PZ4zBVOZ4zADOZPbbvO0SQxdhNje6b RdqkDqekEUKY6vbWN7/pIZUap8CkIPvvKqBk+4CQ6fddb4rdB0ErZ/DrAHUnmUYLafMMz2YqGUBB 5mgc/GdHp38GGTs9hCE6jEJ4xCjJ6T0+sk1Fu47B0mWXIoRs0hHUwZzY2e09zgTI4Ey74nktub5O tJJGdTaFrOflJazwJ5q1u8UIyNt65AniNkzqhBxXJGpPoceRFuues2MYgxliRYGBEXMWOBHWtgYE SBz7zLJWQaqG0fGVUYqqZ27HPxiq0DHntM6hy7CtTwJV8kFFbEoB+Y5laeXLHvxJKxmwAdhKLWwV QH4yjBcnKTye1nyj4TzvOr0/RzZOwhCE6DMIcdziEk1Fre0hM+UDJEpOairZeMdQy63AwJLdQLVO TgjoYwMc5PeZtsCITPMnklOR1xgookBPmVuominEVW2ck945ek3+AJdNp4nqxjDMzwBJJM2thZPW u59x7TdmXM0i7e3WLKjaRvsz2Xp8Y82brGIP3RiJyKaT6zCEirJ6sZTsFtZLFfecyytgzt6SWoBK 957LgRmibchJlSGVt1mZ63aeT0MftRyvsIQhLlTxiFUsxwBItdqa2p21vknrG62wLSVHVu059YDA gic+Wb6Rvjj8jDSLKVG7lRxEjIJVhyJvxfBVs9B0ia2LsXbvOaGr5NzYBnhE2vSekSwMr0mLmwmJ vgCIfztiSDNK4beZZp/LusP+CIRf9vrGXP4de0dTxKvkg2lmQTnljmV0naS56Ks55G0Ify9fhLrm C07AeWHMNVyRfwVaVvLn35jrBhsiS6Js1yuw/dE0we4yyib/AMGz+k/Scmda78Cz+kzkz08XR5fq u0dPRnGlU46Z+snusNnBHfpDcRoq1BwWP7ZJM8QczzPWZKek9P0sf+U/6NKOJmwnbwYyZqXxLcY4 Xk++cOKLnKjpk6VjNPRgB35z2lPvh0hPYjFQVI4pPU7YTFtS3IUboZuZdtoz37SZVXJC7OU+ntoY 5UsvqJnLDtx75ZqbyFwO8jdvL75wOXPB2LoTaWJx0mUXE2Ru5gx4kkgSF5PMzhr29BM95RWvGSIY GgipMjqIKxcEn0kzsVsIbo0fSRtIlWiEdTTfhj4TWOczGm5TiMnR6dcMwy9hCEO06TETfetfk6sZ NznnrDUsBqjgj7s8BGCc9J5vqJNyo7MaSiaY4Edpqjw7dZnT1b2LsOB0Eqmvp8P8pGeTJ8IDyRnn icXU1nT3FSMAnIM7UVqa67aiLBnHSdOSKaM4OmcsNxPGbrM4ZSV6gdJl8/AzlOoyck5PInqjnJmB kQZ+cYlrVcEDWsABAnlIyd5EUo3tz2lNfTJHAmbA5WFaEnrPA251PrJGtLuVY4HaPpb17SGgjsVH yT2Zo5qzNTqwe058vuCEJ4SACT0E3syEarUijAA3E9pA9ljWG1uvQia1B8a0sOswDsHm+RnFlevg 64RUUNWzOAOSegjjojdURY21j+09+z1QoWA8+eZZ35lsWBLmRSeR3SONqdMdKaxu3KR1grcTqaih dRXsbjuDOVYj0sUsGAO/rJyQ0lscrPS0VY3aes0UTlpmaGlGI1MAZaKBA5M8a3MiiDVreIQoj0XJ AHQRFI7nvG2WeFWTjk/tIA+ywcIDwsfoTgMJzkfLHnrL9GfNx3lWC9ugnk9YTyd+P2o5H2B45ib9 QlScHcT0HpN2nbU5HpOWMMeZXJPSi8IamDM7PvY5JnrISu4GejavzgWCttxkGcvfJ0VRrRVjUlxa uVImNbpl0wQ1jyHrKdB+I3wlVtS3VmtxkGdEY3AynLTI5KQJntlFmncqRuX1iy/aYNUap2ZsbsJl RieMcnpDdxAGo4TmL/Es9w6zDMf1jKVxx+shgoXaMlumJlLASR26CYuBZMKcARVb5bk+aR8EfJ1t AeCDLG+98Jz9G+G54z1nQfnkTTA/+jPKhd/4Nn9J+k5M61/4Fn9J+k5M9PF0eV6rtD623eGD0UfU x6dImvmtf87x6zw/Vu8sj2PT/wDlH6R452qT8pRQnh1BT16mIxuuVe3UyqdHpIVHUUzS5oIQhO05 w74kmquRTknpxj1MqdtiFj8pxNRdutJ/L9ZjlfFG2KNuzy60vYFPBmS3PWJRgxJx5vWNC4xOaqOj 5NrPGE0BAyCWJH3paylUEhuJUrjibqvvvYIbCBg58o6AZ4/QyasJcG7AHnlbGs4YZEyCLg3s5ZCv J3sCDyB1wMcn/wBT1k1gYo6YIzncVAGPf8x+o9ZOlkcHX0D7lEpbrPnE1ep07FQ5QjggqJ0/snVX ak2eM+7GMcAevpNMPDoyyx+S+RfaFhXYgOMgn6S3tOdryLL1A6qMfrNsjpGMFbJghIBzziU6al7T tPQHJPrEhCOh+U1UbVcsOPWcaScrZ1NcUjqAAAAdp7Mo+9ARxNTvVVwcb7DvzINZeB0PBlWpsFVZ OeZwtRYX4z945mOaX8Ub4o3yb37ses9sOYrOcEdZvvOc2YY4mX4jJlhmSgzFQJaVMcLg9JEztW42 nE9F7syixiUB823GcRRNDbkD8957SzDh+vYzZWuwVrSLfEtGUy64+8Rg8egi1r1ZVSoUgruHKnjp 9Y0lVR2dBbvTEf0nz/javSY2sAGPBGD/AHnQ+ydTdqTZ4z7sYxwB6+k1w8cGWWP8jodpJrL8fw1P xlRJ2nHXE5Y8zHd1zNMsmlRTHFN2eBMHImyFYYMy7CthjnMz955ynSV6DCllHAxkSwdJzqrPBuHv 4nRHP6ZnVifBzZVyYsYIhOeTOZrdSDgdYzVX7j19wnMd9z88gTHJLUzXHClY9drdpggZ4ninkzQm ZoYYesxnB5jmEWy9+8sQPpGeTPXO4HMkF1q9G4A6Y6yuy+vwA40yruZ1B3NxgDHf3yFENUIANbdP LLtLZtsHPERZS72oamrrDhOM52llyPU8nM89n1e0OjBwTgEDuTjrjHXjr+0ONjg7xO5ARPJxNRq9 dpWCG3Axn7o/5Gf1nT+z7Wu0aWO25jnJxjuZ0YnxRhOFf9DrF31uvcjAnHVGI68jrO1OXerVamwE YVvMD9f3jMrVjE6EkE8HmMrHOTPWUDG39Z7OY6T2qwpqEHQMQD+svus8Osfmbge6c6tPGvVSMqOW +EHubzbmLBeFJ7ibqWnGYyipSPdVeFUjOT6yFXzzM3WF22g8CeA7sACYryzbTSGs2ekywgvoe00e YIFHIPEo04JXMXjPHA+MWbra2KhsY7YhqyKse7hTtOczOwO2ehmtNa1yWh1qsZU3LvO0A5A65HrB 6Xa5gpSvzGsICTuYYzg49T39YoDqi9ZU9fX3zsVsHpBnCTx61DjUVgbQ/TPBOD27GFur1mmsNXjg sCQcKuIimnZDipKjtX/gWf0n6Tkx2g1N2oo1PjNu2rxwB6xM9TA7jZ5HrI6ZJFmmpdqlYbcH1lAq IHOM+6Z0f8snz+sfOPJ6aEpNs7cWSSgl/QlKmW5nz/t4joQmkIKCpBu3bCeE45xx3nsJLVrgqI1V T217UwM95zn+y9QU2h6xzk8n+06wGDjqJqU0qXLNI5HHo5Nf2Vco5ZD64J/tGf6db+av9Z0pLrrX r8PGdhbzEekbUSd2Qj2C38yfr0h/p1x7r8o1mK6S16biRvGDnOBN0ahGKVMHDlM5I68SNqI3ZEN3 2Xc+MNWMepP9p5X9lait8hqjwQQScEEY9PeZ0RqqzYEAbBOAe0ZbxS5yenVRyJO3Endkc7/THCkV gKrHzbrCSRkHA8vHT9hHez3A2FQqF2ZiRaQRuxkA7fUDn0jaLgtFYy7s+QM9eOY9XBrDcgEZ5EnQ iu4zk2fZOoexnNleWJPJP/Ilf2bo7NJ4hsZDuxjBjq9ZVY5UFvj26Qr1VdjqgzlvukgcwoJOyXkk 1Q/uPTEis0lljs4Zck8ZjvaqzYF82GOA2ODDUX4Dom42BSfL2kyjqKJuIpdLb6qZ6dLZ08v6zyrU irSVvYCSxPPHqfWUo+5yNpAHU5EptRL7sjNFb18MeI2IfUldQtKoTnnjEG1SAvhWbZ97HaaJUUbv kxq9Pbcw2EYxIX+ydQzk76wM8ZJ/tOsjrYgdOQekTVqTZay7DtXjII/eVeNN2WWSUeEQp9lXDqyH 4H/xN/6baD95P1P9pamoR7BWdwLDIOOv+YidPcy2aguWbYcAevOJXaiTuyEf6db2ZT8//ED9nXfm r/X/AMSx9StagsG3MM7e4jKnW1A6dD6iNqI3ZHKs+yNQzBg1X6n+0x/o1+fxKSfif7S2vUmqy82l 2wR0HA7f2jL7Az0YtdNxGABwZO3EndkSt9nX/wAE1mtWqGMliTnOR295m20eqzXs8BRW4ZRkkYH3 R056tz3zKX1lakjYzBWCnj/PSPyCuWyvfmToRXcZyrvsy1qxUjVoqkkbrCxyce73CU/Zuks0fiGw p5sYCnP+dYW6hnto8NmCM+D7+f1jK2zrXXfYRtyUIOB0hQS5JeRtUU9OO8kt0bNYWUgAzTarfSxR WXIOGwOuD/aeaa5hpqtyl2YnpzjmTKOrsom4ijobScgqZoaOwf7lz6cy2T6q102V1+VrD1HpKbUS +7IU2js67k6+srcMUwCBxFWUEITU7Bx33H6TVuoFQG9WbA5I7S6gkuCrk5Miu0F1nIesemSZOPse /PNlWPif7TqPqa12dTv+7tE9pvW8sEDAr1BlNqJfdkuCAfZdo/3IfgT/AGnv+m3D/dX/ANx/tLrb xU6KyMd3TH/uB1KrnKt97aM45P6xtRI3ZEP+m3fmr/7j/aZb7MuI+/X+p/tL11KEPuVlZOoImfa6 iKzhvOcD9cRtRG7I5v8Ao+oP/wBlX6n+0YfszUmlKv4GEJO7LZyf/QnTusFVbO2cCLXVJZZtCOCF 3dM4HWTtobsiZdJq1cNs0vG0qCX6qMA/pFjQatduxtOpUjafNlQDnAz7+/WU0XCvTWWbntAfGSO3 6xw1CgKWU7WXcTx0/wAx+snQiNxnMs+yr7GBBpQDgKCcD9Z0tFQ1GmSt8ErnJHTrCnVJa5RchgM4 Mxr221KSz1nPBAzmSopB5G1TKTFamkXV4/3A5BmfaD7QaRWxwOeRnt757qrvAr3bWJJwORjpJavg onQkaSzHVTA6O3HBWOa8KQpQ726LkTVNq3KSuQR1U9RM9qJpuyFafStUtmcbnGBiIt0Nz9GrGOBk mMutZNfWCW2lc7V+caurqanxQSBnbjvmWcE1RCm07OZ/pF5P4lWPif7Rtf2Vcv8AvrPryf7S72uv Y7HI2nBHcRb2DUjIaxKkBZsdT7vrI24lt2RN/pl2c7q/+4/2h/pt35q/+4/2nQ04daVFhy2OSYyR tRI3ZHKP2ZeR9+v9T/aYf7LvKHcyEjoQTmdiEnbQWWSORR9nXrVYEND+INpLFuB1xx75ur7P1VSg A0sytvQtu8p49Ph3nTwBnHGeuJ7G2idxnMr0OpSo1ldNZldvmLg4znt74u/7L1F1z2FqVLHJAJxn 5zrwk6ERuM5+j0Vmko1G8q25eNufQyada8fwbP6T9JyZ04VSPP8AVvVJNnT0f8snz+sdE6P+WT5/ WOmcvczox+xfQQhCVLhCEIAQhCAEXaXDABNykEEcfKMhAIDpXXTXIEwXbhQRwAZta7RqKXKEBU2n zAyyA46QCPT6Z67CprrI3ZVz1lN4L02KF3ErgczcP0gEKUP7PVU9O7bkk7uRn0lNAsWgCzzOBg5j YQCTS1OKbKnXaXJxPdHTZXw1aArnz9zKvnCAc80agsljKXZX/NwR/gjbaLhe7qm42JgjPQyv198I BGqY0Pg2eVwDwT1Of8Eo09Xg0qhHmxyT1M2yIxUsuSpyPdPcccAwTRNbW/tldyruCjB5xiYFVtZ1 AVC6WjqDjmWfOEEC9NUaaErYgkdYiqq2my8bfv5KnI68yvpD9DBPJBXp70vrtKksMhju69voZ4dP d/EcKVYsGU7h/n/qdDEOp7mB2R3VWvZXd4asQMOhMqqXagGFHPRek1gA9D84Y9+ZFoVRAaLdt6bf xDw2R0zGX02bqNi5FZ65lc8HXj69ZPQ+iB0w72Lpy1ed3DjnHHf5y0/xacDjesyNPWONpxnO0kkf p0je2IIIBRcPAXYCK2zkEZ6+kYKXbWXOVKq67QSRkSvJhAI6kvTStQa+AMA7hzMUVXUmp1Rtw8rA sOR+svitQLPD3Vk70O7GfveokMlcs9qNpZxYoVQfKR3EXqKrLcMjBWU+XMcjCxFdDlSMiaPv4+Uc MOJOLb+FNSq3rnOflFaqi62x+Cy7RtHQA/5mWKAvQfOewrBC9VzHT7qua+vIjNIliW3M6YDHIlUJ IJtagtq2A+bII56f5/xPNRpiFpNa7vCb7vrKNqM+/aC3SajgOyXwHe660grvTaFJiko1GNOpRR4b dd3vl+M8w5xzx8oFCtUQaCrKp3HAG7GfnEUZquCvUQ7rtDZBPA6Sp0WxcMMjOeOILWqnIGT6k5P6 mAT6ShxRZVYm3J9Z4mkc6RqWPnI2jnoM9JSCpYqMZXGeOk10ggRpUdR/ErCEDBPrM66t7alVEyc5 PIlMOkAmWuxNabdhKMvY9/8ABPdbU9tChRkhskAygcdIfIfpAJbEc6irUBM7eCmRn/OZrTUtW1tj ZBsbOCeko6Q7wCWxH9sW0VsVVMZBHviV01raNq2Uqd+8AkHM6EMwCSyqxtI48BVLH7oIm8P7JtFf nGAASOcfOUQzjnOMe+ALex1RRgeK3AHaMiqcuxuPfhR6D/zGwWkq4CEIQVCEIQAma7FsTehypzzF atm2LVWcPadoI7Duf0jkVURUUYVRgCSSZv8AwLP6T9JyZ1r/AMCz+k/ScmbYumcPqu0dPR/yyfP6 x0To/wCWT5/WOmUu2dWP2L6CEISpcIQhACEIQAhCEAIQhACEIQAhCEAIQhACZFis5UHJHXHaZesu x3Odn5Rxn4mbVQowoAHoILcEur3DUUhXYBz5gGPPInljGnVVipidxw6liYa0F7qQKy+1ufKSOolK V1qD4aBMjsuDMabbN7SjFsW+qrQk4YopwzDoJ7ZqUqZAwLB+FKjgyeihUFlVqWHnPU4M1qVIs04W sgIw4AJwMiRqlVkqENVD11Cm4VMrKSMjjrF1eGda/wCIHxkjPHaZsDf6jWwVsBcHg/53hXkfaVj7 G2kYBxx2jU7/ANI0qv8ABntS7WZUZ1XqVxHcFfj75AtdisjVb0YsN64O0CdDPrzg9peEm7spkjGL VEFDKLbhbY4VWwAXI7mOrY6fTm1y7qSCCeuOPWK02FfUNZXYA548hOf2ntzM9FlaUuFUAKCDyJmm 0rNmk5V9Djq61VXKPsbuR0itbxqdMfVsfLImdQGbRUqFYnjIwfQzWqy11BCN5WyeD6iHKTv/AAiM Yp/se16i41KrMwGSFx/zPE1CvQbVViF6g9RiJcN7W+5WSsr95V5bp1OMzOmRk0l6srAnPAB5yJOq V0Rojpv6HLrK2CcMA54JH7TR1SbXZUdlTgsAMfWY0aA6ZN48yZzuHv8AfJuj3KFtCMcjwwCD6xqk knZKxwcml8Fg1KGkWEOAThRjJJ9OJqq1Xdk5V16qeskcJdVVZQr7KnwVxzKaUqFrPWrAnuxOT+sm MpMpKMEmK1Nfg6WwozDzZUA425PSYuIXSJYrsLCoI8/X5R2uydOyKpJboADzzNaatPDTNYDBQMkc 9IkrlSJjJKCcvJ4uqDMq7GNm0EqO3T1nh1IfStZWDkA9cZBxFuGOrfcrJWV+8i8t8TieaStvZL62 UhiTjPw4kapXRbRCr+huluL0BrQ3AJL8AHn0gdWiqHKsK2OA3H94qtDZ9nmnDq+05BGO/wCkZSwa la7KTvHRSuf3iMnSIlGNtryLVtn2jbgMRtyAM9cCUVXreWCggqcEGJpDD7RsbaQGXAIU46CGjyLb yyuNzZBIkRck/wDRkjFx+kjeuyNKzglWBGMExNpC6NLFscWEDHmPPHpHa7LadkVSS3QAHnmJNP8A BrtrB8SsAbSPvSZJ6nQxUopy8lFuoNKI1qNkgZx6wbUDICo7ZGfLziLssa6pKxU4L8HKk7ffMaTx aHehkZlJ4fmTqadEaE4tvspqUhfMfMxyeO8ZiYur8VQu51x6HE9pq8IfeZve3WaWzClVmoQxiEsV CEIQAhCEAIQhACeEAggjIM9hACEIQAhCEAIQhACEIQDF/wCBZ/SfpOTOtf8AgWf0n6TkzfF0cXqu 0dPR/wAsnz+sdE6P+WT5/WOmMvczqx+xBCEJBcIQhACEIQAhMkMDlTn3GaHSCQhCEEB0ifEa3inh e7np8vWNZVddrAEehnoHYfCQyU6PEXaoXJOO5OTPYsX1nfhvufeGOkPaKhV4u8bT0z3kgZCLTUV2 IzowIUZMDqKRWthbyscAwQMhF2aimrIdwD6TasrKGB4IzmAewxnsYoaqlrNviAH0k2qvHtaVNYUU Dkj1/wAxBJf17EzzpxzIWuWzW+GbWWscDHc8cSg6qoOELgMOuen6wB2T6w7Yi7b6qVy7jB6YiH1i pqlVmHhlck+nWAVwk5tJ1NYW1QhXJGOvWb9oq8NrNw2qcE4PEEDesMmLe+tEDF1API9f0ntdqWLu RtwgmzeTDMXbdXSAbGAB6QS+qwkI6nHWBYzr15h3iG1dCnhw2ewm2uRWVGbDMMgYgj+hjDerK3IY YiU03hr4aWuq91E9GpqNbWB/IpwTjpPTdUPDBb8T7vEhxTLKTRqupKl2IMDOees1E26mqptruAcT bW1oFLuAGGRzCVENt9m56OnQxdVqXLurO4A4z75I1ws1uxrGWscDHc8cSQXe4/vCJOqpVwjOA3Qz dl1dXDuoOMjEA3z25+c9+fyExW6WoGQ5VpHo9UiVHxbPMWgF2T6w7AdhFvdXWgZnUZ6dzPVuqesu HXaO8A3CKTUUuzKtgJAyfdN1OtihlOQe8A1DHxi7L6qiBY+0nsIjUXpZp7RVaNy4JGSIBWRzyMQA +Jk9GqpZa0Ng3FRn9JmyxxdevjDArJCgHIOPXEEFXSEhpsdaNNmwDcx3ZBJPM3p9YGdksIzuwh9e YBXCIosPiXCy0MqtwAMbeZqvUVWtsRwT24xAG/LMOfQTHiKbDXnz+kl+zXZzaWYnGMfvALYQngZS SAQSOoB6QD2EIQDNhcLlACR1HqII62LuU8fSamQihy4GCevvkA1CEJICEIQAhCEAxf8AgWf0n6Tk zrX/AIFn9J+k5M3xdHF6rtHT0f8ALJ8/rHROj/lk+f1jpjL3M6sfsX0EIQkFwhCEAIQhACEIQAhC EAJ6O3xnkIBzr9+nstVAGW4YHPQzV2msropwvibD5gB1zzK0oqSzxFTzepOYyAQ1Vu1lz+F4asmA p4iSLm0iU+A3kbr+s6kIBIlW77QsL1nBUdRxnEpsUtSyqByvT3zWTDEA5ldJCiu1dRkH/b92PtrB 11R8PK7OfKOvMs+ZhAJEp/8AkLD4fkxxn14k4pZQyXLewJ/+s5BnT75hAIb62S2q0VmxFXBU9Yah WGpS5aC67cFcfWXQ+ZgEbKza6ljWVATnHbrFtTcos0y15R2zu/edDJhAItTQ6vUyh2VBjKHkRmjR RvKi0Z6+J3lOIEk9TmAR6utxelvhF1A5XrzF11ubb28BkDVEAY7zoQgHLOnYaRDsbfnGMdBzKbAy 61GqrfnAYnpiV5hk+p4gJUc5qrgLNMqZSx87sdP84mqktttpFle1ae/cy/8AT1gOBgQDnNS6W2b1 u2uetR6/GasqA9mVUcqDyGAzjMvhk5gGUVVGFXaPTpJkpz9oWE15XbkZ6Z4lcIByzVaK3pNBZmOR ZjMe1RGroDISAmDxx3lsIAABQQowB0GJzUp/6GwGsl93HHwnShAILabf4Fm1yFUZ2nkQNY9ku8NL ssR+IBk89pfPcnOcwCUUp7GAauSgzgczWi3+Dh124OAcY4j/AJn9YQCG9Wr1b3GjxFYcYGcdBEnT k13k1MrBgUAHbuJ1P+Yevvgk5pSyxKqhpShGMvj3fCNNbjU6g+GcGraD78CWw6wQc9anCaQGtvK/ m/We0oyap19m3BmyDjpzL++YQCAU2MNUApXLZGRjvPKastWrJqNyt36CdD9YZ98AjQFNa2xGCN94 t/xNaNCniDwfDyfXMqyYQDD1B2yxYj8ucCaVVUYUAD3CewgBCEIAQhCAJ1DW1gWJgqv3kx1HqPfG VWJagdDlTNRVFXgqyjGNxIx6e+R8gbCEJICEIQDF/wCBZ/SfpOTOtf8AgWf0n6TkzfF0cXqu0dPR /wAsnz+sdE6P+WT5/WOmUu2dWP2L6CE8bPUfpAHIyJS+aND2EISSAhCEAIQhACEWRYjFkO4HqpP0 M0jh1yMj3EYxBFmsfGB69MSXXO2a6UOC5yTnpPadSo0YtYE7cAwSUwiE1SO5TzAhdxOO2J5XrabL NgJUk456GAUc+4++e4+JkdFiLZqCXbCHo2OOYqzVLfbSKi4BYAg8Z5EA6E9A9xmXdUUsxwoGcyGz Ui62kVlgC2COxgF8JPbrKq3KMWOByRA6ytURyrEWHA/WAUQk66ytqncZ8nXMK9ZVZaqAOC3qMYgF EJP7ZXuwAx82N23y/rC3WVVWMjbiw9OkAohJ7NZTXbsyx9TjgTZvTxVrAJLDIMAbCJGprPiZ3KKz gkj3zdVgtr3gEfGAbnoHuMmt1lVVjI2SwHb5TGpuV9OliOy+YDj/AJ5gFf8AnSEhZ29p1ADnC1Ej B74E3TqFr0lZsZizE4HUnmAVwgORnoMZ5kz6+hC2SxC9wIBTCTvq60KKQ2XUMOk9XVVGg3E4Xpjv mAUY9x/vPJCuoF2tq2M2NpyD85VfclKF3YgZwPefSAMgQCMHkRLalFNflf8AicAEQOprFliYYFF3 GAe80ju1f7r/AOI0HIyMHMmGupYE8gAZ6e+FOrpsZa0VvN2GBiAU/wCYhJNLctemexnLYYjkYz7o xtVWlIsbcA3RT96APHwJh0k3tSWrYqBwVQnM1oSW0qEkkknr8TAHwk9msqrtKEsSOpxwJ7bq6qnC Nuyy7hiAPhFV6mp6jYGwF656ieU6qu1wo3Kx6BhjMAdCTV62mxto3jryR0nh+0KBnhuDgcQCqHPu Pvka6phrGQ7ih4AwODNUWItmoYu2EPQ9uYBVCIo1dV77V3A4z5h1i/8AUKcDIcEnHTpAK4c+4++K OorW40jcW4zgZx8YrRljdfuJIDYEAqhDpCAEIQgBCEIATJdVdUJwzZwPXE1F31eLXgHawOVb0PrB K/sZCLosNlYZlKt0YehjIHRi/wDAs/pP0nJnWv8AwLP6T9JyZvi6OH1XaOno/wCWT5/WOidH/LJ8 /rHTKXbOrH7F9BCEJUuEIQgBCEIAQhCAEOMiEIBI2jNtzWWsQD02mC6Nl8WvINTDIye8rhAJdPpG TebG3My7c+6Yp0dgdBY42I2VAlbKTgqxUiZFm3y2DaT37GCRI0rEXrYw/iHjBmBpLyai9iHw2GMD tLe2IfKCDF9YtqZDxn07yVdJdmsu4PhsMAAdJbMXVC5NjMwB67TjI9PhAOe1d1t9q6VwKyfM5Ax8 B75QNI+3TjcP4bEn38ypVVFCqAFAwAB0nsAkGlO3UbjlX5AUZPEVpaHGoRsWbVByXGP0nQhiAQHQ MpOBW67sjcSDKEoZdW1rEFGAH7R8IBFZorGdwrjw7Dlges3dpbPFrepwpVdufdH2WJXjceT0AGSY Vsz5JrKjtnqYFk9WlsVbhYUdrDkZ6GN01LU1FWOfT3R0IBA62Nr7RW4U7R1Gewmzon9mWtXBfeGO eks+QhAJjpnN9z8YdNoz8P8AxMNpLDpUqJQOvJJzxz2lmBCAeKAAqlieMZ9ZE2iuCWVpavhnnBA6 y6EAmXTWePVYSpCIF6/GLTRN7Ka2K7twYES2HQ5gElemuFyW2OpIyOAI7VV+NSyrtyfzdo3pCASW aW011Ktnmr5DH9YJprxZa7sGLptzK4YHpAJk05XQmlydwGfLyeuYjTUudQj5sC1rybBj9J0MQgEY 0LHSvUXGS+9ces3dp7bkrLFfGXv2MphAJE0twstZmDb02+nPyj9LW1OnWtj5hGYB7QgEVmisLuqu vh2HLDvM3qy62lEcKQmASMgdZf2h8oBKujPg2rY2Wc8kDieUaWyuwMy15553HPSVwgE+n07V0NW+ PMeoiDo7vDFYsXYrZAxL+pzD5QCbwLRqxarqAw83vGJldKxF6uwxacjBlmP/AFPIBJTpbEtWy51J Rdq7fSY9ic6Y1blz4m7Pul0P0gE76d21KW71ULg8Z5mqK3R7WdtwZuI6EAOkIQgBCEIAQhCAEIQg BCEIBi/8Cz+k/Scmda/8Cz+k/Scmb4uji9V2jp6P+WT5/WOidH/LJ8/rHTKXbOrH7F9BCEJUuEIQ gBMWMykELuXuB1m4QDxWV1DKcg957MqiqSQMFus1ACEIQBDU2Bi1V7KSclX8y/3H6wW25WC20Hk4 31nI/uI+EmyQgQCMEZE8JAGT0no5EiyDIKJtTcB6DvPSwDhSQDjODIdajPrECHDbSQfQzxLRdrqW K4YKQR7+cwDoQkSau1nDCtfCLbffLHYIhY+mRAPYSKrXFrFDAbWOOAcj4zb33rZ4IRC7HyHPGIBV +hhIFe0a+zCg89M9oyvUXWXsqou0NyT+WRfNEXzRXCQnW3FXsSpTWpxmWVuWpVyOSoMkk1Ms6qQG ZQW6ZkY17G37oKZxtGd3xi2a5ta+2tWIHfsIB0dy7iodSw7T2c3R2tVXbcyLtH+7uT6R2n1TtaK7 VUb1ypU9IBZCc/2nU26diK02jOWBm9LbZXoyxTco+7z155/SAWMwQAswAzjmeyC9m1GjVzsBD9c4 AlzHapJAAHJ+EA8LruC7l3ek1OSb18Y3b8tv4GOoluo1JrsRVC4bncTxAKYTLuqqxPYZkdWuL2qC qlW4wM5HxgF0JG+quNlgqrDLXnOfnBtY60VvsGXJyTnA5gFkJJdqmS1VG3BQt684J/4j9NY1tKsw ALHtAGQkb6q4vZ4NasqDnMG1jrRW+wZcnJOcDmAWc5AAzDI590ySzV5UgHHUcyf7NyaXycnfgkwC o98kADuYn2qjfs8QZjuvlwDmc7XV1lkpqRfEJ6jtAOjFam8aereV3ZOJtBsrUEjpwfWL1ZxXgOis TlSx7wBVOvWywIybcnA5zK+k5RbZqxZay2nIOU6ZnSturq++ygk8D1gG5Hr9Qy4qrPmHJYekpvs8 GlnxnHpOWbkFFu/ebHxzgYHMAt+z3JodmbkMeWPbEpUggFSCD3E5+jsHs91eOcFsmU6NCujRfTPQ ++AOJJOF/X0moseJjCoq/EzShgSWbPuAhLySahCEEBCEIAQhCAEIQgBCEIAQhCAYv/As/pP0nJnW v/As/pP0nJm+Lo4vVdo6ej/lk+f1jonR/wAsnz+sdMpds6sfsX0EIQlS4QhCAEIQgBCEIAQngYFi gI3DnEAwJIBBI4OO0i0WpnsJ4HVhlWUj1BgjK4yrKRnHWLIpr4PCuWyTnHQTUwLayR/ET4ZmtyBg pYAnt3kJx+CdL6owaFbUJduO5RjE89mr9oF6lg3cRhZd20uFbGQJnxayu7xFxnA5k2hTfwLXSVJc bFB5zwegjyAQQRwwxPGYKAxYAE+sCyoMsygfHrFoU/AlNItbLttsAU5ChuBM2aVS24s+Wbls8j0j ldCDh0I7maVgygqcj1ElNfBDg/kU2mRrxad27j54mq6lrsZgxO45xNs6rjcwHxM9zhNxIAHUyGGn 4JW0FLMT5hnoAeJSihECr0AxBWDAMpU+hB6z2SmmGmif2RNx2WWICclVPEYKALmtBbcwx2jIEZgg VXpq0rasZKsckETNOkroYspJbpk9o+EAVXp666mrG4q3UTNWlSlHCswLdxx0jyff098JD/on+yc6 Oo1eH5gucn3mNtqFlRryy54ziaZgpALAFjgZM9Px/eETTFezU+Hs29sZxzFvpq1RTY7FKhnBJ+Mp zMuiuu1xke+SVMadD4TM481vLZ7e6ZXSbCNtlgA/2g8R88wJCVEiLdFTa5Yhhnrg956dKngrUXYK O2esZazoma6/E55XODj3TNOoruJC5VwOUYYI+UkgXqKWcLWlfH58/d/wShVCAKvAHAnsIBPboqbX LNuGeuD3nvsqeCtRdgo7Z6xzsqrlioBPee/pI4J57PAoVcDgdog6YpQa6rNpY5yZRCSQYrrFVQQM eB1k50FRJYvYSfQyuGdoJJ4AzAJl0hDr52NadiYy+ivUbd4Pl6YjCwADlvL2OYAgttBBPfHaRaLa WT16CmtgfM3uPA/aYOlsu1W+7bsXGMDiVeImCd64zjOe812xFojS12H6GYtrW1CjcA+gm54WG8Lu AOM4zHRKti6tOtVTVqWIb1mqa1prCISVHrN/P94SSoQhCAEITwsNwXcoOM4MjolWwI9ODPYAdPfM hlbIU5I6xwmTyzUIQklQhCEAIQhACEIQDF/4Fn9J+k5M61/4Fn9J+k5M3xdHF6rtHT0f8snz+sdE 6P8Alk+f1jplLtnVj9i+ghCEqXCEIQAhCEAIQhAIyRT9osz9LFwp/wA+H7xWl1CVvqLD0bLD3jJl l9CahQr7hjoVmX0dVgQHcAgxgd5zyjK7R1xyQrklz7N9ndQHtOR7v8E19nWKLWpUgrgEfHHP/Mqe hLLFds+XgL2njaaverqNhTkbeI25Jqhuwad/JzKxU1RBrbxWbCN2HSO1FTtfSm7zivOffKxo61pN eXwG3A55Bm/AU3LdltyDHPQyqxsu88b/AGSV2eNrqiRghcMPfzEAf9B//X/idL2asagXDcG/YzHs VRr8LL7d27g8xtyZCzRtf4RahmWgadh50fIPqI9wl+uNdvCKOB0zKL9NXqcbgQR0Ihfpkv2lsgqM ZHEnbZG7CvAgLp1e6upSGFZ78R+iUppkU4zz0+MymjqQEDeSVKk5yY2qsU1itc4HQmXjFp8meScX GkyDXOtuo2lsKi8e8w1N72aKthjk4bnvLE0tSAgpvyc5cCZOiqKlMuAxzjjj4frM3CfL8mqywVLw Rk3pqkARVdR5Vzx3lGo1hrtatNuR1LAnJ92I63TJe4dt2QOx5MLNMlr7gWRuhKHBMlQmk6ZV5Mcm rQl9W+yh60B8Q4IJlNJsKKbEAfuBMeyq3h5Zj4fIPUmN68d+01ipW22ZTlCkoohGtv8ACNvhKUU4 Y55jbdU++tKUDM4zz2EVpvs9WTNy483Y9RxxKbdLVft3KVK8ArwcenwmUVkcezaTxKXRJbqLbaLV ZVUKwzz0jE1D06EPYF3EgLz14jF0dKVugDbXxwT0xNDSVLSasEqTnJ6yVCfkPJi6r5JtUz50pdQb CckDt0xKNHe9xsV0ClDie+y1kVgs58I8cj95uulanZ1LHecnPSTGMtVlJTg4VXItrnXV11YG1lzn vMLq3IvbYGFbYAUcnmMv0ld7KzbgQMcdYJpK61dVLgWdcHp8JLU9XBCePTYs6srpPFIUsTgBef1m tLqWudkcDIGQVBwZv2SnwvC2HaTnPfM9p0/hNuFljcYwxyIqdp2G8elpIxq72oCqqgu/TMzqNRbW yVIqm1lzjPEddQl6BGGPQjqJi3S13KA24EDG4Hn5yZKbuhjeNVaEvrW9mFiKu4NtI9ZqrV2eJYt1 aqFUt1jG0lT1CoblAOcjqT75oaesWtacksNpB6SunJfZbVjqqINRdZfUrNWAhbKkH4ym/VOtprqQ eUZJY/SenQU4b7/JyOenwm7tJVc245U9CR3ldM1ZZzxukKfWORUUrxv4we590x7bdssPhr5Dgn0l J01beHgMoqOQB/zMnSVlLRlv4hyTn5y2nJ5KxlirlGLdWymoBVG9QdxPEqcKysGHlIwfhFNpa3CB t5FYGADxGMN6MpJ5GJeKlzZlJx4rg5laq160vZ/CUnGT190drR4V3iVsA7A5UHqPWUex0moV7WAU 5B75mvATxTaRlmGOeg4mW29NG+7FtMivRE0Fe0hgXBJz1M6QPHY/CTnRVGo15YKTu69J7TpUocsr OSexOZeCkmUnKMo9nmq1DUBNqg7j1boIp3B19J2qTsJ4Px6dpTdSt67XL4zkhSeZltLW7hssCF2j nj/OYkpNsiEoUTVavUWWhQiEAjOPT9Yf6gd/QFM4wPvf2jU0FSMrBnJXoCRib9jTeWVnQZztU4Eo o5K7LueHwOdglbOeQBnAkdWtdrU3IAlhwsswCMdQRgxFeiprsD4YkdATwPhNJKbfBnjcEnYl9Zer W7a1Ko2M+7MGO/XUPxnw8/WOOkrK2jLDxDknM0NOi21uCdyLgA9JTRPyaKeNdL/6ievXWEoMJ5rC vf3f3m9Guy3Uc8b/AF981VSTqfFdAgXooOefWNroWl3cZzYckHpJjGVqyJyik0kM+eYQhNzlCEIQ AhCEAIQhAMX/AIFn9J+k5M61/wCBZ/SfpOTN8XRxeq7QQhCbHKEIQgBCEIAQhCAEIQgBCEIAQhCA EIQgBCEIAQhCAEIQgBCEIAQhCAEIQgBCEIAQhCAEIQgBCEIAQhCAEIQgBCEIAQhCAEIQgBCEIAQh CAEIQgBCEIAQhCAEIQgBCEIAQhCAEIQgBCEIAQhCAEIQgBCEIB//2Q== ------=_NextPart_000_0023_01C8638C.FB22EB00-- From altair43@hillcrestchurch.ca Wed Jan 30 18:11:02 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKM58-0002u2-PB for ccamp-archive@ietf.org; Wed, 30 Jan 2008 18:11:02 -0500 Received: from [41.248.2.140] (helo=emzgzm) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JKM55-000586-7o for ccamp-archive@ietf.org; Wed, 30 Jan 2008 18:11:02 -0500 Received: from fbg ([119.73.95.46]) by emzgzm with Microsoft SMTPSVC(5.0.2195.6713); Wed, 30 Jan 2008 23:10:56 +0000 Message-ID: <47A10400.1000103@hillcrestchurch.ca> Date: Wed, 30 Jan 2008 23:10:56 +0000 From: User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: ccamp-archive@ietf.org Subject: Cheap meds for you and your girls! Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 4.6 (++++) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 the best way to increase your PE! http://76.248.153.187/owejz/ From gwendolles@quikx.com Wed Jan 30 18:11:04 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKM5A-0002uR-NG for ccamp-archive@megatron.ietf.org; Wed, 30 Jan 2008 18:11:04 -0500 Received: from [41.248.2.140] (helo=emzgzm) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1JKM5A-00052s-4A for ccamp-archive@megatron.ietf.org; Wed, 30 Jan 2008 18:11:04 -0500 Received: from tdwv ([73.137.189.165]) by emzgzm with Microsoft SMTPSVC(5.0.2195.6713); Wed, 30 Jan 2008 23:11:02 +0000 Message-ID: <47A10406.2020501@quikx.com> Date: Wed, 30 Jan 2008 23:11:02 +0000 From: User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: ccamp-archive@megatron.ietf.org Subject: All that really matters for a hot woman! Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 BLue-pill is not for all. Is it for you? http://75.6.161.156/tlmub/ From owner-ccamp@ops.ietf.org Wed Jan 30 18:48:00 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKMeu-0001l2-GA for ccamp-archive@ietf.org; Wed, 30 Jan 2008 18:48:00 -0500 Received: from psg.com ([2001:418:1::62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JKMeq-0005dJ-De for ccamp-archive@ietf.org; Wed, 30 Jan 2008 18:48:00 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JKMXq-000JvA-Rb for ccamp-data@psg.com; Wed, 30 Jan 2008 23:40:42 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [64.208.49.27] (helo=smail5.alcatel.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JKMXm-000Jua-Ea for ccamp@ops.ietf.org; Wed, 30 Jan 2008 23:40:40 +0000 Received: from FRVELSBHS05.ad2.ad.alcatel.com (frvelsbhs05.ad2.ad.alcatel.com [155.132.6.77]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id m0UNVZiv008041; Thu, 31 Jan 2008 00:31:35 +0100 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.51]) by FRVELSBHS05.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Thu, 31 Jan 2008 00:40:20 +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: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Date: Thu, 31 Jan 2008 00:40:15 +0100 Message-ID: In-Reply-To: <2ECAA42C79676B42AEBAC11229CA7D0C01D4269F@E03MVB2-UKBR.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Thread-Index: Achid4JetInOIvLXS36xGBjOv4vCdwAOqlZgAB8MVpAADGxFgAACaWoQAADUPSA= References: <2ECAA42C79676B42AEBAC11229CA7D0C01D4269F@E03MVB2-UKBR.domain1.systemhost.net> From: "PAPADIMITRIOU Dimitri" To: , , Cc: , , , , X-OriginalArrivalTime: 30 Jan 2008 23:40:20.0178 (UTC) FILETIME=[79A0B320:01C86399] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 3643ee1fccf5d6cf2af25f27d28abb29 =20 neil,=20 > -----Original Message----- > From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]=20 > Sent: Wednesday, January 30, 2008 7:14 PM > To: PAPADIMITRIOU Dimitri; howard.green@ericsson.com; loa@pi.se > Cc: benjamin.niven-jenkins@bt.com; lberger@labn.net;=20 > dwfedyk@nortel.com; dbrungard@att.com; ccamp@ops.ietf.org > Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt >=20 > I personally think you are making a mountain out of a molehill here > Dimitri. =20 the segmentation of SCs we have in RFC 3945 is sufficient to address your below decomposition. you have to consider that when a new techno is to be supported by GMPLS, stacks are not going to change the full engine/stack per specific technology - > And I thought I had explained why there are differences in the > treatment of layer networks depending on their mode...I clearly did a > bad job. =20 don't worry, we very well understand the difference between a circuit-switched and packet-switched network.=20 > Sure GMPLS is a generic OOB CP suite of protocols, but the > details of the parameters used used to describe the layer=20 > network being > considered will depend on: > - for the co-cs mode whether we are dealing with resources which > are either regular time-slices, freq or space > - for the co-ps mode there is only irregular time-slices. L2SC is in the latter. =20 > And the labelling of such resource partitions is different in=20 > each case > too...so just like it is impossible to have a common (ie=20 > single instance > of) CP running 'IP to Optics' (or any functional component for that > matter) it is impossible to have an identical set of parameters > describing each mode....this is just the physics and the way=20 > it is. The > co-ps mode has the richest scope for 'variation' in the DP=20 > labelling of > traffic units (this is more than simply a destination proxy label > BTW....this was a point I saw Adrian alluding to)....and one can even > violate the rules of connections here and really screw-up any=20 > notion of deterministic resource management anyway. does that imply change in the def. of L2SC as defined in RFC 3945 ? or is it an add-on that is not impacting other RFC's mechanisms ? my understanding is the latter but never got an answer whether or not this is indeed the case (and proposal on how to spell this in the doc.) the addition to adrian's text is a way out. it is to be followed by discussions because the protocol aspects remain open.=20 thanks, -d. > regards, Neil=20 >=20 > > -----Original Message----- > > From: PAPADIMITRIOU Dimitri=20 > > [mailto:Dimitri.Papadimitriou@alcatel-lucent.be]=20 > > Sent: 30 January 2008 17:23 > > To: Howard Green; Loa Andersson > > Cc: Harrison,N,Neil,DMF R; Niven-jenkins,B,Ben,DMF R;=20 > > lberger@labn.net; dwfedyk@nortel.com; dbrungard@att.com;=20 > > ccamp@ops.ietf.org > > Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt > >=20 > >=20 > > =20 > >=20 > > > -----Original Message----- > > > From: Howard Green [mailto:howard.green@ericsson.com] > > > Sent: Wednesday, January 30, 2008 12:09 PM > > > To: PAPADIMITRIOU Dimitri; Loa Andersson > > > Cc: neil.2.harrison@bt.com; benjamin.niven-jenkins@bt.com;=20 > > > lberger@labn.net; dwfedyk@nortel.com; dbrungard@att.com;=20 > > > ccamp@ops.ietf.org > > > Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt > > >=20 > > > Hi > > > Dimitri seems to me to be making a very abstract and=20 > > legalistic point. > >=20 > > receive my total disagreement. an individual submission that=20 > > asks to change an existing RFC requires discussion and=20 > > particular attention (in part., when it is the protocol arch.=20 > > document) - if this not possible then probably you have to=20 > > write also a doc. asking for changing the IETF proces - and=20 > > then you come back with your individual submission. > > =20 > > > The reason why this work is important is that the IEEE has > > > been evolving > > > Ethernet to give it carrier class features, in respect of=20 > > scalability, > > > OAM, and (with 802.1Qay) the possibility to use an=20 > external control > > > plane.=20 > >=20 > > no one i think question this. and i don't think the poll is=20 > > on this specific point. CCAMP or even IETF at large is not an=20 > > authority to decide upon IEEE technos. > >=20 > > > Some of these features will very likely require or enable=20 > > added value=20 > > > from extensions to the functionality of GMPLS - for=20 > example, as has=20 > > > already been suggested, the addition of functionality=20 > for creating=20 > > > the OAM associations. > >=20 > > indeed, and your colleague has already received a list of=20 > > comments to be addressed before seeing any way forward w/ the=20 > > proposed approach.=20 > >=20 > > > Therefore this will likely not be the same as the > > > possible use suggested in RFC3945, which may (at least > > > in theory) have been implemented somewhere.=20 > >=20 > > the exact problem, i mentionned a couple of times. your own=20 > > comment shows that one may use GMPLS differently but may i=20 > > ask WHY ? and what's the implications ? > >=20 > > > Therefore the suggestion in the draft seems to make sense. > >=20 > > why ? > >=20 > > > I can't really see what important principle is being > > > defended by the insistence upon L2SC, which, as Don Fedyk=20 > > stated, was=20 > > > always somewhat underspecified. > >=20 > > THE reason is that an interface SC or a related functionality=20 > > has never resulted in a specific change in the base protocol=20 > > building blocks. GMPLS is a generalized approach not a=20 > > differentiated approach per interface. > >=20 > > actually your last statement is not correct (L2SC is well=20 > > specified in RFC 3945) AND by the way yours does not at all=20 > > better specify it. > >=20 > > > This is not something to be debated in the abstract. The=20 > > work in ccamp=20 > > > should allow sensible extension of functionality where it=20 > > adds value,=20 > > > and this needs to be discussed on a case by case basis.=20 > > Therefore we=20 > > > should make it a working group document and get on with it. > >=20 > > -d. > > > regards Howard Green > > >=20 > > > -----Original Message----- > > > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On=20 > > > Behalf Of PAPADIMITRIOU Dimitri > > > Sent: 30 January 2008 10:15 > > > To: Loa Andersson > > > Cc: neil.2.harrison@bt.com; benjamin.niven-jenkins@bt.com;=20 > > > lberger@labn.net; dwfedyk@nortel.com; dbrungard@att.com;=20 > > > ccamp@ops.ietf.org > > > Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt > > >=20 > > > loa, > > >=20 > > >=20 > > > i think the main point as ccamp is whether or not we poll=20 > > for a change=20 > > > or a continuation inline with RFC3945 -- when the present=20 > > doc. states: > > >=20 > > > "It is expected that there will be no > > > case where an Eth-LSP will be signaled, or an Eth-LSP=20 > supporting > > > interface will be represented, using the L2SC switching > > > type/capability. A new switching type/capability is=20 > required to > > > avoid any potential current usage of the L2SC switching > > > type/capability in support of Ethernet. > > >=20 > > > [...] > > >=20 > > > "The L2SC Interface Switching Capabilities MUST > > > NOT be used to represent interfaces capable of supporting > > > Eth-LSPs." > > >=20 > > > it raises three issues: > > >=20 > > > a) what was the previous L2SC def. per RFC 3945 meant for if > > > not for use > > > also in GMPLS Ethernet context ? > > >=20 > > > b) why a "new one" ? > > >=20 > > > this is not explained. > > >=20 > > > c) what is the "new one" implying in terms of GMPLS ? > > >=20 > > > for inst. in the intro "The intent of this document is to=20 > reuse and=20 > > > align with as much of the GMPLS protocols as possible."=20 > leaves open=20 > > > the issue of what as much as possible means. > > >=20 > > > and on the other "Additions are made only to accommodate=20 > > features of=20 > > > Ethernet that are not already supported by GMPLS." so,=20 > how shall i=20 > > > interpreet the first sentence now ? inline with point a) and b) ? > > >=20 > > >=20 > > > the doc. in WG I-D status or not is not going to provide an=20 > > answer to=20 > > > these questions. sentences and statements in the doc.=20 > > contradict each=20 > > > other. > > >=20 > > > thanks, > > > -d. > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > > > -----Original Message----- > > > > From: Loa Andersson [mailto:loa@pi.se] > > > > Sent: Tuesday, January 29, 2008 2:04 PM > > > > To: PAPADIMITRIOU Dimitri > > > > Cc: neil.2.harrison@bt.com; benjamin.niven-jenkins@bt.com; > > > > lberger@labn.net; dwfedyk@nortel.com; dbrungard@att.com;=20 > > > > ccamp@ops.ietf.org > > > > Subject: Re: Proposed WG Draft -=20 > draft-gmpls-ethernet-arch-00.txt > > > >=20 > > > > Dimitri, > > > >=20 > > > > it is possible that you have a point that needs to be > > > discussed, but > > > > is this really something that should stop us from adopting > > > the doc as > > > > a working group document. > > > >=20 > > > > /Loa > > > >=20 > > > > PAPADIMITRIOU Dimitri wrote: > > > > > neil, > > > > >=20 > > > > >> -----Original Message----- > > > > >> From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] > > > > >> Sent: Friday, January 25, 2008 2:27 PM > > > > >> To: PAPADIMITRIOU Dimitri; benjamin.niven-jenkins@bt.com; > > > > >> lberger@labn.net > > > > >> Cc: dwfedyk@nortel.com; dbrungard@att.com; ccamp@ops.ietf.org > > > > >> Subject: RE: Proposed WG Draft -=20 > > draft-gmpls-ethernet-arch-00.txt > > > > >> > > > > >> Dimitri....see if this helps...in-line > > > > >> > > > > >>> -----Original Message----- > > > > >>> From: owner-ccamp@ops.ietf.org=20 > > [mailto:owner-ccamp@ops.ietf.org]=20 > > > > >>> On Behalf Of > > > > PAPADIMITRIOU Dimitri > > > > >>> Sent: 25 January 2008 11:36 > > > > >>> To: Niven-jenkins,B,Ben,DMF R; Lou Berger > > > > >>> Cc: Don Fedyk; BRUNGARD, DEBORAH A, ATTLABS;=20 > > ccamp@ops.ietf.org > > > > >>> Subject: RE: Proposed WG Draft - > > > draft-gmpls-ethernet-arch-00.txt > > > > >>> > > > > >>> > > > > >>> ben > > > > >>> > > > > >>>> -----Original Message----- > > > > >>>> From: Ben Niven-Jenkins=20 > > [mailto:benjamin.niven-jenkins@bt.com] > > > > >>>> Sent: Thursday, January 24, 2008 3:40 PM > > > > >>>> To: PAPADIMITRIOU Dimitri; Lou Berger > > > > >>>> Cc: Don Fedyk; BRUNGARD, DEBORAH A, ATTLABS;=20 > > ccamp@ops.ietf.org > > > > >>>> Subject: Re: Proposed WG Draft - > > > draft-gmpls-ethernet-arch-00.txt > > > > >>>> > > > > >>>> Dimitri, > > > > >>>> > > > > >>>> I find your mail somewhat puzzling. > > > > >>>> > > > > >>>> You appear to be saying that GMPLS as per RFC 3945 is set > > > > >>> in stone and > > > > >>>> nothing should modify/enhance the behaviour as specified > > > > >> in RFC3945 > > > > >>>> which implies that when RFC3945 was produced the crystal > > > > ball was > > > > >>>> working extremely well and all possible future > > > > applications of the > > > > >>>> technology had > > > > >>>> been correctly envisaged. I don't believe that=20 > was the case. > > > > >>> this is not what i say. i am concerned in stating > > > beforehand RFC > > > > >>> 3945 (GMPLS Arch.) is not applicable to Ethernet.=20 > Why the doc. > > > > >>> does not deliver any tangible explanation. > > > > >> NH=3D> Is your problem that you cannot differentiate=20 > > between the 3 > > > > >> network modes (of co-cs, co-ps and cl-ps)? > > > > >=20 > > > > > my concern wrt specific point you bring is that the today > > > > definition in > > > > > RFC 3945 for L2SC, and in the present case GMPLS for > > > Ethernet (with > > > > > local labels or domain-wide labels or any other equivalent > > > > to "co-ps") > > > > > does not result into a different definition than what's in. > > > > on the other > > > > > side, i do not see how would apply GMPLS for > > > connectionless/bridged > > > > > Ethernet. > > > > >=20 > > > > > note also that GMPLS induces label from the interface and link > > > > > characteristic (i.e. there is no "label type" in the > > > > label/label request > > > > > object. > > > > >=20 > > > > >> If so then looking at the work on > > > > >> unified modelling in SG15/Q12 may help you. But to=20 > give a more > > > > >> specific example here: We can take an Ethernet=20 > > traffic unit and=20 > > > > >> create either a cl-ps and co-ps layer network based on=20 > > this...in=20 > > > > >> fact one > > > > can image 3 > > > > >> different layer network cases here: > > > > >> - traditional Etherent which does not have a=20 > > > directed routing > > > > >> function, ie uses MAC learning, broadcast unknown, > > > STP...this is a > > > > >> cl-ps layer network > > > > >> - Ethernet with an IGP providing a directed routing > > > > >> function....this is also a cl-ps layer network, but it is > > > > different to > > > > >> the one above > > > > >> - Ethernet with a directed routing component=20 > > > (centralised or > > > > >> distributed, ie IGP) and a signalling component that=20 > can create > > > > >> connections....this would be a co-ps layer network. > > > > >> > > > > >> These are all based on a similar traffic unit, however > > > they form 3 > > > > >> quite different layer networks (and in functional=20 > architecture > > > > >> terms we would say 'the Characteristic Information is=20 > > > different in > > > > >> the 3 cases'). > > > > >> > > > > >> Now GMPLS is applying a reusable set of CP components > > > > (which is a very > > > > >> good thing, as Ben points out below) for any co-cs or > > > > co-ps mode layer > > > > >> network. So we are setting up *connections* in=20 > either a space, > > > > >> freq or time dimension of resource, and it is these=20 > 3 resource > > > > dimensions that > > > > >> create the differences in parameters...however, the=20 > notion of a > > > > >> connection is common across all these resource dimensions. > > > > GMPLS does > > > > >> not apply to the cl-ps mode, as it plainly does not have > > > > connections. > > > > >=20 > > > > > well indeed, and this is the reason why i do not see any > > > reason to > > > > > open the space for a different set of mechanisms that > > > would result > > > > > from this new interface switching definition. > > > > >=20 > > > > > thanks, > > > > > -d. > > > > > =20 > > > > >> That is at least how I look at this issue. > > > > >> > > > > >> regards, Neil > > > > >>>>> the question triggered by this poll is the following: if > > > > >>> GMPLS for > > > > >>>>> Ethernet is not inline with the existing stacks what is > > > > >>> the value of > > > > >>>>> GMPLS re-use ? what's the value to borrow the term GMPLS > > > > >>> without its > > > > >>>>> substance ? and in practice, the issue is, if it is not > > > > >>>> GMPLS per RFC > > > > >>>>> 3945, what's the value compared to any other=20 > native control > > > > >>>> stack that > > > > >>>>> would be developed at IEEE for inst. for these techno's. > > > > >>>> If we ignore the peer model (which is unworkable in > > > reality IMO), > > >=20 > > > > >>>> the value is obvious - significant reuse of existing code, > > > > >>>> techniques, knowledge, skills, etc. > > > > >>>> > > > > >>>> So, we should develop the control plane from scratch > > > > >>> because Ethernet > > > > >>>> requires a few modifications/enhancements (which I=20 > > believe are > > > > >>>> backwards > > > > >>>> compatible) to RFC3945 - that IMO is ridiculous. > > > > >>> so you seem to agree with me. departing from RFC 3945 > > > makes little > > >=20 > > > > >>> sense. it would have been interesting to see the doc > > > delivering a > > > > >>> FIT of the GMPLS protocol arch. blocks and, in > > > particular, label > > > > >>> allocation and distribution for Ethernet. > > > > >>> > > > > >>> thanks, > > > > >>> -dimitri. > > > > >>>> Ben > > > > >>>> > > > > >>>> > > > > >>> > > > > >=20 > > > > >=20 > > > > >=20 > > > >=20 > > > >=20 > > > > -- > > > > Loa Andersson > > > >=20 > > > > Principal Networking Architect > > > > Acreo AB phone: +46 8 632 77 14 > > > > Isafjordsgatan 22 mobile: +46 739 81 21 64 > > > > Kista, Sweden email: =20 > loa.andersson@acreo.se > > > > loa@pi.se > > > >=20 > > >=20 > > >=20 > >=20 >=20 From CasandraneaterDelong@vrzhu.com Wed Jan 30 19:23:48 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKNDY-0002uB-Fp; Wed, 30 Jan 2008 19:23:48 -0500 Received: from [85.105.239.177] (helo=murib) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JKNDX-00077L-Sn; Wed, 30 Jan 2008 19:23:48 -0500 Received: from scabrous by vrzhu.com with SMTP id RpFz9oVl1k for ; Thu, 31 Jan 2008 02:23:30 -0200 From: "Angelita Lim" To: , Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKRTF-0001pX-PJ for ccamp-archive@ietf.org; Wed, 30 Jan 2008 23:56:17 -0500 Received: from [58.41.167.246] (helo=[58.41.167.246]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JKRTF-0004iW-4C for ccamp-archive@ietf.org; Wed, 30 Jan 2008 23:56:17 -0500 Message-ID: <000901c863c5$9dad5a30$f6a7293a@xc0eb422a4f8ab> From: "HBM Kattainen" To: ccamp-archive@ietf.org Subject: Make her dreams come true when she sees that you now have a HUGE tool in your pants Date: Thu, 31 Jan 2008 12:56:18 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--------=_NextPart_000_0005_01C86408.ABD09A30" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 ----------=_NextPart_000_0005_01C86408.ABD09A30 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable It used to be the only way she could come was if I went down on her. = Thanks to my new 9 inch tool, she now comes everytime we make love ----------=_NextPart_000_0005_01C86408.ABD09A30 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable It used to be the only way she = could come was=20 if I went down on her. Thanks to my new 9 inch tool, she now comes = everytime we=20 make love ----------=_NextPart_000_0005_01C86408.ABD09A30-- From debra@ocsinfotech.com Thu Jan 31 02:30:19 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKTsJ-00058J-4F for ccamp-archive@ietf.org; Thu, 31 Jan 2008 02:30:19 -0500 Received: from [203.187.136.147] (helo=sdpgsdcds147.us.infonet.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JKTsI-0007vM-AJ for ccamp-archive@ietf.org; Thu, 31 Jan 2008 02:30:18 -0500 Received: (qmail 22107 invoked from network); Thu, 31 Jan 2008 13:00:16 +0530 Received: from unknown (HELO octgk) (142.172.218.76) by sdpgsdcds147.us.infonet.com with SMTP; Thu, 31 Jan 2008 13:00:16 +0530 Message-ID: <47A17908.8060704@ocsinfotech.com> Date: Thu, 31 Jan 2008 13:00:16 +0530 From: User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: ccamp-archive@ietf.org Subject: I Dream of you Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 Hugging My Pillow http://221.127.151.140/ From MorrisHodge@interbiz.ru Thu Jan 31 02:47:42 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKU98-0001iW-U4 for ccamp-archive@ietf.org; Thu, 31 Jan 2008 02:47:42 -0500 Received: from [78.146.177.133] (helo=[78.146.177.133]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JKU98-0008II-7O for ccamp-archive@ietf.org; Thu, 31 Jan 2008 02:47:42 -0500 Received: by 10.141.114.65 with SMTP id EhERgccgUXRCM; Thu, 31 Jan 2008 07:47:47 -0000 (GMT) Received: by 192.168.22.186 with SMTP id cljYebPTCCwhYJ.0977094193847; Thu, 31 Jan 2008 07:47:45 -0000 (GMT) Message-ID: <000a01c863dd$8f9afac0$85b1924e@paul> From: "Morris Hodge" To: Subject: rulerrob Date: Thu, 31 Jan 2008 07:47:42 -0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01C863DD.8F9AFAC0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 ------=_NextPart_000_0003_01C863DD.8F9AFAC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Night ccamp-archive Sensational Hardness and Firmness; http://sheettrade.com Morris Hodge ------=_NextPart_000_0003_01C863DD.8F9AFAC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Night ccamp-archive
Sensational Hardness and Firmness;
http://sheettrade.com
Morris Hodge
------=_NextPart_000_0003_01C863DD.8F9AFAC0-- From RichieoerHaney@themedboulder.com Thu Jan 31 03:48:13 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKV5h-0001uF-GD; Thu, 31 Jan 2008 03:48:13 -0500 Received: from [89.152.151.2] (helo=acercbb9a4757d.netcabo.pt) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JKV5h-0000yb-1a; Thu, 31 Jan 2008 03:48:13 -0500 Received: from croydon by themedboulder.com with SMTP id Lw3IjndFeA for ; Thu, 31 Jan 2008 08:48:01 +0000 From: "Jonah Haney" To: Subject: Our casino is for you who likes to win! Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de We're serious about fun. Our casino is for you and everyone else who likes to win! When YOU WIN, we win! Players from the United States and around the world! http://docthis.cn/ From owner-ccamp@ops.ietf.org Thu Jan 31 05:50:44 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKX0G-00062k-8O for ccamp-archive@ietf.org; Thu, 31 Jan 2008 05:50:44 -0500 Received: from psg.com ([2001:418:1::62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JKX0D-0008LX-L6 for ccamp-archive@ietf.org; Thu, 31 Jan 2008 05:50:44 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JKWmV-000PEx-Jn for ccamp-data@psg.com; Thu, 31 Jan 2008 10:36:31 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [217.32.164.138] (helo=smtp3.smtp.bt.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JKWmQ-000PEV-VX for ccamp@ops.ietf.org; Thu, 31 Jan 2008 10:36:29 +0000 Received: from E03MVB2-UKBR.domain1.systemhost.net ([193.113.197.108]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 Jan 2008 10:36:25 +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: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Date: Thu, 31 Jan 2008 10:35:49 -0000 Message-ID: <2ECAA42C79676B42AEBAC11229CA7D0C01D428DA@E03MVB2-UKBR.domain1.systemhost.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Thread-Index: Achid4JetInOIvLXS36xGBjOv4vCdwAOqlZgAB8MVpAADGxFgAACaWoQAADUPSAAIOuXAA== From: To: , , Cc: , , , , X-OriginalArrivalTime: 31 Jan 2008 10:36:25.0134 (UTC) FILETIME=[20F84CE0:01C863F5] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -1.0 (-) X-Scan-Signature: c07eeb7900970a16fe4056cc74ae9ce2 Thanks Dimitri, You asked a question below...which I have extracted/inserted below for ease of reference: > The > co-ps mode has the richest scope for 'variation' in the DP=20 > labelling of > traffic units (this is more than simply a destination proxy label > BTW....this was a point I saw Adrian alluding to)....and one can even > violate the rules of connections here and really screw-up any=20 > notion of deterministic resource management anyway. does that imply change in the def. of L2SC as defined in RFC 3945 ? or is it an add-on that is not impacting other RFC's mechanisms ? my understanding is the latter but never got an answer whether or not this is indeed the case (and proposal on how to spell this in the doc.) NH=3D> I assume you are referring to the definition of a connection (wrt to what L2Sc really means)? A connection can only have a single source and it must not re-order traffic units...a subtle corollary of this is that a connection can only have a single traffic/QoS class. This means connections can only be p2p or p2mp in construction. This is a necessary requirement for resource assignment determinism. Assuming one does not violate these rules (and you can't in the co-cs mode) then there is no need to include a SA label in the traffic units of a connection....the parent connection object carries that semantic. Further, because a connection represents a chosen set of link connections (hops) between the source and the sink(s)then: - in the case of a p2p connection the label carrying the DA information need only be link connection unique (across the population of clients served by the lower layer network connection on that link), ie it can be swapped hop by hop - in the case of a p2mp connection the label carrying the DA is a 'name' (proxy) that respresents a set of real DAs. These labelling short-cuts is all works fine until there are misconnectivity defects. But if one wants to make the network more robust to such defects (without even using any adjunct OAM flows at all) then including the SA in each traffic unit and not-swapping the DA in the case of p2p connections (ie just use the real DA and not a proxy for it) has many benefits. Now if you start with a traffic unit that was originally designed for cl-ps operation and use it for a co-ps operation then the above labelling information is already present, ie one has no need to take short-cuts on removing the SA or making the DA only link connection unique....the cl-ps mode cannot allow such short-cuts as there is no connection that provides this information. Now if one chooses to create mp2p merging constructs and there is also no SA information then you have lost information on where the traffic unit came from.....and this lost information must be provided by some other means (usually an appeal to a higher layer entity =3D> which if cl-ps (eg IP) allows SA recovery directly or if not cl-ps (eg ATM, etc) requires a further label is added to provide this information, eg PW label in MPLS). But this is only dealing with the loss of SA information caused by merging....we still have the issue that merging constructs cannot have deterministic resource allocation. I'm not sure that answers your question, because it assumes the above is understood (implicit?) in the definition of what L2SC really means....I suspect the above considerations have not really been taken into account. regards, Neil > -----Original Message----- > From: PAPADIMITRIOU Dimitri=20 > [mailto:Dimitri.Papadimitriou@alcatel-lucent.be]=20 > Sent: 30 January 2008 23:40 > To: Harrison,N,Neil,DMF R; howard.green@ericsson.com; loa@pi.se > Cc: Niven-jenkins,B,Ben,DMF R; lberger@labn.net;=20 > dwfedyk@nortel.com; dbrungard@att.com; ccamp@ops.ietf.org > Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt >=20 >=20 > =20 > neil,=20 >=20 > > -----Original Message----- > > From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] > > Sent: Wednesday, January 30, 2008 7:14 PM > > To: PAPADIMITRIOU Dimitri; howard.green@ericsson.com; loa@pi.se > > Cc: benjamin.niven-jenkins@bt.com; lberger@labn.net;=20 > > dwfedyk@nortel.com; dbrungard@att.com; ccamp@ops.ietf.org > > Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt > >=20 > > I personally think you are making a mountain out of a molehill here=20 > > Dimitri. >=20 > the segmentation of SCs we have in RFC 3945 is sufficient to=20 > address your below decomposition. you have to consider that=20 > when a new techno is to be supported by GMPLS, stacks are not=20 > going to change the full engine/stack per specific technology - >=20 > > And I thought I had explained why there are differences in the=20 > > treatment of layer networks depending on their mode...I=20 > clearly did a=20 > > bad job. >=20 > don't worry, we very well understand the difference between a=20 > circuit-switched and packet-switched network.=20 >=20 > > Sure GMPLS is a generic OOB CP suite of protocols, but the=20 > details of=20 > > the parameters used used to describe the layer network being > > considered will depend on: > > - for the co-cs mode whether we are dealing with resources which > > are either regular time-slices, freq or space > > - for the co-ps mode there is only irregular time-slices. >=20 > L2SC is in the latter. > =20 > > And the labelling of such resource partitions is different in > > each case > > too...so just like it is impossible to have a common (ie=20 > > single instance > > of) CP running 'IP to Optics' (or any functional component for that > > matter) it is impossible to have an identical set of parameters > > describing each mode....this is just the physics and the way=20 > > it is. The > > co-ps mode has the richest scope for 'variation' in the DP=20 > > labelling of > > traffic units (this is more than simply a destination proxy label > > BTW....this was a point I saw Adrian alluding to)....and=20 > one can even > > violate the rules of connections here and really screw-up any=20 > > notion of deterministic resource management anyway. >=20 > does that imply change in the def. of L2SC as defined in RFC=20 > 3945 ? or is it an add-on that is not impacting other RFC's=20 > mechanisms ? my understanding is the latter but never got an=20 > answer whether or not this is indeed the case (and proposal=20 > on how to spell this in the doc.) >=20 > the addition to adrian's text is a way out. it is to be=20 > followed by discussions because the protocol aspects remain open.=20 >=20 > thanks, > -d. >=20 > > regards, Neil > >=20 > > > -----Original Message----- > > > From: PAPADIMITRIOU Dimitri > > > [mailto:Dimitri.Papadimitriou@alcatel-lucent.be]=20 > > > Sent: 30 January 2008 17:23 > > > To: Howard Green; Loa Andersson > > > Cc: Harrison,N,Neil,DMF R; Niven-jenkins,B,Ben,DMF R;=20 > > > lberger@labn.net; dwfedyk@nortel.com; dbrungard@att.com;=20 > > > ccamp@ops.ietf.org > > > Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt > > >=20 > > >=20 > > > =20 > > >=20 > > > > -----Original Message----- > > > > From: Howard Green [mailto:howard.green@ericsson.com] > > > > Sent: Wednesday, January 30, 2008 12:09 PM > > > > To: PAPADIMITRIOU Dimitri; Loa Andersson > > > > Cc: neil.2.harrison@bt.com; benjamin.niven-jenkins@bt.com; > > > > lberger@labn.net; dwfedyk@nortel.com; dbrungard@att.com;=20 > > > > ccamp@ops.ietf.org > > > > Subject: RE: Proposed WG Draft -=20 > draft-gmpls-ethernet-arch-00.txt > > > >=20 > > > > Hi > > > > Dimitri seems to me to be making a very abstract and > > > legalistic point. > > >=20 > > > receive my total disagreement. an individual submission that > > > asks to change an existing RFC requires discussion and=20 > > > particular attention (in part., when it is the protocol arch.=20 > > > document) - if this not possible then probably you have to=20 > > > write also a doc. asking for changing the IETF proces - and=20 > > > then you come back with your individual submission. > > > =20 > > > > The reason why this work is important is that the IEEE has been=20 > > > > evolving Ethernet to give it carrier class features, in=20 > respect of > > > scalability, > > > > OAM, and (with 802.1Qay) the possibility to use an > > external control > > > > plane. > > >=20 > > > no one i think question this. and i don't think the poll is > > > on this specific point. CCAMP or even IETF at large is not an=20 > > > authority to decide upon IEEE technos. > > >=20 > > > > Some of these features will very likely require or enable > > > added value > > > > from extensions to the functionality of GMPLS - for > > example, as has > > > > already been suggested, the addition of functionality > > for creating > > > > the OAM associations. > > >=20 > > > indeed, and your colleague has already received a list of > > > comments to be addressed before seeing any way forward w/ the=20 > > > proposed approach.=20 > > >=20 > > > > Therefore this will likely not be the same as the possible use=20 > > > > suggested in RFC3945, which may (at least in theory) have been=20 > > > > implemented somewhere. > > >=20 > > > the exact problem, i mentionned a couple of times. your own > > > comment shows that one may use GMPLS differently but may i=20 > > > ask WHY ? and what's the implications ? > > >=20 > > > > Therefore the suggestion in the draft seems to make sense. > > >=20 > > > why ? > > >=20 > > > > I can't really see what important principle is being=20 > defended by=20 > > > > the insistence upon L2SC, which, as Don Fedyk > > > stated, was > > > > always somewhat underspecified. > > >=20 > > > THE reason is that an interface SC or a related functionality > > > has never resulted in a specific change in the base protocol=20 > > > building blocks. GMPLS is a generalized approach not a=20 > > > differentiated approach per interface. > > >=20 > > > actually your last statement is not correct (L2SC is well > > > specified in RFC 3945) AND by the way yours does not at all=20 > > > better specify it. > > >=20 > > > > This is not something to be debated in the abstract. The > > > work in ccamp > > > > should allow sensible extension of functionality where it > > > adds value, > > > > and this needs to be discussed on a case by case basis. > > > Therefore we > > > > should make it a working group document and get on with it. > > >=20 > > > -d. > > > > regards Howard Green > > > >=20 > > > > -----Original Message----- > > > > From: owner-ccamp@ops.ietf.org > > [mailto:owner-ccamp@ops.ietf.org] On > > > > Behalf Of PAPADIMITRIOU Dimitri > > > > Sent: 30 January 2008 10:15 > > > > To: Loa Andersson > > > > Cc: neil.2.harrison@bt.com; benjamin.niven-jenkins@bt.com; > > > > lberger@labn.net; dwfedyk@nortel.com; dbrungard@att.com;=20 > > > > ccamp@ops.ietf.org > > > > Subject: RE: Proposed WG Draft -=20 > draft-gmpls-ethernet-arch-00.txt > > > >=20 > > > > loa, > > > >=20 > > > >=20 > > > > i think the main point as ccamp is whether or not we poll > > > for a change > > > > or a continuation inline with RFC3945 -- when the present > > > doc. states: > > > >=20 > > > > "It is expected that there will be no > > > > case where an Eth-LSP will be signaled, or an Eth-LSP > > supporting > > > > interface will be represented, using the L2SC switching > > > > type/capability. A new switching type/capability is > > required to > > > > avoid any potential current usage of the L2SC switching > > > > type/capability in support of Ethernet. > > > >=20 > > > > [...] > > > >=20 > > > > "The L2SC Interface Switching Capabilities MUST > > > > NOT be used to represent interfaces capable of supporting=20 > > > > Eth-LSPs." > > > >=20 > > > > it raises three issues: > > > >=20 > > > > a) what was the previous L2SC def. per RFC 3945 meant=20 > for if not=20 > > > > for use also in GMPLS Ethernet context ? > > > >=20 > > > > b) why a "new one" ? > > > >=20 > > > > this is not explained. > > > >=20 > > > > c) what is the "new one" implying in terms of GMPLS ? > > > >=20 > > > > for inst. in the intro "The intent of this document is to > > reuse and > > > > align with as much of the GMPLS protocols as possible." > > leaves open > > > > the issue of what as much as possible means. > > > >=20 > > > > and on the other "Additions are made only to accommodate > > > features of > > > > Ethernet that are not already supported by GMPLS." so, > > how shall i > > > > interpreet the first sentence now ? inline with point=20 > a) and b) ? > > > >=20 > > > >=20 > > > > the doc. in WG I-D status or not is not going to provide an > > > answer to > > > > these questions. sentences and statements in the doc. > > > contradict each > > > > other. > > > >=20 > > > > thanks, > > > > -d. > > > >=20 > > > >=20 > > > >=20 > > > >=20 > > > >=20 > > > > > -----Original Message----- > > > > > From: Loa Andersson [mailto:loa@pi.se] > > > > > Sent: Tuesday, January 29, 2008 2:04 PM > > > > > To: PAPADIMITRIOU Dimitri > > > > > Cc: neil.2.harrison@bt.com; benjamin.niven-jenkins@bt.com;=20 > > > > > lberger@labn.net; dwfedyk@nortel.com; dbrungard@att.com;=20 > > > > > ccamp@ops.ietf.org > > > > > Subject: Re: Proposed WG Draft - > > draft-gmpls-ethernet-arch-00.txt > > > > >=20 > > > > > Dimitri, > > > > >=20 > > > > > it is possible that you have a point that needs to be > > > > discussed, but > > > > > is this really something that should stop us from adopting > > > > the doc as > > > > > a working group document. > > > > >=20 > > > > > /Loa > > > > >=20 > > > > > PAPADIMITRIOU Dimitri wrote: > > > > > > neil, > > > > > >=20 > > > > > >> -----Original Message----- > > > > > >> From: neil.2.harrison@bt.com=20 > [mailto:neil.2.harrison@bt.com] > > > > > >> Sent: Friday, January 25, 2008 2:27 PM > > > > > >> To: PAPADIMITRIOU Dimitri; benjamin.niven-jenkins@bt.com;=20 > > > > > >> lberger@labn.net > > > > > >> Cc: dwfedyk@nortel.com; dbrungard@att.com;=20 > ccamp@ops.ietf.org > > > > > >> Subject: RE: Proposed WG Draft - > > > draft-gmpls-ethernet-arch-00.txt > > > > > >> > > > > > >> Dimitri....see if this helps...in-line > > > > > >> > > > > > >>> -----Original Message----- > > > > > >>> From: owner-ccamp@ops.ietf.org > > > [mailto:owner-ccamp@ops.ietf.org] > > > > > >>> On Behalf Of > > > > > PAPADIMITRIOU Dimitri > > > > > >>> Sent: 25 January 2008 11:36 > > > > > >>> To: Niven-jenkins,B,Ben,DMF R; Lou Berger > > > > > >>> Cc: Don Fedyk; BRUNGARD, DEBORAH A, ATTLABS; > > > ccamp@ops.ietf.org > > > > > >>> Subject: RE: Proposed WG Draft - > > > > draft-gmpls-ethernet-arch-00.txt > > > > > >>> > > > > > >>> > > > > > >>> ben > > > > > >>> > > > > > >>>> -----Original Message----- > > > > > >>>> From: Ben Niven-Jenkins > > > [mailto:benjamin.niven-jenkins@bt.com] > > > > > >>>> Sent: Thursday, January 24, 2008 3:40 PM > > > > > >>>> To: PAPADIMITRIOU Dimitri; Lou Berger > > > > > >>>> Cc: Don Fedyk; BRUNGARD, DEBORAH A, ATTLABS; > > > ccamp@ops.ietf.org > > > > > >>>> Subject: Re: Proposed WG Draft - > > > > draft-gmpls-ethernet-arch-00.txt > > > > > >>>> > > > > > >>>> Dimitri, > > > > > >>>> > > > > > >>>> I find your mail somewhat puzzling. > > > > > >>>> > > > > > >>>> You appear to be saying that GMPLS as per RFC 3945 is set > > > > > >>> in stone and > > > > > >>>> nothing should modify/enhance the behaviour as specified > > > > > >> in RFC3945 > > > > > >>>> which implies that when RFC3945 was produced the crystal > > > > > ball was > > > > > >>>> working extremely well and all possible future > > > > > applications of the > > > > > >>>> technology had > > > > > >>>> been correctly envisaged. I don't believe that > > was the case. > > > > > >>> this is not what i say. i am concerned in stating > > > > beforehand RFC > > > > > >>> 3945 (GMPLS Arch.) is not applicable to Ethernet. > > Why the doc. > > > > > >>> does not deliver any tangible explanation. > > > > > >> NH=3D> Is your problem that you cannot differentiate > > > between the 3 > > > > > >> network modes (of co-cs, co-ps and cl-ps)? > > > > > >=20 > > > > > > my concern wrt specific point you bring is that the today > > > > > definition in > > > > > > RFC 3945 for L2SC, and in the present case GMPLS for > > > > Ethernet (with > > > > > > local labels or domain-wide labels or any other equivalent > > > > > to "co-ps") > > > > > > does not result into a different definition than what's in. > > > > > on the other > > > > > > side, i do not see how would apply GMPLS for > > > > connectionless/bridged > > > > > > Ethernet. > > > > > >=20 > > > > > > note also that GMPLS induces label from the=20 > interface and link=20 > > > > > > characteristic (i.e. there is no "label type" in the > > > > > label/label request > > > > > > object. > > > > > >=20 > > > > > >> If so then looking at the work on > > > > > >> unified modelling in SG15/Q12 may help you. But to > > give a more > > > > > >> specific example here: We can take an Ethernet > > > traffic unit and > > > > > >> create either a cl-ps and co-ps layer network based on > > > this...in > > > > > >> fact one > > > > > can image 3 > > > > > >> different layer network cases here: > > > > > >> - traditional Etherent which does not have a=20 > > > > directed routing > > > > > >> function, ie uses MAC learning, broadcast unknown, > > > > STP...this is a > > > > > >> cl-ps layer network > > > > > >> - Ethernet with an IGP providing a directed routing > > > > > >> function....this is also a cl-ps layer network, but it is > > > > > different to > > > > > >> the one above > > > > > >> - Ethernet with a directed routing component=20 > > > > (centralised or > > > > > >> distributed, ie IGP) and a signalling component that > > can create > > > > > >> connections....this would be a co-ps layer network. > > > > > >> > > > > > >> These are all based on a similar traffic unit, however > > > > they form 3 > > > > > >> quite different layer networks (and in functional > > architecture > > > > > >> terms we would say 'the Characteristic Information is > > > > different in > > > > > >> the 3 cases'). > > > > > >> > > > > > >> Now GMPLS is applying a reusable set of CP components > > > > > (which is a very > > > > > >> good thing, as Ben points out below) for any co-cs or > > > > > co-ps mode layer > > > > > >> network. So we are setting up *connections* in > > either a space, > > > > > >> freq or time dimension of resource, and it is these > > 3 resource > > > > > dimensions that > > > > > >> create the differences in parameters...however, the > > notion of a > > > > > >> connection is common across all these resource dimensions. > > > > > GMPLS does > > > > > >> not apply to the cl-ps mode, as it plainly does not have > > > > > connections. > > > > > >=20 > > > > > > well indeed, and this is the reason why i do not see any > > > > reason to > > > > > > open the space for a different set of mechanisms that > > > > would result > > > > > > from this new interface switching definition. > > > > > >=20 > > > > > > thanks, > > > > > > -d. > > > > > > =20 > > > > > >> That is at least how I look at this issue. > > > > > >> > > > > > >> regards, Neil > > > > > >>>>> the question triggered by this poll is the following: if > > > > > >>> GMPLS for > > > > > >>>>> Ethernet is not inline with the existing stacks what is > > > > > >>> the value of > > > > > >>>>> GMPLS re-use ? what's the value to borrow the term GMPLS > > > > > >>> without its > > > > > >>>>> substance ? and in practice, the issue is, if it is not > > > > > >>>> GMPLS per RFC > > > > > >>>>> 3945, what's the value compared to any other > > native control > > > > > >>>> stack that > > > > > >>>>> would be developed at IEEE for inst. for these techno's. > > > > > >>>> If we ignore the peer model (which is unworkable in > > > > reality IMO), > > > >=20 > > > > > >>>> the value is obvious - significant reuse of=20 > existing code,=20 > > > > > >>>> techniques, knowledge, skills, etc. > > > > > >>>> > > > > > >>>> So, we should develop the control plane from scratch > > > > > >>> because Ethernet > > > > > >>>> requires a few modifications/enhancements (which I > > > believe are > > > > > >>>> backwards > > > > > >>>> compatible) to RFC3945 - that IMO is ridiculous. > > > > > >>> so you seem to agree with me. departing from RFC 3945 > > > > makes little > > > >=20 > > > > > >>> sense. it would have been interesting to see the doc > > > > delivering a > > > > > >>> FIT of the GMPLS protocol arch. blocks and, in > > > > particular, label > > > > > >>> allocation and distribution for Ethernet. > > > > > >>> > > > > > >>> thanks, > > > > > >>> -dimitri. > > > > > >>>> Ben > > > > > >>>> > > > > > >>>> > > > > > >>> > > > > > >=20 > > > > > >=20 > > > > > >=20 > > > > >=20 > > > > >=20 > > > > > -- > > > > > Loa Andersson > > > > >=20 > > > > > Principal Networking Architect > > > > > Acreo AB phone: +46 8 632 77 14 > > > > > Isafjordsgatan 22 mobile: +46 739 81 21 64 > > > > > Kista, Sweden email: =20 > > loa.andersson@acreo.se > > > > > loa@pi.se > > > > >=20 > > > >=20 > > > >=20 > > >=20 > >=20 >=20 From owner-ccamp@ops.ietf.org Thu Jan 31 06:01:49 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKXAz-0001a8-3I for ccamp-archive@ietf.org; Thu, 31 Jan 2008 06:01:49 -0500 Received: from psg.com ([2001:418:1::62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JKXAx-000054-75 for ccamp-archive@ietf.org; Thu, 31 Jan 2008 06:01:49 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JKX3I-0000yZ-2U for ccamp-data@psg.com; Thu, 31 Jan 2008 10:53:52 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE, STOX_REPLY_TYPE autolearn=no version=3.2.3 Received: from [62.128.201.248] (helo=asmtp1.iomartmail.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JKX3E-0000xr-RJ for ccamp@ops.ietf.org; Thu, 31 Jan 2008 10:53:50 +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 m0VArbJh010944; Thu, 31 Jan 2008 10:53:38 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 m0VArT3x010844; Thu, 31 Jan 2008 10:53:37 GMT Message-ID: <106201c863f7$8154f640$0200a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Ong, Lyndon" , Cc: "Dimitri Papadimitriou" References: <23F9E58A916663488B3D12D1FE1A999FD0E447@mdmxm03.ciena.com> Subject: Re: Question on TLV Length Calculation Date: Thu, 31 Jan 2008 10:52:43 -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.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Hi Lyndon, I didn't see an answer to this on the list. Dimitri, do you have a view? > Simple question on length calculation for RSVP-TE TLVs: I've > noticed that draft-ietf-ccamp-ethernet-traffic-parameters-03.txt > has adopted a method of calculating TLV length from RFC 4420, > where the length includes only the value portion of the TLV, and > does not include the header (type and length bytes) or any padding > bytes. > > This is a bit different from how length is computed for objects and > sub-objects, where length includes header as well. Having not > followed the discussion on RFC 4420 closely, can someone clarify: > > -- is this method of length calculation to be followed on all new > TLVs defined for RSVP-TE? > > -- if not, is there some basis for deciding what calculation to follow > when defining a new TLV? More important than the object and subobject length calculations, are the TLV length calculations defined in RFC 3471 where we have... Length: 16 bits Indicates the total length of the TLV, i.e., 4 + the length of the value field in octets. A value field whose length is not a multiple of four MUST be zero-padded so that the TLV is four- octet aligned. I would say that we should aim for consistency and that RFC 4420 was a mistake (mea culpa) caused by mirroring the capabilities advertisement features from a similar draft in the OSPF working group (OSPF TLVs use L = value length). Consistency means following 3471 where possible (note that we can't go back and fix 4420 because it is deployed). So the questions for Dimitri with draft-ietf-ccamp-ethernet-traffic-parameters-03.txt are: - is there a reason to diverge from 3471? - is it too late to fix this? Thanks, Adrian From bluemountain@go4webservices.com Thu Jan 31 06:20:04 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKXSe-0000Bx-Ks for ccamp-archive@ietf.org; Thu, 31 Jan 2008 06:20:04 -0500 Received: from [92.80.217.44] (helo=abcix) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JKXSe-0004qq-0x for ccamp-archive@ietf.org; Thu, 31 Jan 2008 06:20:04 -0500 Received: from bgdw ([101.150.180.135]) by abcix with Microsoft SMTPSVC(6.0.3790.0); Thu, 31 Jan 2008 13:20:09 +0200 Message-ID: <47A1AEE9.3070208@go4webservices.com> Date: Thu, 31 Jan 2008 13:20:09 +0200 From: User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: ccamp-archive@ietf.org Subject: Gigantic results guaranteed! Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.3 (+) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 Pending meds on your way! http://82.38.55.46/ijrxuo/ From piland1970@alchemistpiano.com Thu Jan 31 09:47:59 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKahr-0006g0-D9 for ccamp-archive@ietf.org; Thu, 31 Jan 2008 09:47:59 -0500 Received: from dyn-91-171-27-33.ppp.tiscali.fr ([91.171.27.33]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JKahq-0005Ms-GG for ccamp-archive@ietf.org; Thu, 31 Jan 2008 09:47:58 -0500 Message-ID: <000d01c86418$3c080390$211bab5b@107293410315> From: "gheorghe Redander" To: ccamp-archive@ietf.org Subject: Be the talk of the town with your new huge schl0ng Date: Thu, 31 Jan 2008 15:47:42 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--------=_NextPart_000_0009_01C86420.9DCC6B90" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 3.5 (+++) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 ----------=_NextPart_000_0009_01C86420.9DCC6B90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Evenings alone are a thing of the past with your brand new huge d1ck ----------=_NextPart_000_0009_01C86420.9DCC6B90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Evenings alone are a thing of the = past with=20 your brand new huge d1ck ----------=_NextPart_000_0009_01C86420.9DCC6B90-- From moaningly@rrabun.com Thu Jan 31 10:10:15 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKb3P-00028o-DR for ccamp-archive@ietf.org; Thu, 31 Jan 2008 10:10:15 -0500 Received: from e157188.upc-e.chello.nl ([213.93.157.188] helo=adojgaew) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JKb3O-0005xy-UH for ccamp-archive@ietf.org; Thu, 31 Jan 2008 10:10:15 -0500 Message-ID: <000501c8641a$2e5f8b80$0100007f@wqmhq> From: "Michelle Hernandez" To: Subject: Ado6e Master Sui+e for XP|Vls+a 299, Retail 2499 (save 2199) Date: Thu, 31 Jan 2008 16:10:12 +0100 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 12.0.4210 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Score: 0.1 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c discreet combustion 4.0 for windows - 69 crystal reports professional edition 11 - 69 adobe illustrator cs3 - 69 microsoft sql server developer edition 2005 - 69 adobe indesign cs2 - 59 nero 7 premium - 39 adobe golive cs2 - 49 roxio digitalmedia studio deluxe suite 7.0 - 49 google sketchup pro 6 for mac - 59 v!slt >oemfactorysale. com< in your |nternet Explorer 444 555 6 From _cesar@ab-pr.com Thu Jan 31 10:18:06 2008 Return-path: <_cesar@ab-pr.com> Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKbB0-0001dL-3C for ccamp-archive@ietf.org; Thu, 31 Jan 2008 10:18:06 -0500 Received: from host-84-221-139-162.cust-adsl.tiscali.it ([84.221.139.162]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JKbAz-0006L9-Gp for ccamp-archive@ietf.org; Thu, 31 Jan 2008 10:18:06 -0500 Message-ID: <000701c8641c$04a904ef$f38d4e90@yvfdrrld> From: "huntington goliath" <_cesar@ab-pr.com> To: Subject: Dreams can cost less here! Date: Thu, 31 Jan 2008 13:30:42 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C8641C.04A75C74" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 3.5 (+++) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 This is a multi-part message in MIME format. ------=_NextPart_000_0004_01C8641C.04A75C74 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable THE WORLDS #1 ED TREATING BLUE PILL ------=_NextPart_000_0004_01C8641C.04A75C74 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable THE WORLDS #1 ED TREATING BLUE = PILL ------=_NextPart_000_0004_01C8641C.04A75C74-- From Gautam-essinife@absinspector.com Thu Jan 31 10:35:08 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKbRU-0003w3-KM for ccamp-archive@ietf.org; Thu, 31 Jan 2008 10:35:08 -0500 Received: from 87-126-59-130.btc-net.bg ([87.126.59.130]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JKbRU-0007Ff-0I for ccamp-archive@ietf.org; Thu, 31 Jan 2008 10:35:08 -0500 Message-ID: <001001c8641e$e051c1b0$14fd7e57@PC717031793218> From: "Gautam conway" To: ccamp-archive@ietf.org Subject: esueigno Date: Thu, 31 Jan 2008 17:35:15 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--------=_NextPart_000_000C_01C8642F.A3DA91B0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 2.1 (++) X-Scan-Signature: 93238566e09e6e262849b4f805833007 ----------=_NextPart_000_000C_01C8642F.A3DA91B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Psychological Confidence and Relief; Rapid Chemical Uptake; ----------=_NextPart_000_000C_01C8642F.A3DA91B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Psychological Confidence and = Relief;
Rapid Chemical Uptake; ----------=_NextPart_000_000C_01C8642F.A3DA91B0-- From GeorgettesacrilegeGage@podiobooks.com Thu Jan 31 11:20:27 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKc9K-00089q-Sk; Thu, 31 Jan 2008 11:20:27 -0500 Received: from [88.254.42.38] (helo=pce) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JKc9K-0008LH-6e; Thu, 31 Jan 2008 11:20:26 -0500 Message-ID: From: "Lakeisha Mock" To: , =20
THE GOLD of Small = Caps=20 LITERALLY!!

Gold & Silver = company G&S=20 Minerals ( Symbol:GSML) is on Fire

People are loading up, If = you missed=20 the move in past 2 days and thg amazing 500% plus volume spike, Don't=20 Dispair.

GSML has a price target of = 3.88 by a=20 reputed analyst firm and a Tight Float to help

The the word markets = fearing economic=20 growth, Gold is bound to shine and The company with most to gain is an=20 UNDISCOVERED GEM such as GSML

Get in GSML and reap = the=20 profits

------=_NextPart_000_BB49_01C86425.2F5CFD50-- From kagon.net@winhostdir.com Thu Jan 31 12:24:00 2008 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKd8q-0000CF-QJ for ccamp-archive@ietf.org; Thu, 31 Jan 2008 12:24:00 -0500 Received: from 190-13-169-86.bk14-ipfija.surnet.cl ([190.13.169.86] helo=ruhmmdpi) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JKd8p-000250-SC for ccamp-archive@ietf.org; Thu, 31 Jan 2008 12:24:00 -0500 Message-ID: <000301c8642e$548f2680$0100007f@hrtosbt> From: "Benjamin Green" To: Subject: FYI Date: Thu, 31 Jan 2008 14:23:57 -0500 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2905 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 1.7 (+) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 crystal xcelsius professional v4.5 - 59 mcafee desktop firewall 8.0.493 - 39 Type 'softnunow. com' in Internet Explorer (w/o spaces and quotes) sony sound forge 9.0 - 49 adobe indesign cs2 - 59 intuit quicken premier 2008 - 29 sonic scenarist 3.0 - 49 endnote x1 for mac - 59 conitec gamestudio pro a7 7.05 - 89 turbotax business 2006 (usa only) - 29 endnote x1 for mac - 59 roxio digitalmedia studio deluxe suite 7.0 - 49 microsoft vista ultimate - 89 Save up to 73-90%! From jjbeltran@wgint.com Thu Jan 31 13:04:19 2008 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JKdlr-0008FD-2f for ccamp-archive@ietf.org; Thu, 31 Jan 2008 13:04:19 -0500 Received: from [85.107.109.240] (helo=dsl85-107-28144.ttnet.net.tr) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1JKdlq-0003fl-At for ccamp-archive@ietf.org; Thu, 31 Jan 2008 13:04:19 -0500 Received: from uiglf ([43.139.55.103]) by dsl85-107-28144.ttnet.net.tr (8.13.3/8.13.3) with SMTP id m0VI8Xdk015671; Thu, 31 Jan 2008 20:08:33 +0200 Message-ID: <001101c86433$b0a06330$67378b2b@uiglf> From: To: Subject: Falling In Love with You Date: Thu, 31 Jan 2008 20:04:14 +0200 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 5.50.4029.2901 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4029.2901 X-Spam-Score: 3.6 (+++) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 Sending You My Love http://62.63.90.245/ From excommunicatedjn4@bortonoverseas.com Thu Jan 31 18:04: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 C322F28C221 for ; Thu, 31 Jan 2008 18:04:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: YES X-Spam-Score: 100.841 X-Spam-Level: **************************************************************** X-Spam-Status: Yes, score=100.841 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_DYNAMIC_IPADDR2=4.395, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_EQ_IP_ADDR=1.119, INVALID_DATE=1.245, OUTLOOK_3416=1.744, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_DSBL=0.961, RCVD_IN_XBL=3.033, RCVD_NUMERIC_HELO=2.067, RDNS_NONE=0.1, 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_SC_SURBL=10, URIBL_WS_SURBL=10] X-Spam-Report: * 3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100% * [score: 1.0000] * 3.5 HELO_DYNAMIC_SPLIT_IP Relay HELO'd using suspicious hostname (Split * IP) * 1.1 HELO_EQ_IP_ADDR HELO using IP Address (not private) * 1.5 FH_RELAY_NODNS We could not determine your Reverse DNS * 4.4 HELO_DYNAMIC_IPADDR2 Relay HELO'd using suspicious hostname (IP addr * 2) * 1.2 INVALID_DATE Invalid Date: header (not RFC 2822) * 1.7 OUTLOOK_3416 Claims to be sent by an unusual build of Outlook (3416) * 1.9 TVD_RCVD_IP TVD_RCVD_IP * 2.1 RCVD_NUMERIC_HELO Received: contains an IP address used for HELO * 2.2 TVD_SPACE_RATIO BODY: TVD_SPACE_RATIO * 1.5 RAZOR2_CF_RANGE_E8_51_100 Razor2 gives engine 8 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/) * 0.5 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50% * [cf: 100] * 20 URIBL_BLACK Contains an URL listed in the URIBL blacklist * [URIs: verybestoff.com] * 10 URIBL_AB_SURBL Contains an URL listed in the AB SURBL blocklist * [URIs: verybestoff.com] * 10 URIBL_WS_SURBL Contains an URL listed in the WS SURBL blocklist * [URIs: verybestoff.com] * 10 URIBL_JP_SURBL Contains an URL listed in the JP SURBL blocklist * [URIs: verybestoff.com] * 10 URIBL_OB_SURBL Contains an URL listed in the OB SURBL blocklist * [URIs: verybestoff.com] * 10 URIBL_SC_SURBL Contains an URL listed in the SC SURBL blocklist * [URIs: verybestoff.com] * 1.1 URIBL_RHS_DOB Contains an URI of a new domain (Day Old Bread) * [URIs: verybestoff.com] * 3.0 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL * [80.97.59.146 listed in zen.spamhaus.org] * 1.0 RCVD_IN_DSBL RBL: Received via a relay in list.dsbl.org * [] * 0.1 RDNS_NONE Delivered to trusted network by a host with no rDNS Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 92FFcYMdxwQC for ; Thu, 31 Jan 2008 18:04:01 -0800 (PST) Received: from 80.97.59.146.sta.moldova.md (unknown [80.97.59.146]) by core3.amsl.com (Postfix) with ESMTP id 6F9D728C0D7 for ; Thu, 31 Jan 2008 18:03:58 -0800 (PST) Received: from [80.97.59.146] by smtp1.msp.securence.com; Fri, 32 Jan 2008 04:05:33 +0200 From: "Shelia Rodriguez" To: Subject: ***SPAM*** 100.841 (5) FrancescaBigFuckstick Date: Fri, 32 Jan 2008 04:05:33 +0200 Message-ID: <1270fd74$00000004$923b6150@excommunicatedjn4> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Importance: Normal WinstonCockQueen-sized http://www.verybestoff.com From -schmidt-nms@abcatalonian.com Thu Jan 31 19:07:41 2008 Return-Path: <-schmidt-nms@abcatalonian.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 DFE023A6781 for ; Thu, 31 Jan 2008 19:07:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: YES X-Spam-Score: 78.231 X-Spam-Level: **************************************************************** X-Spam-Status: Yes, score=78.231 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DOS_OE_TO_MX=2.75, HTML_MESSAGE=1, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.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_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10] X-Spam-Report: * 3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100% * [score: 1.0000] * 1.0 HTML_MESSAGE BODY: HTML included in message * 1.5 RAZOR2_CF_RANGE_E8_51_100 Razor2 gives engine 8 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/) * 1.5 RAZOR2_CF_RANGE_E4_51_100 Razor2 gives engine 4 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50% * [cf: 100] * 1.1 URIBL_RHS_DOB Contains an URI of a new domain (Day Old Bread) * [URIs: writtenfinish.com] * 0.9 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL * [76.8.163.90 listed in zen.spamhaus.org] * 3.0 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL * 2.0 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net * [Blocked - see ] * 20 URIBL_BLACK Contains an URL listed in the URIBL blacklist * [URIs: writtenfinish.com] * 10 URIBL_WS_SURBL Contains an URL listed in the WS SURBL blocklist * [URIs: writtenfinish.com] * 10 URIBL_JP_SURBL Contains an URL listed in the JP SURBL blocklist * [URIs: writtenfinish.com] * 10 URIBL_OB_SURBL Contains an URL listed in the OB SURBL blocklist * [URIs: writtenfinish.com] * 10 URIBL_SC_SURBL Contains an URL listed in the SC SURBL blocklist * [URIs: writtenfinish.com] * 2.8 DOS_OE_TO_MX Delivered direct to MX with OE headers Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wVP7rTWSP8sC for ; Thu, 31 Jan 2008 19:07:41 -0800 (PST) Received: from imctv-163-90.mis.net (imctv-163-90.mis.net [76.8.163.90]) by core3.amsl.com (Postfix) with ESMTP id 2A49D3A67AE for ; Thu, 31 Jan 2008 19:07:40 -0800 (PST) Message-ID: <000501c8647f$068ed938$9924e183@dmeituo> From: "austen chung-na" <-schmidt-nms@abcatalonian.com> To: Subject: ***SPAM*** 78.231 (5) Hear her screaming your name in passion! Date: Fri, 01 Feb 2008 01:21:54 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0002_01C8647F.068A3F78" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 This is a multi-part message in MIME format. ------=_NextPart_000_0002_01C8647F.068A3F78 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Your new baby-maker scores more! ------=_NextPart_000_0002_01C8647F.068A3F78 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Your new baby-maker scores = more! ------=_NextPart_000_0002_01C8647F.068A3F78-- From btrfli2001@earthlink.net Thu Jan 31 20:02:39 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 6E74828C13D for ; Thu, 31 Jan 2008 20:02:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: YES X-Spam-Score: 99.634 X-Spam-Level: **************************************************************** X-Spam-Status: Yes, score=99.634 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DOS_OE_TO_MX=2.75, 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_MESSAGE=1, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.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_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SBL=20, URIBL_WS_SURBL=10] X-Spam-Report: * 3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100% * [score: 1.0000] * 2.1 FH_HOST_EQ_VERIZON_P Host is pool-.+verizon.net * 0.8 FH_HOST_EQ_D_D_D_D Host starts with d-d-d-d * 2.4 HELO_DYNAMIC_IPADDR Relay HELO'd using suspicious hostname (IP addr * 1) * 1.5 HELO_EQ_VERIZON_POOL HELO_EQ_VERIZON_POOL * 1.6 FH_HELO_EQ_D_D_D_D Helo is d-d-d-d * 1.0 HTML_MESSAGE BODY: HTML included in message * 1.5 RAZOR2_CF_RANGE_E8_51_100 Razor2 gives engine 8 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/) * 1.5 RAZOR2_CF_RANGE_E4_51_100 Razor2 gives engine 4 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50% * [cf: 100] * 20 URIBL_BLACK Contains an URL listed in the URIBL blacklist * [URIs: strutfootonline.com] * 1.1 URIBL_RHS_DOB Contains an URI of a new domain (Day Old Bread) * [URIs: strutfootonline.com] * 10 URIBL_WS_SURBL Contains an URL listed in the WS SURBL blocklist * [URIs: strutfootonline.com] * 10 URIBL_JP_SURBL Contains an URL listed in the JP SURBL blocklist * [URIs: strutfootonline.com] * 10 URIBL_OB_SURBL Contains an URL listed in the OB SURBL blocklist * [URIs: strutfootonline.com] * 0.9 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP address * [71.178.168.212 listed in dnsbl.sorbs.net] * 2.0 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net * [Blocked - see ] * 0.9 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL * [71.178.168.212 listed in zen.spamhaus.org] * 3.0 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL * 20 URIBL_SBL Contains an URL listed in the SBL blocklist * [URIs: strutfootonline.com] * 2.0 FM_DDDD_TIMES_2 Dual helo + host eq d_d_d_d * 0.1 RDNS_DYNAMIC Delivered to trusted network by host with * dynamic-looking rDNS * 2.8 DOS_OE_TO_MX Delivered direct to MX with OE headers Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xiH-RmJxgaE0 for ; Thu, 31 Jan 2008 20:02:35 -0800 (PST) Received: from pool-71-178-168-212.washdc.fios.verizon.net (pool-71-178-168-212.washdc.fios.verizon.net [71.178.168.212]) by core3.amsl.com (Postfix) with ESMTP id 7BFCD28C11B for ; Thu, 31 Jan 2008 20:02:35 -0800 (PST) Message-ID: <000a01c86487$04d6b2ff$064622bb@vgapmffa> From: "eberhard faith" To: Subject: ***SPAM*** 99.634 (5) 2008 Designer Shoes Collection from Gucci Ugg Prada Chanel Dsquared Date: Fri, 01 Feb 2008 02:18:06 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C86487.04D5B426" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C86487.04D5B426 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable They say first impressions are everything... Make sure you stand your ground when walking around, simply by walking = hard in Top Brand Name Designer Footwear. Forget department store prices, Enjoy DIRECT PRICING at more than 65% = OFF on a wide variety of 2008 Collections from Versace, Prada, Chanel, = Dior & More. =20 We also carry TOP BRANDS such as Uggs, Gucci, Dsquared, D&G, Bally, = Coach and much more. Find Loafers, Boots, High Heels, Sneakers and = Casual Shoes from Brand Names at less than WHOLESALE prices. Selection is available for Women and Men, Shipping is FREE WorldWide, = Trendy Fashion Footwear Sale of the YEAR! Forget Department Store Prices, Buy Direct=20 Visit Today! Click Here.... =20 =20 ------=_NextPart_000_0007_01C86487.04D5B426 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

They say first = impressions are everything...
Make sure you stand your ground when walking around, simply by walking = hard in Versace, = Prada, Chanel, Dior & More.

=20 We also carry TOP BRANDS such as Uggs, Gucci, Dsquared, D&G, Bally, = Coach and much more. Find Loafers, Boots, High Heels, Sneakers = and Casual Shoes from Brand Names at less than WHOLESALE prices.
Selection is available for Women and Men, Shipping is FREE WorldWide, = Trendy Fashion Footwear Sale of the YEAR!

Forget Department = Store Prices, Buy Direct
Visit Today! Click Here....
------=_NextPart_000_0007_01C86487.04D5B426-- From don@web-cashing.net Thu Jan 31 21:16: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 9A6F528C1CB for ; Thu, 31 Jan 2008 21:16:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: YES X-Spam-Score: 97.372 X-Spam-Level: **************************************************************** X-Spam-Status: Yes, score=97.372 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HTML_MESSAGE=1, INVALID_DATE=1.245, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.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, 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] X-Spam-Report: * 3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100% * [score: 1.0000] * 1.5 FH_RELAY_NODNS We could not determine your Reverse DNS * 1.2 INVALID_DATE Invalid Date: header (not RFC 2822) * 1.0 HTML_MESSAGE BODY: HTML included in message * 1.5 RAZOR2_CF_RANGE_E8_51_100 Razor2 gives engine 8 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/) * 1.5 RAZOR2_CF_RANGE_E4_51_100 Razor2 gives engine 4 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50% * [cf: 100] * 20 URIBL_BLACK Contains an URL listed in the URIBL blacklist * [URIs: mactenonline.com] * 1.1 URIBL_RHS_DOB Contains an URI of a new domain (Day Old Bread) * [URIs: mactenonline.com] * 3.0 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL * [125.133.70.137 listed in zen.spamhaus.org] * 10 URIBL_WS_SURBL Contains an URL listed in the WS SURBL blocklist * [URIs: mactenonline.com] * 10 URIBL_JP_SURBL Contains an URL listed in the JP SURBL blocklist * [URIs: mactenonline.com] * 10 URIBL_OB_SURBL Contains an URL listed in the OB SURBL blocklist * [URIs: mactenonline.com] * 10 URIBL_SC_SURBL Contains an URL listed in the SC SURBL blocklist * [URIs: mactenonline.com] * 2.0 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net * [Blocked - see ] * 20 URIBL_SBL Contains an URL listed in the SBL blocklist * [URIs: mactenonline.com] * 0.1 RDNS_NONE Delivered to trusted network by a host with no rDNS Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yOsmzaZikvXe for ; Thu, 31 Jan 2008 21:16:55 -0800 (PST) Received: from DHFGJHFC-RF88KS.kornet (unknown [125.133.70.137]) by core3.amsl.com (Postfix) with ESMTP id E626628C1B5 for ; Thu, 31 Jan 2008 21:16:54 -0800 (PST) Received: from [125.133.70.137] by web-cashing.net; Fri, 32 Jan 2008 14:44:29 +0900 From: "Norris Bernal" To: Subject: ***SPAM*** 97.372 (5) 10 advantages of ED remedy! Date: Fri, 32 Jan 2008 14:44:29 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_0440FCB0.14700000" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Aca6QRR8W4SUHXBIMHANDCH3IK2S6V== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Message-ID: <0440fd74$14700000$8946857d@don> This is a multi-part message in MIME format. ------=_NextPart_000_0006_0440FCB0.14700000 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit New generation extra-strength med, for the treatment of ED only in men. Benefits: 6-8 Hour Response Period; Improves Focus; Accelerates Recovery from Prior I|\|tercourse; Amplified Passion and Desire; Rapid-Absorption of the Chemical Component; Increased Staaamina and Libido; Psychological Confidence and Relief; Helpfull in Hard Cases. If you experience some lapses in your sexual life, please, do not hesitate or make your life worse. Just a blue-pill will cure all your doubts and restore the life you will not help enjoying. http://mactenonline.com (Wait a moment until the page will be loaded entirely) ------=_NextPart_000_0006_0440FCB0.14700000 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable New generation extra-strength med, for the treatment of ED only i= n men.

Benefits:
6-8 Hour Response Period;
Improves Focus;
Accelerates Recovery from Prior I|\|tercourse;
Amplified Passion and Desire;
Rapid-Absorption of the Chemical Component;
Increased Staaaamina and Libido;
Psychological Confidence and Relief;
Helpfull in Hard Cases.

If you experience some lapses in your sexual life, please, do not hesitat= e or make your life worse.
Just a blue-pill will cure all your doubts and restore the life you will= not help enjoying.

http://mactenonline.com
(Wait a moment until the page will be loaded entirely) ------=_NextPart_000_0006_0440FCB0.14700000-- From leanwec523@myselfbelt.com Thu Jan 31 23:07: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 C2B463A6812 for ; Thu, 31 Jan 2008 23:07:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: YES X-Spam-Score: 94.549 X-Spam-Level: **************************************************************** X-Spam-Status: Yes, score=94.549 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HOST_EQ_D_D_D_D=0.765, HELO_LH_HOME=3.714, HOST_MISMATCH_COM=0.311, INVALID_DATE=1.245, 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, SPAMMY_XMAILER=2.337, 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] X-Spam-Report: * 3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100% * [score: 1.0000] * 3.7 HELO_LH_HOME HELO_LH_HOME * 0.8 FH_HOST_EQ_D_D_D_D Host starts with d-d-d-d * 1.2 INVALID_DATE Invalid Date: header (not RFC 2822) * 2.2 TVD_SPACE_RATIO BODY: TVD_SPACE_RATIO * 1.5 RAZOR2_CF_RANGE_E8_51_100 Razor2 gives engine 8 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/) * 0.5 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50% * [cf: 100] * 20 URIBL_BLACK Contains an URL listed in the URIBL blacklist * [URIs: lamintour.com] * 10 URIBL_AB_SURBL Contains an URL listed in the AB SURBL blocklist * [URIs: lamintour.com] * 10 URIBL_WS_SURBL Contains an URL listed in the WS SURBL blocklist * [URIs: lamintour.com] * 10 URIBL_JP_SURBL Contains an URL listed in the JP SURBL blocklist * [URIs: lamintour.com] * 10 URIBL_OB_SURBL Contains an URL listed in the OB SURBL blocklist * [URIs: lamintour.com] * 10 URIBL_SC_SURBL Contains an URL listed in the SC SURBL blocklist * [URIs: lamintour.com] * 1.1 URIBL_RHS_DOB Contains an URI of a new domain (Day Old Bread) * [URIs: lamintour.com] * 0.9 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP address * [81.153.19.182 listed in dnsbl.sorbs.net] * 2.0 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net * [Blocked - see ] * 0.9 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL * [81.153.19.182 listed in zen.spamhaus.org] * 3.0 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL * 0.3 HOST_MISMATCH_COM HOST_MISMATCH_COM * 2.3 SPAMMY_XMAILER X-Mailer string is common in spam and not in ham * 0.1 RDNS_DYNAMIC Delivered to trusted network by host with * dynamic-looking rDNS Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yGn8XVohgJmz for ; Thu, 31 Jan 2008 23:07:47 -0800 (PST) Received: from BThomehub.home (host81-153-19-182.range81-153.btcentralplus.com [81.153.19.182]) by core3.amsl.com (Postfix) with ESMTP id 3ABDC3A685D for ; Thu, 31 Jan 2008 23:07:46 -0800 (PST) Received: from [81.153.19.182] by mx-1.loosefoot.com; Fri, 32 Jan 2008 07:09:20 +0000 From: "Concetta Barajas" To: Subject: ***SPAM*** 94.549 (5) ZacheryDickMountainous Date: Fri, 32 Jan 2008 07:09:20 +0000 Message-ID: <0340fd74$00000005$b6139951@leanwec523> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4115 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.2300 Importance: Normal DoloresPenisEnormous http://www.lamintour.com From kbarnett@mitjans-advocats.com Thu Jan 31 23:20: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 390903A6859 for ; Thu, 31 Jan 2008 23:20:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: YES X-Spam-Score: 50.58 X-Spam-Level: ************************************************** X-Spam-Status: Yes, score=50.58 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, HELO_EQ_CLUBINTERNET=0.781, HELO_EQ_FR=0.35, HOST_EQ_CLUBINTERNET=0.663, NORMAL_HTTP_TO_IP=0.001, 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] X-Spam-Report: * 3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100% * [score: 1.0000] * 0.3 HELO_EQ_FR HELO_EQ_FR * 0.8 HELO_EQ_CLUBINTERNET HELO_EQ_CLUBINTERNET * 0.7 HOST_EQ_CLUBINTERNET HOST_EQ_CLUBINTERNET * 0.8 FH_HOST_EQ_D_D_D_D Host starts with d-d-d-d * 2.4 HELO_DYNAMIC_IPADDR Relay HELO'd using suspicious hostname (IP addr * 1) * 1.6 FH_HELO_EQ_D_D_D_D Helo is d-d-d-d * 0.0 NORMAL_HTTP_TO_IP URI: Uses a dotted-decimal IP address in URL * 1.5 RAZOR2_CF_RANGE_E8_51_100 Razor2 gives engine 8 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/) * 0.5 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50% * [cf: 100] * 20 URIBL_BLACK Contains an URL listed in the URIBL blacklist * [URIs: 82.66.134.167] * 10 URIBL_JP_SURBL Contains an URL listed in the JP SURBL blocklist * [URIs: 82.66.134.167] * 0.9 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL * [87.91.150.78 listed in zen.spamhaus.org] * 3.0 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL * 2.0 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net * [Blocked - see ] * 2.0 FM_DDDD_TIMES_2 Dual helo + host eq d_d_d_d * 0.1 RDNS_DYNAMIC Delivered to trusted network by host with * dynamic-looking rDNS Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6xqemsS8dq6Q for ; Thu, 31 Jan 2008 23:20:49 -0800 (PST) Received: from i05m-87-91-150-78.d4.club-internet.fr (i05m-87-91-150-78.d4.club-internet.fr [87.91.150.78]) by core3.amsl.com (Postfix) with SMTP id 0496D3A685B for ; Thu, 31 Jan 2008 23:20:48 -0800 (PST) Received: from [167.210.106.132] (helo=xyrbd) by i05m-87-91-150-78.d4.club-internet.fr with smtp (Exim 4.62 (FreeBSD)) id 1JLX2P-0001jF-MY; Fri, 1 Feb 2008 08:24:12 +0100 Message-ID: <47A2C8AD.5040507@mitjans-advocats.com> Date: Fri, 1 Feb 2008 08:22:21 +0100 From: User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: ccamp-archive@ietf.org Subject: ***SPAM*** 50.58 (5) Your Love Has Opened Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Inside My Heart http://82.66.134.167/ From jameson@sphpl.com Thu Jan 31 23:20:53 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 B862D3A684E for ; Thu, 31 Jan 2008 23:20:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: YES X-Spam-Score: 64.299 X-Spam-Level: **************************************************************** X-Spam-Status: Yes, score=64.299 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, HELO_EQ_CLUBINTERNET=0.781, HELO_EQ_FR=0.35, HOST_EQ_CLUBINTERNET=0.663, NORMAL_HTTP_TO_IP=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.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, TVD_SPACE_RATIO=2.219, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_WS_SURBL=10] X-Spam-Report: * 3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100% * [score: 1.0000] * 0.3 HELO_EQ_FR HELO_EQ_FR * 0.8 HELO_EQ_CLUBINTERNET HELO_EQ_CLUBINTERNET * 0.7 HOST_EQ_CLUBINTERNET HOST_EQ_CLUBINTERNET * 0.8 FH_HOST_EQ_D_D_D_D Host starts with d-d-d-d * 2.4 HELO_DYNAMIC_IPADDR Relay HELO'd using suspicious hostname (IP addr * 1) * 1.6 FH_HELO_EQ_D_D_D_D Helo is d-d-d-d * 0.0 NORMAL_HTTP_TO_IP URI: Uses a dotted-decimal IP address in URL * 2.2 TVD_SPACE_RATIO BODY: TVD_SPACE_RATIO * 1.5 RAZOR2_CF_RANGE_E8_51_100 Razor2 gives engine 8 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/) * 1.5 RAZOR2_CF_RANGE_E4_51_100 Razor2 gives engine 4 confidence level * above 50% * [cf: 56] * 0.5 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50% * [cf: 100] * 2.0 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net * [Blocked - see ] * 3.0 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL * [87.91.150.78 listed in zen.spamhaus.org] * 0.9 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL * 10 URIBL_WS_SURBL Contains an URL listed in the WS SURBL blocklist * [URIs: 75.68.231.167] * 10 URIBL_JP_SURBL Contains an URL listed in the JP SURBL blocklist * [URIs: 75.68.231.167] * 20 URIBL_BLACK Contains an URL listed in the URIBL blacklist * [URIs: 75.68.231.167] * 2.0 FM_DDDD_TIMES_2 Dual helo + host eq d_d_d_d * 0.1 RDNS_DYNAMIC Delivered to trusted network by host with * dynamic-looking rDNS Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JMcn8LM0lAwv for ; Thu, 31 Jan 2008 23:20:53 -0800 (PST) Received: from i05m-87-91-150-78.d4.club-internet.fr (i05m-87-91-150-78.d4.club-internet.fr [87.91.150.78]) by core3.amsl.com (Postfix) with SMTP id 897C33A681C for ; Thu, 31 Jan 2008 23:20:52 -0800 (PST) Received: from [196.188.120.236] (helo=qxi) by i05m-87-91-150-78.d4.club-internet.fr with smtp (Exim 4.62 (FreeBSD)) id 1JLXd6-0002dc-Pk; Fri, 1 Feb 2008 08:25:24 +0100 Message-ID: <47A2C8B2.3070305@sphpl.com> Date: Fri, 1 Feb 2008 08:22:26 +0100 From: User-Agent: Thunderbird 1.5.0.13 (Windows/20070809) MIME-Version: 1.0 To: ccamp-archive@megatron.ietf.org Subject: ***SPAM*** 64.299 (5) Love Remains Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I Love Thee http://75.68.231.167/ From missy-eciruamt@28chejil.com Thu Jan 31 23:41: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 A8AB13A680A for ; Thu, 31 Jan 2008 23:41:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: YES X-Spam-Score: 98.394 X-Spam-Level: **************************************************************** X-Spam-Status: Yes, score=98.394 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DOS_OE_TO_MX=2.75, FH_HELO_EQ_D_D_D_D=1.597, FH_RELAY_NODNS=1.451, HELO_DYNAMIC_IPADDR2=4.395, HTML_MESSAGE=1, J_CHICKENPOX_42=0.6, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.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, RELAY_IS_203=0.994, 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_SC_SURBL=10, URIBL_WS_SURBL=10] X-Spam-Report: * 3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100% * [score: 1.0000] * 1.0 RELAY_IS_203 RELAY_IS_203 * 1.5 FH_RELAY_NODNS We could not determine your Reverse DNS * 4.4 HELO_DYNAMIC_IPADDR2 Relay HELO'd using suspicious hostname (IP addr * 2) * 1.6 FH_HELO_EQ_D_D_D_D Helo is d-d-d-d * 1.9 TVD_RCVD_IP TVD_RCVD_IP * 0.6 J_CHICKENPOX_42 BODY: 4alpha-pock-2alpha * 1.0 HTML_MESSAGE BODY: HTML included in message * 1.5 RAZOR2_CF_RANGE_E8_51_100 Razor2 gives engine 8 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/) * 1.5 RAZOR2_CF_RANGE_E4_51_100 Razor2 gives engine 4 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50% * [cf: 100] * 10 URIBL_AB_SURBL Contains an URL listed in the AB SURBL blocklist * [URIs: binmose.com] * 10 URIBL_WS_SURBL Contains an URL listed in the WS SURBL blocklist * [URIs: binmose.com] * 10 URIBL_JP_SURBL Contains an URL listed in the JP SURBL blocklist * [URIs: binmose.com] * 10 URIBL_OB_SURBL Contains an URL listed in the OB SURBL blocklist * [URIs: binmose.com] * 10 URIBL_SC_SURBL Contains an URL listed in the SC SURBL blocklist * [URIs: binmose.com] * 1.1 URIBL_RHS_DOB Contains an URI of a new domain (Day Old Bread) * [URIs: binmose.com] * 2.0 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net * [Blocked - see ] * 20 URIBL_BLACK Contains an URL listed in the URIBL blacklist * [URIs: binmose.com] * 3.0 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL * [203.160.118.113 listed in zen.spamhaus.org] * 0.1 RDNS_NONE Delivered to trusted network by a host with no rDNS * 2.8 DOS_OE_TO_MX Delivered direct to MX with OE headers Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZJgKHmIZzVuR for ; Thu, 31 Jan 2008 23:41:34 -0800 (PST) Received: from 203-160-118-113.callplus.net.nz (unknown [203.160.118.113]) by core3.amsl.com (Postfix) with ESMTP id 1F5DE3A6781 for ; Thu, 31 Jan 2008 23:41:32 -0800 (PST) Message-ID: <000f01c864a6$10f21b30$7176a0cb@ownere3ywia8a8> From: "missy Pitblado" To: ccamp-archive@ietf.org Subject: ***SPAM*** 98.394 (5) Be the talk of the town with your new huge schl0ng Date: Fri, 1 Feb 2008 20:42:59 +1300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--------=_NextPart_000_000B_01C86513.07EB6330" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 ----------=_NextPart_000_000B_01C86513.07EB6330 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable A revolutionary medical discovery has been made Find out more here ----------=_NextPart_000_000B_01C86513.07EB6330 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable A revolutionary medical discovery = has been=20 made Find out more here ----------=_NextPart_000_000B_01C86513.07EB6330-- From mcKinleyxo@virgin.net Thu Jan 31 23:47: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 9B7663A67E1; Thu, 31 Jan 2008 23:47:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: YES X-Spam-Score: 99.361 X-Spam-Level: **************************************************************** X-Spam-Status: Yes, score=99.361 tagged_above=-999 required=5 tests=[BAYES_99=3.5, BODY_ENHANCEMENT=0.309, BODY_ENHANCEMENT2=0.001, FH_RELAY_NODNS=1.451, FRT_PENIS1=3.592, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_31=0.6, MANGLED_PENIS=2.3, MONEY_BACK=0.001, 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_DSBL=0.961, RCVD_IN_NJABL_PROXY=1.643, RCVD_IN_SORBS_HTTP=0.001, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_ADULT2=1.42, SARE_ENLRGYOUR=1.02, SARE_OBFU_PENIS_SUB=3.333, 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] X-Spam-Report: * 3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100% * [score: 1.0000] * 1.5 FH_RELAY_NODNS We could not determine your Reverse DNS * 3.3 SARE_OBFU_PENIS_SUB subject has obfuscated spammer topic * 2.3 MANGLED_PENIS BODY: mangled - Penis * 0.0 MONEY_BACK BODY: Money back guarantee * 0.3 BODY_ENHANCEMENT BODY: Information on growing body parts * 1.0 SARE_ENLRGYOUR BODY: Talks about "enlarging" something * 1.4 SARE_ADULT2 BODY: Contains adult material * 3.6 FRT_PENIS1 BODY: ReplaceTags: Penis * 0.0 BODY_ENHANCEMENT2 BODY: Information on getting larger body parts * 0.6 J_CHICKENPOX_31 BODY: 3alpha-pock-1alpha * 1.5 RAZOR2_CF_RANGE_E8_51_100 Razor2 gives engine 8 confidence level * above 50% * [cf: 100] * 0.5 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/) * 0.5 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50% * [cf: 100] * 20 URIBL_BLACK Contains an URL listed in the URIBL blacklist * [URIs: dovosgehr.com] * 10 URIBL_AB_SURBL Contains an URL listed in the AB SURBL blocklist * [URIs: dovosgehr.com] * 10 URIBL_WS_SURBL Contains an URL listed in the WS SURBL blocklist * [URIs: dovosgehr.com] * 10 URIBL_JP_SURBL Contains an URL listed in the JP SURBL blocklist * [URIs: dovosgehr.com] * 10 URIBL_OB_SURBL Contains an URL listed in the OB SURBL blocklist * [URIs: dovosgehr.com] * 10 URIBL_SC_SURBL Contains an URL listed in the SC SURBL blocklist * [URIs: dovosgehr.com] * 1.1 URIBL_RHS_DOB Contains an URI of a new domain (Day Old Bread) * [URIs: dovosgehr.com] * 1.6 RCVD_IN_NJABL_PROXY RBL: NJABL: sender is an open proxy * [60.217.228.199 listed in combined.njabl.org] * 2.0 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net * [Blocked - see ] * 3.0 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL * [60.217.228.199 listed in zen.spamhaus.org] * 0.0 RCVD_IN_SORBS_HTTP RBL: SORBS: sender is open HTTP proxy server * [60.217.228.199 listed in dnsbl.sorbs.net] * 1.0 RCVD_IN_DSBL RBL: Received via a relay in list.dsbl.org * [] * 0.1 RDNS_NONE Delivered to trusted network by a host with no rDNS * 0.6 HELO_MISMATCH_COM HELO_MISMATCH_COM Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bniRF+MAzSei; Thu, 31 Jan 2008 23:47:02 -0800 (PST) Received: from latinmail.com (unknown [60.217.228.199]) by core3.amsl.com (Postfix) with ESMTP id 853223A6853; Thu, 31 Jan 2008 23:47:01 -0800 (PST) From: "Lenora McKinley" Subject: ***SPAM*** 99.361 (5) Add up to 4 inches to yours pxenis crg7c Message-ID: <1201848743.4082@virgin.net> Date: Fri, 01 Feb 2008 06:52:23 +0000 To: call-home@ietf.org, calsch-archive@ietf.org, capwap-archive@ietf.org, ccamp-archive@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 8bit Dear call-home@ietf.org http://dovosgehr.com Do you want Enlarge your Penis? » Gain 3+ Inches In Length. 100% Money Back Guarantee. » *3 FREE Bottles Of ManSter !! http://dovosgehr.com Thanks Cathy Vargas call-home@ietf.org wrote: > Are you ready for BIG PENlS ? 1u2jjp1h0j- out me now http://dovosgehr.com/w.php Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 31 Jan 2008 10:54:23 +0000 Message-ID: <106201c863f7$8154f640$0200a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Ong, Lyndon" , Cc: "Dimitri Papadimitriou" Subject: Re: Question on TLV Length Calculation Date: Thu, 31 Jan 2008 10:52:43 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Hi Lyndon, I didn't see an answer to this on the list. Dimitri, do you have a view? > Simple question on length calculation for RSVP-TE TLVs: I've > noticed that draft-ietf-ccamp-ethernet-traffic-parameters-03.txt > has adopted a method of calculating TLV length from RFC 4420, > where the length includes only the value portion of the TLV, and > does not include the header (type and length bytes) or any padding > bytes. > > This is a bit different from how length is computed for objects and > sub-objects, where length includes header as well. Having not > followed the discussion on RFC 4420 closely, can someone clarify: > > -- is this method of length calculation to be followed on all new > TLVs defined for RSVP-TE? > > -- if not, is there some basis for deciding what calculation to follow > when defining a new TLV? More important than the object and subobject length calculations, are the TLV length calculations defined in RFC 3471 where we have... Length: 16 bits Indicates the total length of the TLV, i.e., 4 + the length of the value field in octets. A value field whose length is not a multiple of four MUST be zero-padded so that the TLV is four- octet aligned. I would say that we should aim for consistency and that RFC 4420 was a mistake (mea culpa) caused by mirroring the capabilities advertisement features from a similar draft in the OSPF working group (OSPF TLVs use L = value length). Consistency means following 3471 where possible (note that we can't go back and fix 4420 because it is deployed). So the questions for Dimitri with draft-ietf-ccamp-ethernet-traffic-parameters-03.txt are: - is there a reason to diverge from 3471? - is it too late to fix this? Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 31 Jan 2008 10:38:18 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Date: Thu, 31 Jan 2008 10:35:49 -0000 Message-ID: <2ECAA42C79676B42AEBAC11229CA7D0C01D428DA@E03MVB2-UKBR.domain1.systemhost.net> Thread-Topic: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Thread-Index: Achid4JetInOIvLXS36xGBjOv4vCdwAOqlZgAB8MVpAADGxFgAACaWoQAADUPSAAIOuXAA== From: To: , , Cc: , , , , Thanks Dimitri, You asked a question below...which I have extracted/inserted below for ease of reference: > The > co-ps mode has the richest scope for 'variation' in the DP=20 > labelling of > traffic units (this is more than simply a destination proxy label > BTW....this was a point I saw Adrian alluding to)....and one can even > violate the rules of connections here and really screw-up any=20 > notion of deterministic resource management anyway. does that imply change in the def. of L2SC as defined in RFC 3945 ? or is it an add-on that is not impacting other RFC's mechanisms ? my understanding is the latter but never got an answer whether or not this is indeed the case (and proposal on how to spell this in the doc.) NH=3D> I assume you are referring to the definition of a connection (wrt to what L2Sc really means)? A connection can only have a single source and it must not re-order traffic units...a subtle corollary of this is that a connection can only have a single traffic/QoS class. This means connections can only be p2p or p2mp in construction. This is a necessary requirement for resource assignment determinism. Assuming one does not violate these rules (and you can't in the co-cs mode) then there is no need to include a SA label in the traffic units of a connection....the parent connection object carries that semantic. Further, because a connection represents a chosen set of link connections (hops) between the source and the sink(s)then: - in the case of a p2p connection the label carrying the DA information need only be link connection unique (across the population of clients served by the lower layer network connection on that link), ie it can be swapped hop by hop - in the case of a p2mp connection the label carrying the DA is a 'name' (proxy) that respresents a set of real DAs. These labelling short-cuts is all works fine until there are misconnectivity defects. But if one wants to make the network more robust to such defects (without even using any adjunct OAM flows at all) then including the SA in each traffic unit and not-swapping the DA in the case of p2p connections (ie just use the real DA and not a proxy for it) has many benefits. Now if you start with a traffic unit that was originally designed for cl-ps operation and use it for a co-ps operation then the above labelling information is already present, ie one has no need to take short-cuts on removing the SA or making the DA only link connection unique....the cl-ps mode cannot allow such short-cuts as there is no connection that provides this information. Now if one chooses to create mp2p merging constructs and there is also no SA information then you have lost information on where the traffic unit came from.....and this lost information must be provided by some other means (usually an appeal to a higher layer entity =3D> which if cl-ps (eg IP) allows SA recovery directly or if not cl-ps (eg ATM, etc) requires a further label is added to provide this information, eg PW label in MPLS). But this is only dealing with the loss of SA information caused by merging....we still have the issue that merging constructs cannot have deterministic resource allocation. I'm not sure that answers your question, because it assumes the above is understood (implicit?) in the definition of what L2SC really means....I suspect the above considerations have not really been taken into account. regards, Neil > -----Original Message----- > From: PAPADIMITRIOU Dimitri=20 > [mailto:Dimitri.Papadimitriou@alcatel-lucent.be]=20 > Sent: 30 January 2008 23:40 > To: Harrison,N,Neil,DMF R; howard.green@ericsson.com; loa@pi.se > Cc: Niven-jenkins,B,Ben,DMF R; lberger@labn.net;=20 > dwfedyk@nortel.com; dbrungard@att.com; ccamp@ops.ietf.org > Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt >=20 >=20 > =20 > neil,=20 >=20 > > -----Original Message----- > > From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] > > Sent: Wednesday, January 30, 2008 7:14 PM > > To: PAPADIMITRIOU Dimitri; howard.green@ericsson.com; loa@pi.se > > Cc: benjamin.niven-jenkins@bt.com; lberger@labn.net;=20 > > dwfedyk@nortel.com; dbrungard@att.com; ccamp@ops.ietf.org > > Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt > >=20 > > I personally think you are making a mountain out of a molehill here=20 > > Dimitri. >=20 > the segmentation of SCs we have in RFC 3945 is sufficient to=20 > address your below decomposition. you have to consider that=20 > when a new techno is to be supported by GMPLS, stacks are not=20 > going to change the full engine/stack per specific technology - >=20 > > And I thought I had explained why there are differences in the=20 > > treatment of layer networks depending on their mode...I=20 > clearly did a=20 > > bad job. >=20 > don't worry, we very well understand the difference between a=20 > circuit-switched and packet-switched network.=20 >=20 > > Sure GMPLS is a generic OOB CP suite of protocols, but the=20 > details of=20 > > the parameters used used to describe the layer network being > > considered will depend on: > > - for the co-cs mode whether we are dealing with resources which > > are either regular time-slices, freq or space > > - for the co-ps mode there is only irregular time-slices. >=20 > L2SC is in the latter. > =20 > > And the labelling of such resource partitions is different in > > each case > > too...so just like it is impossible to have a common (ie=20 > > single instance > > of) CP running 'IP to Optics' (or any functional component for that > > matter) it is impossible to have an identical set of parameters > > describing each mode....this is just the physics and the way=20 > > it is. The > > co-ps mode has the richest scope for 'variation' in the DP=20 > > labelling of > > traffic units (this is more than simply a destination proxy label > > BTW....this was a point I saw Adrian alluding to)....and=20 > one can even > > violate the rules of connections here and really screw-up any=20 > > notion of deterministic resource management anyway. >=20 > does that imply change in the def. of L2SC as defined in RFC=20 > 3945 ? or is it an add-on that is not impacting other RFC's=20 > mechanisms ? my understanding is the latter but never got an=20 > answer whether or not this is indeed the case (and proposal=20 > on how to spell this in the doc.) >=20 > the addition to adrian's text is a way out. it is to be=20 > followed by discussions because the protocol aspects remain open.=20 >=20 > thanks, > -d. >=20 > > regards, Neil > >=20 > > > -----Original Message----- > > > From: PAPADIMITRIOU Dimitri > > > [mailto:Dimitri.Papadimitriou@alcatel-lucent.be]=20 > > > Sent: 30 January 2008 17:23 > > > To: Howard Green; Loa Andersson > > > Cc: Harrison,N,Neil,DMF R; Niven-jenkins,B,Ben,DMF R;=20 > > > lberger@labn.net; dwfedyk@nortel.com; dbrungard@att.com;=20 > > > ccamp@ops.ietf.org > > > Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt > > >=20 > > >=20 > > > =20 > > >=20 > > > > -----Original Message----- > > > > From: Howard Green [mailto:howard.green@ericsson.com] > > > > Sent: Wednesday, January 30, 2008 12:09 PM > > > > To: PAPADIMITRIOU Dimitri; Loa Andersson > > > > Cc: neil.2.harrison@bt.com; benjamin.niven-jenkins@bt.com; > > > > lberger@labn.net; dwfedyk@nortel.com; dbrungard@att.com;=20 > > > > ccamp@ops.ietf.org > > > > Subject: RE: Proposed WG Draft -=20 > draft-gmpls-ethernet-arch-00.txt > > > >=20 > > > > Hi > > > > Dimitri seems to me to be making a very abstract and > > > legalistic point. > > >=20 > > > receive my total disagreement. an individual submission that > > > asks to change an existing RFC requires discussion and=20 > > > particular attention (in part., when it is the protocol arch.=20 > > > document) - if this not possible then probably you have to=20 > > > write also a doc. asking for changing the IETF proces - and=20 > > > then you come back with your individual submission. > > > =20 > > > > The reason why this work is important is that the IEEE has been=20 > > > > evolving Ethernet to give it carrier class features, in=20 > respect of > > > scalability, > > > > OAM, and (with 802.1Qay) the possibility to use an > > external control > > > > plane. > > >=20 > > > no one i think question this. and i don't think the poll is > > > on this specific point. CCAMP or even IETF at large is not an=20 > > > authority to decide upon IEEE technos. > > >=20 > > > > Some of these features will very likely require or enable > > > added value > > > > from extensions to the functionality of GMPLS - for > > example, as has > > > > already been suggested, the addition of functionality > > for creating > > > > the OAM associations. > > >=20 > > > indeed, and your colleague has already received a list of > > > comments to be addressed before seeing any way forward w/ the=20 > > > proposed approach.=20 > > >=20 > > > > Therefore this will likely not be the same as the possible use=20 > > > > suggested in RFC3945, which may (at least in theory) have been=20 > > > > implemented somewhere. > > >=20 > > > the exact problem, i mentionned a couple of times. your own > > > comment shows that one may use GMPLS differently but may i=20 > > > ask WHY ? and what's the implications ? > > >=20 > > > > Therefore the suggestion in the draft seems to make sense. > > >=20 > > > why ? > > >=20 > > > > I can't really see what important principle is being=20 > defended by=20 > > > > the insistence upon L2SC, which, as Don Fedyk > > > stated, was > > > > always somewhat underspecified. > > >=20 > > > THE reason is that an interface SC or a related functionality > > > has never resulted in a specific change in the base protocol=20 > > > building blocks. GMPLS is a generalized approach not a=20 > > > differentiated approach per interface. > > >=20 > > > actually your last statement is not correct (L2SC is well > > > specified in RFC 3945) AND by the way yours does not at all=20 > > > better specify it. > > >=20 > > > > This is not something to be debated in the abstract. The > > > work in ccamp > > > > should allow sensible extension of functionality where it > > > adds value, > > > > and this needs to be discussed on a case by case basis. > > > Therefore we > > > > should make it a working group document and get on with it. > > >=20 > > > -d. > > > > regards Howard Green > > > >=20 > > > > -----Original Message----- > > > > From: owner-ccamp@ops.ietf.org > > [mailto:owner-ccamp@ops.ietf.org] On > > > > Behalf Of PAPADIMITRIOU Dimitri > > > > Sent: 30 January 2008 10:15 > > > > To: Loa Andersson > > > > Cc: neil.2.harrison@bt.com; benjamin.niven-jenkins@bt.com; > > > > lberger@labn.net; dwfedyk@nortel.com; dbrungard@att.com;=20 > > > > ccamp@ops.ietf.org > > > > Subject: RE: Proposed WG Draft -=20 > draft-gmpls-ethernet-arch-00.txt > > > >=20 > > > > loa, > > > >=20 > > > >=20 > > > > i think the main point as ccamp is whether or not we poll > > > for a change > > > > or a continuation inline with RFC3945 -- when the present > > > doc. states: > > > >=20 > > > > "It is expected that there will be no > > > > case where an Eth-LSP will be signaled, or an Eth-LSP > > supporting > > > > interface will be represented, using the L2SC switching > > > > type/capability. A new switching type/capability is > > required to > > > > avoid any potential current usage of the L2SC switching > > > > type/capability in support of Ethernet. > > > >=20 > > > > [...] > > > >=20 > > > > "The L2SC Interface Switching Capabilities MUST > > > > NOT be used to represent interfaces capable of supporting=20 > > > > Eth-LSPs." > > > >=20 > > > > it raises three issues: > > > >=20 > > > > a) what was the previous L2SC def. per RFC 3945 meant=20 > for if not=20 > > > > for use also in GMPLS Ethernet context ? > > > >=20 > > > > b) why a "new one" ? > > > >=20 > > > > this is not explained. > > > >=20 > > > > c) what is the "new one" implying in terms of GMPLS ? > > > >=20 > > > > for inst. in the intro "The intent of this document is to > > reuse and > > > > align with as much of the GMPLS protocols as possible." > > leaves open > > > > the issue of what as much as possible means. > > > >=20 > > > > and on the other "Additions are made only to accommodate > > > features of > > > > Ethernet that are not already supported by GMPLS." so, > > how shall i > > > > interpreet the first sentence now ? inline with point=20 > a) and b) ? > > > >=20 > > > >=20 > > > > the doc. in WG I-D status or not is not going to provide an > > > answer to > > > > these questions. sentences and statements in the doc. > > > contradict each > > > > other. > > > >=20 > > > > thanks, > > > > -d. > > > >=20 > > > >=20 > > > >=20 > > > >=20 > > > >=20 > > > > > -----Original Message----- > > > > > From: Loa Andersson [mailto:loa@pi.se] > > > > > Sent: Tuesday, January 29, 2008 2:04 PM > > > > > To: PAPADIMITRIOU Dimitri > > > > > Cc: neil.2.harrison@bt.com; benjamin.niven-jenkins@bt.com;=20 > > > > > lberger@labn.net; dwfedyk@nortel.com; dbrungard@att.com;=20 > > > > > ccamp@ops.ietf.org > > > > > Subject: Re: Proposed WG Draft - > > draft-gmpls-ethernet-arch-00.txt > > > > >=20 > > > > > Dimitri, > > > > >=20 > > > > > it is possible that you have a point that needs to be > > > > discussed, but > > > > > is this really something that should stop us from adopting > > > > the doc as > > > > > a working group document. > > > > >=20 > > > > > /Loa > > > > >=20 > > > > > PAPADIMITRIOU Dimitri wrote: > > > > > > neil, > > > > > >=20 > > > > > >> -----Original Message----- > > > > > >> From: neil.2.harrison@bt.com=20 > [mailto:neil.2.harrison@bt.com] > > > > > >> Sent: Friday, January 25, 2008 2:27 PM > > > > > >> To: PAPADIMITRIOU Dimitri; benjamin.niven-jenkins@bt.com;=20 > > > > > >> lberger@labn.net > > > > > >> Cc: dwfedyk@nortel.com; dbrungard@att.com;=20 > ccamp@ops.ietf.org > > > > > >> Subject: RE: Proposed WG Draft - > > > draft-gmpls-ethernet-arch-00.txt > > > > > >> > > > > > >> Dimitri....see if this helps...in-line > > > > > >> > > > > > >>> -----Original Message----- > > > > > >>> From: owner-ccamp@ops.ietf.org > > > [mailto:owner-ccamp@ops.ietf.org] > > > > > >>> On Behalf Of > > > > > PAPADIMITRIOU Dimitri > > > > > >>> Sent: 25 January 2008 11:36 > > > > > >>> To: Niven-jenkins,B,Ben,DMF R; Lou Berger > > > > > >>> Cc: Don Fedyk; BRUNGARD, DEBORAH A, ATTLABS; > > > ccamp@ops.ietf.org > > > > > >>> Subject: RE: Proposed WG Draft - > > > > draft-gmpls-ethernet-arch-00.txt > > > > > >>> > > > > > >>> > > > > > >>> ben > > > > > >>> > > > > > >>>> -----Original Message----- > > > > > >>>> From: Ben Niven-Jenkins > > > [mailto:benjamin.niven-jenkins@bt.com] > > > > > >>>> Sent: Thursday, January 24, 2008 3:40 PM > > > > > >>>> To: PAPADIMITRIOU Dimitri; Lou Berger > > > > > >>>> Cc: Don Fedyk; BRUNGARD, DEBORAH A, ATTLABS; > > > ccamp@ops.ietf.org > > > > > >>>> Subject: Re: Proposed WG Draft - > > > > draft-gmpls-ethernet-arch-00.txt > > > > > >>>> > > > > > >>>> Dimitri, > > > > > >>>> > > > > > >>>> I find your mail somewhat puzzling. > > > > > >>>> > > > > > >>>> You appear to be saying that GMPLS as per RFC 3945 is set > > > > > >>> in stone and > > > > > >>>> nothing should modify/enhance the behaviour as specified > > > > > >> in RFC3945 > > > > > >>>> which implies that when RFC3945 was produced the crystal > > > > > ball was > > > > > >>>> working extremely well and all possible future > > > > > applications of the > > > > > >>>> technology had > > > > > >>>> been correctly envisaged. I don't believe that > > was the case. > > > > > >>> this is not what i say. i am concerned in stating > > > > beforehand RFC > > > > > >>> 3945 (GMPLS Arch.) is not applicable to Ethernet. > > Why the doc. > > > > > >>> does not deliver any tangible explanation. > > > > > >> NH=3D> Is your problem that you cannot differentiate > > > between the 3 > > > > > >> network modes (of co-cs, co-ps and cl-ps)? > > > > > >=20 > > > > > > my concern wrt specific point you bring is that the today > > > > > definition in > > > > > > RFC 3945 for L2SC, and in the present case GMPLS for > > > > Ethernet (with > > > > > > local labels or domain-wide labels or any other equivalent > > > > > to "co-ps") > > > > > > does not result into a different definition than what's in. > > > > > on the other > > > > > > side, i do not see how would apply GMPLS for > > > > connectionless/bridged > > > > > > Ethernet. > > > > > >=20 > > > > > > note also that GMPLS induces label from the=20 > interface and link=20 > > > > > > characteristic (i.e. there is no "label type" in the > > > > > label/label request > > > > > > object. > > > > > >=20 > > > > > >> If so then looking at the work on > > > > > >> unified modelling in SG15/Q12 may help you. But to > > give a more > > > > > >> specific example here: We can take an Ethernet > > > traffic unit and > > > > > >> create either a cl-ps and co-ps layer network based on > > > this...in > > > > > >> fact one > > > > > can image 3 > > > > > >> different layer network cases here: > > > > > >> - traditional Etherent which does not have a=20 > > > > directed routing > > > > > >> function, ie uses MAC learning, broadcast unknown, > > > > STP...this is a > > > > > >> cl-ps layer network > > > > > >> - Ethernet with an IGP providing a directed routing > > > > > >> function....this is also a cl-ps layer network, but it is > > > > > different to > > > > > >> the one above > > > > > >> - Ethernet with a directed routing component=20 > > > > (centralised or > > > > > >> distributed, ie IGP) and a signalling component that > > can create > > > > > >> connections....this would be a co-ps layer network. > > > > > >> > > > > > >> These are all based on a similar traffic unit, however > > > > they form 3 > > > > > >> quite different layer networks (and in functional > > architecture > > > > > >> terms we would say 'the Characteristic Information is > > > > different in > > > > > >> the 3 cases'). > > > > > >> > > > > > >> Now GMPLS is applying a reusable set of CP components > > > > > (which is a very > > > > > >> good thing, as Ben points out below) for any co-cs or > > > > > co-ps mode layer > > > > > >> network. So we are setting up *connections* in > > either a space, > > > > > >> freq or time dimension of resource, and it is these > > 3 resource > > > > > dimensions that > > > > > >> create the differences in parameters...however, the > > notion of a > > > > > >> connection is common across all these resource dimensions. > > > > > GMPLS does > > > > > >> not apply to the cl-ps mode, as it plainly does not have > > > > > connections. > > > > > >=20 > > > > > > well indeed, and this is the reason why i do not see any > > > > reason to > > > > > > open the space for a different set of mechanisms that > > > > would result > > > > > > from this new interface switching definition. > > > > > >=20 > > > > > > thanks, > > > > > > -d. > > > > > > =20 > > > > > >> That is at least how I look at this issue. > > > > > >> > > > > > >> regards, Neil > > > > > >>>>> the question triggered by this poll is the following: if > > > > > >>> GMPLS for > > > > > >>>>> Ethernet is not inline with the existing stacks what is > > > > > >>> the value of > > > > > >>>>> GMPLS re-use ? what's the value to borrow the term GMPLS > > > > > >>> without its > > > > > >>>>> substance ? and in practice, the issue is, if it is not > > > > > >>>> GMPLS per RFC > > > > > >>>>> 3945, what's the value compared to any other > > native control > > > > > >>>> stack that > > > > > >>>>> would be developed at IEEE for inst. for these techno's. > > > > > >>>> If we ignore the peer model (which is unworkable in > > > > reality IMO), > > > >=20 > > > > > >>>> the value is obvious - significant reuse of=20 > existing code,=20 > > > > > >>>> techniques, knowledge, skills, etc. > > > > > >>>> > > > > > >>>> So, we should develop the control plane from scratch > > > > > >>> because Ethernet > > > > > >>>> requires a few modifications/enhancements (which I > > > believe are > > > > > >>>> backwards > > > > > >>>> compatible) to RFC3945 - that IMO is ridiculous. > > > > > >>> so you seem to agree with me. departing from RFC 3945 > > > > makes little > > > >=20 > > > > > >>> sense. it would have been interesting to see the doc > > > > delivering a > > > > > >>> FIT of the GMPLS protocol arch. blocks and, in > > > > particular, label > > > > > >>> allocation and distribution for Ethernet. > > > > > >>> > > > > > >>> thanks, > > > > > >>> -dimitri. > > > > > >>>> Ben > > > > > >>>> > > > > > >>>> > > > > > >>> > > > > > >=20 > > > > > >=20 > > > > > >=20 > > > > >=20 > > > > >=20 > > > > > -- > > > > > Loa Andersson > > > > >=20 > > > > > Principal Networking Architect > > > > > Acreo AB phone: +46 8 632 77 14 > > > > > Isafjordsgatan 22 mobile: +46 739 81 21 64 > > > > > Kista, Sweden email: =20 > > loa.andersson@acreo.se > > > > > loa@pi.se > > > > >=20 > > > >=20 > > > >=20 > > >=20 > >=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 30 Jan 2008 23:41:44 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Date: Thu, 31 Jan 2008 00:40:15 +0100 Message-ID: Thread-Topic: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Thread-Index: Achid4JetInOIvLXS36xGBjOv4vCdwAOqlZgAB8MVpAADGxFgAACaWoQAADUPSA= From: "PAPADIMITRIOU Dimitri" To: , , Cc: , , , , =20 neil,=20 > -----Original Message----- > From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]=20 > Sent: Wednesday, January 30, 2008 7:14 PM > To: PAPADIMITRIOU Dimitri; howard.green@ericsson.com; loa@pi.se > Cc: benjamin.niven-jenkins@bt.com; lberger@labn.net;=20 > dwfedyk@nortel.com; dbrungard@att.com; ccamp@ops.ietf.org > Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt >=20 > I personally think you are making a mountain out of a molehill here > Dimitri. =20 the segmentation of SCs we have in RFC 3945 is sufficient to address your below decomposition. you have to consider that when a new techno is to be supported by GMPLS, stacks are not going to change the full engine/stack per specific technology - > And I thought I had explained why there are differences in the > treatment of layer networks depending on their mode...I clearly did a > bad job. =20 don't worry, we very well understand the difference between a circuit-switched and packet-switched network.=20 > Sure GMPLS is a generic OOB CP suite of protocols, but the > details of the parameters used used to describe the layer=20 > network being > considered will depend on: > - for the co-cs mode whether we are dealing with resources which > are either regular time-slices, freq or space > - for the co-ps mode there is only irregular time-slices. L2SC is in the latter. =20 > And the labelling of such resource partitions is different in=20 > each case > too...so just like it is impossible to have a common (ie=20 > single instance > of) CP running 'IP to Optics' (or any functional component for that > matter) it is impossible to have an identical set of parameters > describing each mode....this is just the physics and the way=20 > it is. The > co-ps mode has the richest scope for 'variation' in the DP=20 > labelling of > traffic units (this is more than simply a destination proxy label > BTW....this was a point I saw Adrian alluding to)....and one can even > violate the rules of connections here and really screw-up any=20 > notion of deterministic resource management anyway. does that imply change in the def. of L2SC as defined in RFC 3945 ? or is it an add-on that is not impacting other RFC's mechanisms ? my understanding is the latter but never got an answer whether or not this is indeed the case (and proposal on how to spell this in the doc.) the addition to adrian's text is a way out. it is to be followed by discussions because the protocol aspects remain open.=20 thanks, -d. > regards, Neil=20 >=20 > > -----Original Message----- > > From: PAPADIMITRIOU Dimitri=20 > > [mailto:Dimitri.Papadimitriou@alcatel-lucent.be]=20 > > Sent: 30 January 2008 17:23 > > To: Howard Green; Loa Andersson > > Cc: Harrison,N,Neil,DMF R; Niven-jenkins,B,Ben,DMF R;=20 > > lberger@labn.net; dwfedyk@nortel.com; dbrungard@att.com;=20 > > ccamp@ops.ietf.org > > Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt > >=20 > >=20 > > =20 > >=20 > > > -----Original Message----- > > > From: Howard Green [mailto:howard.green@ericsson.com] > > > Sent: Wednesday, January 30, 2008 12:09 PM > > > To: PAPADIMITRIOU Dimitri; Loa Andersson > > > Cc: neil.2.harrison@bt.com; benjamin.niven-jenkins@bt.com;=20 > > > lberger@labn.net; dwfedyk@nortel.com; dbrungard@att.com;=20 > > > ccamp@ops.ietf.org > > > Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt > > >=20 > > > Hi > > > Dimitri seems to me to be making a very abstract and=20 > > legalistic point. > >=20 > > receive my total disagreement. an individual submission that=20 > > asks to change an existing RFC requires discussion and=20 > > particular attention (in part., when it is the protocol arch.=20 > > document) - if this not possible then probably you have to=20 > > write also a doc. asking for changing the IETF proces - and=20 > > then you come back with your individual submission. > > =20 > > > The reason why this work is important is that the IEEE has > > > been evolving > > > Ethernet to give it carrier class features, in respect of=20 > > scalability, > > > OAM, and (with 802.1Qay) the possibility to use an=20 > external control > > > plane.=20 > >=20 > > no one i think question this. and i don't think the poll is=20 > > on this specific point. CCAMP or even IETF at large is not an=20 > > authority to decide upon IEEE technos. > >=20 > > > Some of these features will very likely require or enable=20 > > added value=20 > > > from extensions to the functionality of GMPLS - for=20 > example, as has=20 > > > already been suggested, the addition of functionality=20 > for creating=20 > > > the OAM associations. > >=20 > > indeed, and your colleague has already received a list of=20 > > comments to be addressed before seeing any way forward w/ the=20 > > proposed approach.=20 > >=20 > > > Therefore this will likely not be the same as the > > > possible use suggested in RFC3945, which may (at least > > > in theory) have been implemented somewhere.=20 > >=20 > > the exact problem, i mentionned a couple of times. your own=20 > > comment shows that one may use GMPLS differently but may i=20 > > ask WHY ? and what's the implications ? > >=20 > > > Therefore the suggestion in the draft seems to make sense. > >=20 > > why ? > >=20 > > > I can't really see what important principle is being > > > defended by the insistence upon L2SC, which, as Don Fedyk=20 > > stated, was=20 > > > always somewhat underspecified. > >=20 > > THE reason is that an interface SC or a related functionality=20 > > has never resulted in a specific change in the base protocol=20 > > building blocks. GMPLS is a generalized approach not a=20 > > differentiated approach per interface. > >=20 > > actually your last statement is not correct (L2SC is well=20 > > specified in RFC 3945) AND by the way yours does not at all=20 > > better specify it. > >=20 > > > This is not something to be debated in the abstract. The=20 > > work in ccamp=20 > > > should allow sensible extension of functionality where it=20 > > adds value,=20 > > > and this needs to be discussed on a case by case basis.=20 > > Therefore we=20 > > > should make it a working group document and get on with it. > >=20 > > -d. > > > regards Howard Green > > >=20 > > > -----Original Message----- > > > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On=20 > > > Behalf Of PAPADIMITRIOU Dimitri > > > Sent: 30 January 2008 10:15 > > > To: Loa Andersson > > > Cc: neil.2.harrison@bt.com; benjamin.niven-jenkins@bt.com;=20 > > > lberger@labn.net; dwfedyk@nortel.com; dbrungard@att.com;=20 > > > ccamp@ops.ietf.org > > > Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt > > >=20 > > > loa, > > >=20 > > >=20 > > > i think the main point as ccamp is whether or not we poll=20 > > for a change=20 > > > or a continuation inline with RFC3945 -- when the present=20 > > doc. states: > > >=20 > > > "It is expected that there will be no > > > case where an Eth-LSP will be signaled, or an Eth-LSP=20 > supporting > > > interface will be represented, using the L2SC switching > > > type/capability. A new switching type/capability is=20 > required to > > > avoid any potential current usage of the L2SC switching > > > type/capability in support of Ethernet. > > >=20 > > > [...] > > >=20 > > > "The L2SC Interface Switching Capabilities MUST > > > NOT be used to represent interfaces capable of supporting > > > Eth-LSPs." > > >=20 > > > it raises three issues: > > >=20 > > > a) what was the previous L2SC def. per RFC 3945 meant for if > > > not for use > > > also in GMPLS Ethernet context ? > > >=20 > > > b) why a "new one" ? > > >=20 > > > this is not explained. > > >=20 > > > c) what is the "new one" implying in terms of GMPLS ? > > >=20 > > > for inst. in the intro "The intent of this document is to=20 > reuse and=20 > > > align with as much of the GMPLS protocols as possible."=20 > leaves open=20 > > > the issue of what as much as possible means. > > >=20 > > > and on the other "Additions are made only to accommodate=20 > > features of=20 > > > Ethernet that are not already supported by GMPLS." so,=20 > how shall i=20 > > > interpreet the first sentence now ? inline with point a) and b) ? > > >=20 > > >=20 > > > the doc. in WG I-D status or not is not going to provide an=20 > > answer to=20 > > > these questions. sentences and statements in the doc.=20 > > contradict each=20 > > > other. > > >=20 > > > thanks, > > > -d. > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > > > -----Original Message----- > > > > From: Loa Andersson [mailto:loa@pi.se] > > > > Sent: Tuesday, January 29, 2008 2:04 PM > > > > To: PAPADIMITRIOU Dimitri > > > > Cc: neil.2.harrison@bt.com; benjamin.niven-jenkins@bt.com; > > > > lberger@labn.net; dwfedyk@nortel.com; dbrungard@att.com;=20 > > > > ccamp@ops.ietf.org > > > > Subject: Re: Proposed WG Draft -=20 > draft-gmpls-ethernet-arch-00.txt > > > >=20 > > > > Dimitri, > > > >=20 > > > > it is possible that you have a point that needs to be > > > discussed, but > > > > is this really something that should stop us from adopting > > > the doc as > > > > a working group document. > > > >=20 > > > > /Loa > > > >=20 > > > > PAPADIMITRIOU Dimitri wrote: > > > > > neil, > > > > >=20 > > > > >> -----Original Message----- > > > > >> From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] > > > > >> Sent: Friday, January 25, 2008 2:27 PM > > > > >> To: PAPADIMITRIOU Dimitri; benjamin.niven-jenkins@bt.com; > > > > >> lberger@labn.net > > > > >> Cc: dwfedyk@nortel.com; dbrungard@att.com; ccamp@ops.ietf.org > > > > >> Subject: RE: Proposed WG Draft -=20 > > draft-gmpls-ethernet-arch-00.txt > > > > >> > > > > >> Dimitri....see if this helps...in-line > > > > >> > > > > >>> -----Original Message----- > > > > >>> From: owner-ccamp@ops.ietf.org=20 > > [mailto:owner-ccamp@ops.ietf.org]=20 > > > > >>> On Behalf Of > > > > PAPADIMITRIOU Dimitri > > > > >>> Sent: 25 January 2008 11:36 > > > > >>> To: Niven-jenkins,B,Ben,DMF R; Lou Berger > > > > >>> Cc: Don Fedyk; BRUNGARD, DEBORAH A, ATTLABS;=20 > > ccamp@ops.ietf.org > > > > >>> Subject: RE: Proposed WG Draft - > > > draft-gmpls-ethernet-arch-00.txt > > > > >>> > > > > >>> > > > > >>> ben > > > > >>> > > > > >>>> -----Original Message----- > > > > >>>> From: Ben Niven-Jenkins=20 > > [mailto:benjamin.niven-jenkins@bt.com] > > > > >>>> Sent: Thursday, January 24, 2008 3:40 PM > > > > >>>> To: PAPADIMITRIOU Dimitri; Lou Berger > > > > >>>> Cc: Don Fedyk; BRUNGARD, DEBORAH A, ATTLABS;=20 > > ccamp@ops.ietf.org > > > > >>>> Subject: Re: Proposed WG Draft - > > > draft-gmpls-ethernet-arch-00.txt > > > > >>>> > > > > >>>> Dimitri, > > > > >>>> > > > > >>>> I find your mail somewhat puzzling. > > > > >>>> > > > > >>>> You appear to be saying that GMPLS as per RFC 3945 is set > > > > >>> in stone and > > > > >>>> nothing should modify/enhance the behaviour as specified > > > > >> in RFC3945 > > > > >>>> which implies that when RFC3945 was produced the crystal > > > > ball was > > > > >>>> working extremely well and all possible future > > > > applications of the > > > > >>>> technology had > > > > >>>> been correctly envisaged. I don't believe that=20 > was the case. > > > > >>> this is not what i say. i am concerned in stating > > > beforehand RFC > > > > >>> 3945 (GMPLS Arch.) is not applicable to Ethernet.=20 > Why the doc. > > > > >>> does not deliver any tangible explanation. > > > > >> NH=3D> Is your problem that you cannot differentiate=20 > > between the 3 > > > > >> network modes (of co-cs, co-ps and cl-ps)? > > > > >=20 > > > > > my concern wrt specific point you bring is that the today > > > > definition in > > > > > RFC 3945 for L2SC, and in the present case GMPLS for > > > Ethernet (with > > > > > local labels or domain-wide labels or any other equivalent > > > > to "co-ps") > > > > > does not result into a different definition than what's in. > > > > on the other > > > > > side, i do not see how would apply GMPLS for > > > connectionless/bridged > > > > > Ethernet. > > > > >=20 > > > > > note also that GMPLS induces label from the interface and link > > > > > characteristic (i.e. there is no "label type" in the > > > > label/label request > > > > > object. > > > > >=20 > > > > >> If so then looking at the work on > > > > >> unified modelling in SG15/Q12 may help you. But to=20 > give a more > > > > >> specific example here: We can take an Ethernet=20 > > traffic unit and=20 > > > > >> create either a cl-ps and co-ps layer network based on=20 > > this...in=20 > > > > >> fact one > > > > can image 3 > > > > >> different layer network cases here: > > > > >> - traditional Etherent which does not have a=20 > > > directed routing > > > > >> function, ie uses MAC learning, broadcast unknown, > > > STP...this is a > > > > >> cl-ps layer network > > > > >> - Ethernet with an IGP providing a directed routing > > > > >> function....this is also a cl-ps layer network, but it is > > > > different to > > > > >> the one above > > > > >> - Ethernet with a directed routing component=20 > > > (centralised or > > > > >> distributed, ie IGP) and a signalling component that=20 > can create > > > > >> connections....this would be a co-ps layer network. > > > > >> > > > > >> These are all based on a similar traffic unit, however > > > they form 3 > > > > >> quite different layer networks (and in functional=20 > architecture > > > > >> terms we would say 'the Characteristic Information is=20 > > > different in > > > > >> the 3 cases'). > > > > >> > > > > >> Now GMPLS is applying a reusable set of CP components > > > > (which is a very > > > > >> good thing, as Ben points out below) for any co-cs or > > > > co-ps mode layer > > > > >> network. So we are setting up *connections* in=20 > either a space, > > > > >> freq or time dimension of resource, and it is these=20 > 3 resource > > > > dimensions that > > > > >> create the differences in parameters...however, the=20 > notion of a > > > > >> connection is common across all these resource dimensions. > > > > GMPLS does > > > > >> not apply to the cl-ps mode, as it plainly does not have > > > > connections. > > > > >=20 > > > > > well indeed, and this is the reason why i do not see any > > > reason to > > > > > open the space for a different set of mechanisms that > > > would result > > > > > from this new interface switching definition. > > > > >=20 > > > > > thanks, > > > > > -d. > > > > > =20 > > > > >> That is at least how I look at this issue. > > > > >> > > > > >> regards, Neil > > > > >>>>> the question triggered by this poll is the following: if > > > > >>> GMPLS for > > > > >>>>> Ethernet is not inline with the existing stacks what is > > > > >>> the value of > > > > >>>>> GMPLS re-use ? what's the value to borrow the term GMPLS > > > > >>> without its > > > > >>>>> substance ? and in practice, the issue is, if it is not > > > > >>>> GMPLS per RFC > > > > >>>>> 3945, what's the value compared to any other=20 > native control > > > > >>>> stack that > > > > >>>>> would be developed at IEEE for inst. for these techno's. > > > > >>>> If we ignore the peer model (which is unworkable in > > > reality IMO), > > >=20 > > > > >>>> the value is obvious - significant reuse of existing code, > > > > >>>> techniques, knowledge, skills, etc. > > > > >>>> > > > > >>>> So, we should develop the control plane from scratch > > > > >>> because Ethernet > > > > >>>> requires a few modifications/enhancements (which I=20 > > believe are > > > > >>>> backwards > > > > >>>> compatible) to RFC3945 - that IMO is ridiculous. > > > > >>> so you seem to agree with me. departing from RFC 3945 > > > makes little > > >=20 > > > > >>> sense. it would have been interesting to see the doc > > > delivering a > > > > >>> FIT of the GMPLS protocol arch. blocks and, in > > > particular, label > > > > >>> allocation and distribution for Ethernet. > > > > >>> > > > > >>> thanks, > > > > >>> -dimitri. > > > > >>>> Ben > > > > >>>> > > > > >>>> > > > > >>> > > > > >=20 > > > > >=20 > > > > >=20 > > > >=20 > > > >=20 > > > > -- > > > > Loa Andersson > > > >=20 > > > > Principal Networking Architect > > > > Acreo AB phone: +46 8 632 77 14 > > > > Isafjordsgatan 22 mobile: +46 739 81 21 64 > > > > Kista, Sweden email: =20 > loa.andersson@acreo.se > > > > loa@pi.se > > > >=20 > > >=20 > > >=20 > >=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 30 Jan 2008 21:49:01 +0000 Date: Wed, 30 Jan 2008 16:47:29 -0500 To: "Adrian Farrel" From: Lou Berger Subject: Re: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Cc: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-Id: Adrian, This seems workable to me. Also, I don't think it was the intent of the draft to preclude use of L2SC for current applications, but rather to use new values for the new types of ether switching. I think your text disambiguates this issue. Lou At 10:27 AM 1/30/2008, Adrian Farrel wrote: >All, > >We appear to be seeing good support for this document, and that >suggests that we should take it forward, but I would like to at >least make an attempt to close down the point raised by Dimitri. As >Howard points out, this is in danger of becoming a legalistic >discussion, but I've never been one to refuse the opportunity to >back to first principles... > >In RFC 3945 we have... > > A link may support a set of encoding formats, where support means > that a link is able to carry and switch a signal of one or more of > these encoding formats. The Switching Type indicates then the type > of switching that should be performed on a particular link for that > LSP. This information is needed for links that advertise more than > one type of switching capability. > > Nodes must verify that the type indicated in the Switching Type is > supported on the corresponding incoming interface; otherwise, the > node must generate a notification message with a "Routing > problem/Switching Type" indication. > >Now, the question is whether we are introducing one (or more) new >Switching Type and whether we need to be able to distinguish between >them. Suppose (for the sake of argument) that we will over time >introduce the ability to switch Ethernet frames under GMPLS control >based on several different label concepts: >- 802.1Qay >- destination MAC only >- destination MAC and VLAN tag >It is likely that a GMPLS-capable Ethernet switch will want to >support more than one of these switching paradigms on any single >interface. So we have to decide how, during signaling, we indicate >which type of LSP is requested. > >There are plenty of ways that this could be done. Currently we use a >combination of the parameters of the Generalized_Label_Request >object and the Sender_TSpec object. The TSpec is used in the case of >TDM (RFC 4606) and Ethernet to distinguish the Switching Granularity >(draft-ietf-ccamp-ethernet-traffic-parameters). > >As I see it, the text at issue in draft-gmpls-ethernet-arch-00.txt >causes a problem because it appears to say that *no* Ethernet Label >Switched Path (Eth-LSP) can be set up using an L2SC Switching Type. > It is expected that there will be no > case where an Eth-LSP will be signaled, or an Eth-LSP supporting > interface will be represented, using the L2SC switching > type/capability. > >However, the draft also says... > A new switching type/capability is required to > avoid any potential current usage of the L2SC switching > type/capability in support of Ethernet. > >And this clearly says that L2SC *is* allowed. > >Can we fix this by agreeing some new wording? > >== >OLD > This document does not define any specific format for an Eth-LSP > label. Rather, it is expected that service specific documents will > define any signaling and routing extensions needed to support that > specific Ethernet service. Depending on the requirements of a > service, it may be necessary to define multiple GMPLS extensions, > e.g., label formats, switching types, and Traffic Engineering (TE) > routing extensions. It is expected that all such extensions will be > consistent with this document. It is expected that there will be no > case where an Eth-LSP will be signaled, or an Eth-LSP supporting > interface will be represented, using the L2SC switching > type/capability. A new switching type/capability is required to > avoid any potential current usage of the L2SC switching > type/capability in support of Ethernet. >NEW > This document does not define any specific format for an Eth-LSP > label. Rather, it is expected that service specific documents will > define any signaling and routing extensions needed to support that > specific Ethernet service. Depending on the requirements of a > service, it may be necessary to define multiple GMPLS protocol > extensions and procedures. It is expected that all such extensions > will be consistent with this document. > > It is expected that key a requirement will be to describe label > formats and encodings. It may also be necessary to provide a > mechanism to identify the required Ethernet service type in signaling > and a way to advertise the capabilities of Ethernet switches in the > routing protocols. These mechanisms must make it possible to > distinguish between requests for different paradigms including new, > future, and existing paradigms. > > The Switching Type and Interface Switching Capability Descriptor > share a common set of values and are defined in [RFC3945], [RFC3471], > and [RFC4202] as indicators of the type of switching that should > ([RFC3471]) and can ([RFC4202]) be performed on a particular link for > an LSP. The L2SC switching type is available for use by > implementations performing layer 2 switching including ATM and > Ethernet. To support the continued use of that switching type by > existing implementations as well as to distinguish between each new > Ethernet switching paradigm, a new switching type is expected to be > needed for each new Ethernet switching paradigm that is supported. >== > >Thanks, >Adrian > > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 30 Jan 2008 18:39:51 +0000 Message-ID: <0edc01c8636f$65f4c980$0200a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "PAPADIMITRIOU Dimitri" , Subject: Re: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Date: Wed, 30 Jan 2008 18:39:02 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Dimitri, Thanks. Editors, Please submit your I-D as draft-ietf-ccamp-gmpls-ethernet-arch-00.txt making the changes described below. Thanks, Adrian ----- Original Message ----- From: "PAPADIMITRIOU Dimitri" To: "Adrian Farrel" ; Sent: Wednesday, January 30, 2008 6:32 PM Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt adrian > -----Original Message----- > From: owner-ccamp@ops.ietf.org > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel > Sent: Wednesday, January 30, 2008 4:28 PM > To: ccamp@ops.ietf.org > Subject: Re: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt > > All, > > We appear to be seeing good support for this document, and > that suggests > that we should take it forward, but I would like to at least > make an attempt > to close down the point raised by Dimitri. As Howard points > out, this is in > danger of becoming a legalistic discussion, but I've never > been one to > refuse the opportunity to back to first principles... > > In RFC 3945 we have... > > A link may support a set of encoding formats, where support means > that a link is able to carry and switch a signal of one or more of > these encoding formats. The Switching Type indicates then the type > of switching that should be performed on a particular link for that > LSP. This information is needed for links that advertise more than > one type of switching capability. > > Nodes must verify that the type indicated in the Switching Type is > supported on the corresponding incoming interface; otherwise, the > node must generate a notification message with a "Routing > problem/Switching Type" indication. > > Now, the question is whether we are introducing one (or more) > new Switching > Type and whether we need to be able to distinguish between > them. Suppose > (for the sake of argument) that we will over time introduce > the ability to > switch Ethernet frames under GMPLS control based on several > different label > concepts: > - 802.1Qay > - destination MAC only > - destination MAC and VLAN tag > It is likely that a GMPLS-capable Ethernet switch will want > to support more > than one of these switching paradigms on any single > interface. So we have to > decide how, during signaling, we indicate which type of LSP > is requested. > > There are plenty of ways that this could be done. Currently we use a > combination of the parameters of the > Generalized_Label_Request object and > the Sender_TSpec object. The TSpec is used in the case of TDM > (RFC 4606) and > Ethernet to distinguish the Switching Granularity > (draft-ietf-ccamp-ethernet-traffic-parameters). > > As I see it, the text at issue in > draft-gmpls-ethernet-arch-00.txt causes a > problem because it appears to say that *no* Ethernet Label > Switched Path > (Eth-LSP) can be set up using an L2SC Switching Type. > It is expected that there will be no > case where an Eth-LSP will be signaled, or an Eth-LSP supporting > interface will be represented, using the L2SC switching > type/capability. > > However, the draft also says... > A new switching type/capability is required to > avoid any potential current usage of the L2SC switching > type/capability in support of Ethernet. > > And this clearly says that L2SC *is* allowed. > > Can we fix this by agreeing some new wording? > > == > OLD > This document does not define any specific format for an Eth-LSP > label. Rather, it is expected that service specific documents will > define any signaling and routing extensions needed to support that > specific Ethernet service. Depending on the requirements of a > service, it may be necessary to define multiple GMPLS extensions, > e.g., label formats, switching types, and Traffic Engineering (TE) > routing extensions. It is expected that all such > extensions will be > consistent with this document. It is expected that there will be no > case where an Eth-LSP will be signaled, or an Eth-LSP supporting > interface will be represented, using the L2SC switching > type/capability. A new switching type/capability is required to > avoid any potential current usage of the L2SC switching > type/capability in support of Ethernet. > NEW > This document does not define any specific format for an Eth-LSP > label. Rather, it is expected that service specific documents will > define any signaling and routing extensions needed to support that > specific Ethernet service. Depending on the requirements of a > service, it may be necessary to define multiple GMPLS protocol > extensions and procedures. It is expected that all such extensions > will be consistent with this document. > > It is expected that key a requirement will be to describe label > formats and encodings. It may also be necessary to provide a > mechanism to identify the required Ethernet service type > in signaling > and a way to advertise the capabilities of Ethernet switches in the > routing protocols. These mechanisms must make it possible to > distinguish between requests for different paradigms including new, > future, and existing paradigms. > > The Switching Type and Interface Switching Capability Descriptor > share a common set of values and are defined in [RFC3945], > [RFC3471], > and [RFC4202] as indicators of the type of switching that should > ([RFC3471]) and can ([RFC4202]) be performed on a > particular link for > an LSP. The L2SC switching type is available for use by > implementations performing layer 2 switching including ATM and > Ethernet. To support the continued use of that switching type by > existing implementations as well as to distinguish between each new > Ethernet switching paradigm, a new switching type is expected to be > needed for each new Ethernet switching paradigm that is supported. i can live with this at the condition that a statement is added about either we do ack assessment on further implications or do not imply any change on other GMPLS building blocks (note: there is a main difference between change and extensions). thanks, -d. > == > > Thanks, > Adrian > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 30 Jan 2008 18:33:54 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Date: Wed, 30 Jan 2008 19:32:32 +0100 Message-ID: Thread-Topic: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Thread-Index: AchjVQ4iCRP3GvaQReiaKOLk76rorgAGLI+A From: "PAPADIMITRIOU Dimitri" To: "Adrian Farrel" , adrian=20 > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel > Sent: Wednesday, January 30, 2008 4:28 PM > To: ccamp@ops.ietf.org > Subject: Re: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt >=20 > All, >=20 > We appear to be seeing good support for this document, and=20 > that suggests=20 > that we should take it forward, but I would like to at least=20 > make an attempt=20 > to close down the point raised by Dimitri. As Howard points=20 > out, this is in=20 > danger of becoming a legalistic discussion, but I've never=20 > been one to=20 > refuse the opportunity to back to first principles... >=20 > In RFC 3945 we have... >=20 > A link may support a set of encoding formats, where support means > that a link is able to carry and switch a signal of one or more of > these encoding formats. The Switching Type indicates then the type > of switching that should be performed on a particular link for that > LSP. This information is needed for links that advertise more than > one type of switching capability. >=20 > Nodes must verify that the type indicated in the Switching Type is > supported on the corresponding incoming interface; otherwise, the > node must generate a notification message with a "Routing > problem/Switching Type" indication. >=20 > Now, the question is whether we are introducing one (or more)=20 > new Switching=20 > Type and whether we need to be able to distinguish between=20 > them. Suppose=20 > (for the sake of argument) that we will over time introduce=20 > the ability to=20 > switch Ethernet frames under GMPLS control based on several=20 > different label=20 > concepts: > - 802.1Qay > - destination MAC only > - destination MAC and VLAN tag > It is likely that a GMPLS-capable Ethernet switch will want=20 > to support more=20 > than one of these switching paradigms on any single=20 > interface. So we have to=20 > decide how, during signaling, we indicate which type of LSP=20 > is requested. >=20 > There are plenty of ways that this could be done. Currently we use a=20 > combination of the parameters of the=20 > Generalized_Label_Request object and=20 > the Sender_TSpec object. The TSpec is used in the case of TDM=20 > (RFC 4606) and=20 > Ethernet to distinguish the Switching Granularity=20 > (draft-ietf-ccamp-ethernet-traffic-parameters). >=20 > As I see it, the text at issue in=20 > draft-gmpls-ethernet-arch-00.txt causes a=20 > problem because it appears to say that *no* Ethernet Label=20 > Switched Path=20 > (Eth-LSP) can be set up using an L2SC Switching Type. > It is expected that there will be no > case where an Eth-LSP will be signaled, or an Eth-LSP supporting > interface will be represented, using the L2SC switching > type/capability. >=20 > However, the draft also says... > A new switching type/capability is required to > avoid any potential current usage of the L2SC switching > type/capability in support of Ethernet. >=20 > And this clearly says that L2SC *is* allowed. >=20 > Can we fix this by agreeing some new wording? >=20 > =3D=3D > OLD > This document does not define any specific format for an Eth-LSP > label. Rather, it is expected that service specific documents will > define any signaling and routing extensions needed to support that > specific Ethernet service. Depending on the requirements of a > service, it may be necessary to define multiple GMPLS extensions, > e.g., label formats, switching types, and Traffic Engineering (TE) > routing extensions. It is expected that all such=20 > extensions will be > consistent with this document. It is expected that there will be no > case where an Eth-LSP will be signaled, or an Eth-LSP supporting > interface will be represented, using the L2SC switching > type/capability. A new switching type/capability is required to > avoid any potential current usage of the L2SC switching > type/capability in support of Ethernet. > NEW > This document does not define any specific format for an Eth-LSP > label. Rather, it is expected that service specific documents will > define any signaling and routing extensions needed to support that > specific Ethernet service. Depending on the requirements of a > service, it may be necessary to define multiple GMPLS protocol > extensions and procedures. It is expected that all such extensions > will be consistent with this document. >=20 > It is expected that key a requirement will be to describe label > formats and encodings. It may also be necessary to provide a > mechanism to identify the required Ethernet service type=20 > in signaling > and a way to advertise the capabilities of Ethernet switches in the > routing protocols. These mechanisms must make it possible to > distinguish between requests for different paradigms including new, > future, and existing paradigms. >=20 > The Switching Type and Interface Switching Capability Descriptor > share a common set of values and are defined in [RFC3945],=20 > [RFC3471], > and [RFC4202] as indicators of the type of switching that should > ([RFC3471]) and can ([RFC4202]) be performed on a=20 > particular link for > an LSP. The L2SC switching type is available for use by > implementations performing layer 2 switching including ATM and > Ethernet. To support the continued use of that switching type by > existing implementations as well as to distinguish between each new > Ethernet switching paradigm, a new switching type is expected to be > needed for each new Ethernet switching paradigm that is supported. i can live with this at the condition that a statement is added about either we do ack assessment on further implications or do not imply any change on other GMPLS building blocks (note: there is a main difference between change and extensions). thanks, -d.=20 > =3D=3D >=20 > Thanks, > Adrian=20 >=20 >=20 >=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 30 Jan 2008 18:14:33 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Date: Wed, 30 Jan 2008 18:13:34 -0000 Message-ID: <2ECAA42C79676B42AEBAC11229CA7D0C01D4269F@E03MVB2-UKBR.domain1.systemhost.net> Thread-Topic: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Thread-Index: Achid4JetInOIvLXS36xGBjOv4vCdwAOqlZgAB8MVpAADGxFgAACaWoQ From: To: , , Cc: , , , , I personally think you are making a mountain out of a molehill here Dimitri. And I thought I had explained why there are differences in the treatment of layer networks depending on their mode...I clearly did a bad job. Sure GMPLS is a generic OOB CP suite of protocols, but the details of the parameters used used to describe the layer network being considered will depend on: - for the co-cs mode whether we are dealing with resources which are either regular time-slices, freq or space - for the co-ps mode there is only irregular time-slices. And the labelling of such resource partitions is different in each case too...so just like it is impossible to have a common (ie single instance of) CP running 'IP to Optics' (or any functional component for that matter) it is impossible to have an identical set of parameters describing each mode....this is just the physics and the way it is. The co-ps mode has the richest scope for 'variation' in the DP labelling of traffic units (this is more than simply a destination proxy label BTW....this was a point I saw Adrian alluding to)....and one can even violate the rules of connections here and really screw-up any notion of deterministic resource management anyway. regards, Neil=20 > -----Original Message----- > From: PAPADIMITRIOU Dimitri=20 > [mailto:Dimitri.Papadimitriou@alcatel-lucent.be]=20 > Sent: 30 January 2008 17:23 > To: Howard Green; Loa Andersson > Cc: Harrison,N,Neil,DMF R; Niven-jenkins,B,Ben,DMF R;=20 > lberger@labn.net; dwfedyk@nortel.com; dbrungard@att.com;=20 > ccamp@ops.ietf.org > Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt >=20 >=20 > =20 >=20 > > -----Original Message----- > > From: Howard Green [mailto:howard.green@ericsson.com] > > Sent: Wednesday, January 30, 2008 12:09 PM > > To: PAPADIMITRIOU Dimitri; Loa Andersson > > Cc: neil.2.harrison@bt.com; benjamin.niven-jenkins@bt.com;=20 > > lberger@labn.net; dwfedyk@nortel.com; dbrungard@att.com;=20 > > ccamp@ops.ietf.org > > Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt > >=20 > > Hi > > Dimitri seems to me to be making a very abstract and=20 > legalistic point. >=20 > receive my total disagreement. an individual submission that=20 > asks to change an existing RFC requires discussion and=20 > particular attention (in part., when it is the protocol arch.=20 > document) - if this not possible then probably you have to=20 > write also a doc. asking for changing the IETF proces - and=20 > then you come back with your individual submission. > =20 > > The reason why this work is important is that the IEEE has > > been evolving > > Ethernet to give it carrier class features, in respect of=20 > scalability, > > OAM, and (with 802.1Qay) the possibility to use an external control > > plane.=20 >=20 > no one i think question this. and i don't think the poll is=20 > on this specific point. CCAMP or even IETF at large is not an=20 > authority to decide upon IEEE technos. >=20 > > Some of these features will very likely require or enable=20 > added value=20 > > from extensions to the functionality of GMPLS - for example, as has=20 > > already been suggested, the addition of functionality for creating=20 > > the OAM associations. >=20 > indeed, and your colleague has already received a list of=20 > comments to be addressed before seeing any way forward w/ the=20 > proposed approach.=20 >=20 > > Therefore this will likely not be the same as the > > possible use suggested in RFC3945, which may (at least > > in theory) have been implemented somewhere.=20 >=20 > the exact problem, i mentionned a couple of times. your own=20 > comment shows that one may use GMPLS differently but may i=20 > ask WHY ? and what's the implications ? >=20 > > Therefore the suggestion in the draft seems to make sense. >=20 > why ? >=20 > > I can't really see what important principle is being > > defended by the insistence upon L2SC, which, as Don Fedyk=20 > stated, was=20 > > always somewhat underspecified. >=20 > THE reason is that an interface SC or a related functionality=20 > has never resulted in a specific change in the base protocol=20 > building blocks. GMPLS is a generalized approach not a=20 > differentiated approach per interface. >=20 > actually your last statement is not correct (L2SC is well=20 > specified in RFC 3945) AND by the way yours does not at all=20 > better specify it. >=20 > > This is not something to be debated in the abstract. The=20 > work in ccamp=20 > > should allow sensible extension of functionality where it=20 > adds value,=20 > > and this needs to be discussed on a case by case basis.=20 > Therefore we=20 > > should make it a working group document and get on with it. >=20 > -d. > > regards Howard Green > >=20 > > -----Original Message----- > > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On=20 > > Behalf Of PAPADIMITRIOU Dimitri > > Sent: 30 January 2008 10:15 > > To: Loa Andersson > > Cc: neil.2.harrison@bt.com; benjamin.niven-jenkins@bt.com;=20 > > lberger@labn.net; dwfedyk@nortel.com; dbrungard@att.com;=20 > > ccamp@ops.ietf.org > > Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt > >=20 > > loa, > >=20 > >=20 > > i think the main point as ccamp is whether or not we poll=20 > for a change=20 > > or a continuation inline with RFC3945 -- when the present=20 > doc. states: > >=20 > > "It is expected that there will be no > > case where an Eth-LSP will be signaled, or an Eth-LSP supporting > > interface will be represented, using the L2SC switching > > type/capability. A new switching type/capability is required to > > avoid any potential current usage of the L2SC switching > > type/capability in support of Ethernet. > >=20 > > [...] > >=20 > > "The L2SC Interface Switching Capabilities MUST > > NOT be used to represent interfaces capable of supporting > > Eth-LSPs." > >=20 > > it raises three issues: > >=20 > > a) what was the previous L2SC def. per RFC 3945 meant for if > > not for use > > also in GMPLS Ethernet context ? > >=20 > > b) why a "new one" ? > >=20 > > this is not explained. > >=20 > > c) what is the "new one" implying in terms of GMPLS ? > >=20 > > for inst. in the intro "The intent of this document is to reuse and=20 > > align with as much of the GMPLS protocols as possible." leaves open=20 > > the issue of what as much as possible means. > >=20 > > and on the other "Additions are made only to accommodate=20 > features of=20 > > Ethernet that are not already supported by GMPLS." so, how shall i=20 > > interpreet the first sentence now ? inline with point a) and b) ? > >=20 > >=20 > > the doc. in WG I-D status or not is not going to provide an=20 > answer to=20 > > these questions. sentences and statements in the doc.=20 > contradict each=20 > > other. > >=20 > > thanks, > > -d. > >=20 > >=20 > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: Loa Andersson [mailto:loa@pi.se] > > > Sent: Tuesday, January 29, 2008 2:04 PM > > > To: PAPADIMITRIOU Dimitri > > > Cc: neil.2.harrison@bt.com; benjamin.niven-jenkins@bt.com; > > > lberger@labn.net; dwfedyk@nortel.com; dbrungard@att.com;=20 > > > ccamp@ops.ietf.org > > > Subject: Re: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt > > >=20 > > > Dimitri, > > >=20 > > > it is possible that you have a point that needs to be > > discussed, but > > > is this really something that should stop us from adopting > > the doc as > > > a working group document. > > >=20 > > > /Loa > > >=20 > > > PAPADIMITRIOU Dimitri wrote: > > > > neil, > > > >=20 > > > >> -----Original Message----- > > > >> From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] > > > >> Sent: Friday, January 25, 2008 2:27 PM > > > >> To: PAPADIMITRIOU Dimitri; benjamin.niven-jenkins@bt.com; > > > >> lberger@labn.net > > > >> Cc: dwfedyk@nortel.com; dbrungard@att.com; ccamp@ops.ietf.org > > > >> Subject: RE: Proposed WG Draft -=20 > draft-gmpls-ethernet-arch-00.txt > > > >> > > > >> Dimitri....see if this helps...in-line > > > >> > > > >>> -----Original Message----- > > > >>> From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org]=20 > > > >>> On Behalf Of > > > PAPADIMITRIOU Dimitri > > > >>> Sent: 25 January 2008 11:36 > > > >>> To: Niven-jenkins,B,Ben,DMF R; Lou Berger > > > >>> Cc: Don Fedyk; BRUNGARD, DEBORAH A, ATTLABS;=20 > ccamp@ops.ietf.org > > > >>> Subject: RE: Proposed WG Draft - > > draft-gmpls-ethernet-arch-00.txt > > > >>> > > > >>> > > > >>> ben > > > >>> > > > >>>> -----Original Message----- > > > >>>> From: Ben Niven-Jenkins=20 > [mailto:benjamin.niven-jenkins@bt.com] > > > >>>> Sent: Thursday, January 24, 2008 3:40 PM > > > >>>> To: PAPADIMITRIOU Dimitri; Lou Berger > > > >>>> Cc: Don Fedyk; BRUNGARD, DEBORAH A, ATTLABS;=20 > ccamp@ops.ietf.org > > > >>>> Subject: Re: Proposed WG Draft - > > draft-gmpls-ethernet-arch-00.txt > > > >>>> > > > >>>> Dimitri, > > > >>>> > > > >>>> I find your mail somewhat puzzling. > > > >>>> > > > >>>> You appear to be saying that GMPLS as per RFC 3945 is set > > > >>> in stone and > > > >>>> nothing should modify/enhance the behaviour as specified > > > >> in RFC3945 > > > >>>> which implies that when RFC3945 was produced the crystal > > > ball was > > > >>>> working extremely well and all possible future > > > applications of the > > > >>>> technology had > > > >>>> been correctly envisaged. I don't believe that was the case. > > > >>> this is not what i say. i am concerned in stating > > beforehand RFC > > > >>> 3945 (GMPLS Arch.) is not applicable to Ethernet. Why the doc. > > > >>> does not deliver any tangible explanation. > > > >> NH=3D> Is your problem that you cannot differentiate=20 > between the 3 > > > >> network modes (of co-cs, co-ps and cl-ps)? > > > >=20 > > > > my concern wrt specific point you bring is that the today > > > definition in > > > > RFC 3945 for L2SC, and in the present case GMPLS for > > Ethernet (with > > > > local labels or domain-wide labels or any other equivalent > > > to "co-ps") > > > > does not result into a different definition than what's in. > > > on the other > > > > side, i do not see how would apply GMPLS for > > connectionless/bridged > > > > Ethernet. > > > >=20 > > > > note also that GMPLS induces label from the interface and link > > > > characteristic (i.e. there is no "label type" in the > > > label/label request > > > > object. > > > >=20 > > > >> If so then looking at the work on > > > >> unified modelling in SG15/Q12 may help you. But to give a more > > > >> specific example here: We can take an Ethernet=20 > traffic unit and=20 > > > >> create either a cl-ps and co-ps layer network based on=20 > this...in=20 > > > >> fact one > > > can image 3 > > > >> different layer network cases here: > > > >> - traditional Etherent which does not have a=20 > > directed routing > > > >> function, ie uses MAC learning, broadcast unknown, > > STP...this is a > > > >> cl-ps layer network > > > >> - Ethernet with an IGP providing a directed routing > > > >> function....this is also a cl-ps layer network, but it is > > > different to > > > >> the one above > > > >> - Ethernet with a directed routing component=20 > > (centralised or > > > >> distributed, ie IGP) and a signalling component that can create > > > >> connections....this would be a co-ps layer network. > > > >> > > > >> These are all based on a similar traffic unit, however > > they form 3 > > > >> quite different layer networks (and in functional architecture > > > >> terms we would say 'the Characteristic Information is=20 > > different in > > > >> the 3 cases'). > > > >> > > > >> Now GMPLS is applying a reusable set of CP components > > > (which is a very > > > >> good thing, as Ben points out below) for any co-cs or > > > co-ps mode layer > > > >> network. So we are setting up *connections* in either a space, > > > >> freq or time dimension of resource, and it is these 3 resource > > > dimensions that > > > >> create the differences in parameters...however, the notion of a > > > >> connection is common across all these resource dimensions. > > > GMPLS does > > > >> not apply to the cl-ps mode, as it plainly does not have > > > connections. > > > >=20 > > > > well indeed, and this is the reason why i do not see any > > reason to > > > > open the space for a different set of mechanisms that > > would result > > > > from this new interface switching definition. > > > >=20 > > > > thanks, > > > > -d. > > > > =20 > > > >> That is at least how I look at this issue. > > > >> > > > >> regards, Neil > > > >>>>> the question triggered by this poll is the following: if > > > >>> GMPLS for > > > >>>>> Ethernet is not inline with the existing stacks what is > > > >>> the value of > > > >>>>> GMPLS re-use ? what's the value to borrow the term GMPLS > > > >>> without its > > > >>>>> substance ? and in practice, the issue is, if it is not > > > >>>> GMPLS per RFC > > > >>>>> 3945, what's the value compared to any other native control > > > >>>> stack that > > > >>>>> would be developed at IEEE for inst. for these techno's. > > > >>>> If we ignore the peer model (which is unworkable in > > reality IMO), > >=20 > > > >>>> the value is obvious - significant reuse of existing code, > > > >>>> techniques, knowledge, skills, etc. > > > >>>> > > > >>>> So, we should develop the control plane from scratch > > > >>> because Ethernet > > > >>>> requires a few modifications/enhancements (which I=20 > believe are > > > >>>> backwards > > > >>>> compatible) to RFC3945 - that IMO is ridiculous. > > > >>> so you seem to agree with me. departing from RFC 3945 > > makes little > >=20 > > > >>> sense. it would have been interesting to see the doc > > delivering a > > > >>> FIT of the GMPLS protocol arch. blocks and, in > > particular, label > > > >>> allocation and distribution for Ethernet. > > > >>> > > > >>> thanks, > > > >>> -dimitri. > > > >>>> Ben > > > >>>> > > > >>>> > > > >>> > > > >=20 > > > >=20 > > > >=20 > > >=20 > > >=20 > > > -- > > > Loa Andersson > > >=20 > > > Principal Networking Architect > > > Acreo AB phone: +46 8 632 77 14 > > > Isafjordsgatan 22 mobile: +46 739 81 21 64 > > > Kista, Sweden email: loa.andersson@acreo.se > > > loa@pi.se > > >=20 > >=20 > >=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 30 Jan 2008 18:03:22 +0000 Message-ID: <0ea901c8636a$3220c230$0200a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "Mach Chen" Subject: Getting off the fence about draft-chen-ccamp-isis-interas-te-extension Date: Wed, 30 Jan 2008 18:00:54 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Hi all, We have an imbalance. We accepted draft-ietf-ccamp-ospf-interas-te-extension long ago. The ISIS I-D got stuck making some changes for the ISIS WG and then because of the discussion around BGP-TE. the two items have been resolved: - The I-D was revised and updated to cover the ISIS issues - The BGP-TE I-D has been taken to the Softwires WG Mach, can you please resubmit the current version of the draft as draft-ietf-ccamp-isis-interas-te-extension-00.txt Many thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 30 Jan 2008 17:24: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: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Date: Wed, 30 Jan 2008 18:23:00 +0100 Message-ID: Thread-Topic: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Thread-Index: Achid4JetInOIvLXS36xGBjOv4vCdwAOqlZgAB8MVpAADGxFgA== From: "PAPADIMITRIOU Dimitri" To: "Howard Green" , "Loa Andersson" Cc: , , , , , =20 > -----Original Message----- > From: Howard Green [mailto:howard.green@ericsson.com]=20 > Sent: Wednesday, January 30, 2008 12:09 PM > To: PAPADIMITRIOU Dimitri; Loa Andersson > Cc: neil.2.harrison@bt.com; benjamin.niven-jenkins@bt.com;=20 > lberger@labn.net; dwfedyk@nortel.com; dbrungard@att.com;=20 > ccamp@ops.ietf.org > Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt >=20 > Hi > Dimitri seems to me to be making a very abstract and legalistic point. receive my total disagreement. an individual submission that asks to change an existing RFC requires discussion and particular attention (in part., when it is the protocol arch. document) - if this not possible then probably you have to write also a doc. asking for changing the IETF proces - and then you come back with your individual submission. =20 > The reason why this work is important is that the IEEE has=20 > been evolving > Ethernet to give it carrier class features, in respect of scalability, > OAM, and (with 802.1Qay) the possibility to use an external control > plane.=20 no one i think question this. and i don't think the poll is on this specific point. CCAMP or even IETF at large is not an authority to decide upon IEEE technos. > Some of these features will very likely require or enable added > value from extensions to the functionality of GMPLS - for example, as > has already been suggested, the addition of functionality=20 > for creating the OAM associations.=20 indeed, and your colleague has already received a list of comments to be addressed before seeing any way forward w/ the proposed approach.=20 > Therefore this will likely not be the same as the > possible use suggested in RFC3945, which may (at least=20 > in theory) have been implemented somewhere.=20 the exact problem, i mentionned a couple of times. your own comment shows that one may use GMPLS differently but may i ask WHY ? and what's the implications ? > Therefore the suggestion in the draft seems to make sense.=20 why ? > I can't really see what important principle is being > defended by the insistence upon L2SC, which, as Don Fedyk stated, was > always somewhat underspecified. THE reason is that an interface SC or a related functionality has never resulted in a specific change in the base protocol building blocks. GMPLS is a generalized approach not a differentiated approach per interface. actually your last statement is not correct (L2SC is well specified in RFC 3945) AND by the way yours does not at all better specify it. > This is not something to be debated in the abstract. The work in ccamp > should allow sensible extension of functionality where it adds value, > and this needs to be discussed on a case by case basis. Therefore we > should make it a working group document and get on with it. -d. > regards Howard Green >=20 > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On > Behalf Of PAPADIMITRIOU Dimitri > Sent: 30 January 2008 10:15 > To: Loa Andersson > Cc: neil.2.harrison@bt.com; benjamin.niven-jenkins@bt.com; > lberger@labn.net; dwfedyk@nortel.com; dbrungard@att.com; > ccamp@ops.ietf.org > Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt >=20 > loa, >=20 >=20 > i think the main point as ccamp is whether or not we poll for a change > or a continuation inline with RFC3945 -- when the present=20 > doc. states:=20 >=20 > "It is expected that there will be no > case where an Eth-LSP will be signaled, or an Eth-LSP supporting > interface will be represented, using the L2SC switching > type/capability. A new switching type/capability is required to > avoid any potential current usage of the L2SC switching > type/capability in support of Ethernet. >=20 > [...] >=20 > "The L2SC Interface Switching Capabilities MUST > NOT be used to represent interfaces capable of supporting=20 > Eth-LSPs." >=20 > it raises three issues: >=20 > a) what was the previous L2SC def. per RFC 3945 meant for if=20 > not for use > also in GMPLS Ethernet context ? >=20 > b) why a "new one" ?=20 >=20 > this is not explained. >=20 > c) what is the "new one" implying in terms of GMPLS ? >=20 > for inst. in the intro "The intent of this document is to reuse and > align with as much of the GMPLS protocols as possible."=20 > leaves open the > issue of what as much as possible means. >=20 > and on the other "Additions are made only to accommodate features of > Ethernet that are not already supported by GMPLS." so, how shall i > interpreet the first sentence now ? inline with point a) and b) ? >=20 >=20 > the doc. in WG I-D status or not is not going to provide an answer to > these questions. sentences and statements in the doc. contradict each > other. >=20 > thanks, > -d. >=20 >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: Loa Andersson [mailto:loa@pi.se] > > Sent: Tuesday, January 29, 2008 2:04 PM > > To: PAPADIMITRIOU Dimitri > > Cc: neil.2.harrison@bt.com; benjamin.niven-jenkins@bt.com;=20 > > lberger@labn.net; dwfedyk@nortel.com; dbrungard@att.com;=20 > > ccamp@ops.ietf.org > > Subject: Re: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt > >=20 > > Dimitri, > >=20 > > it is possible that you have a point that needs to be=20 > discussed, but=20 > > is this really something that should stop us from adopting=20 > the doc as=20 > > a working group document. > >=20 > > /Loa > >=20 > > PAPADIMITRIOU Dimitri wrote: > > > neil, > > >=20 > > >> -----Original Message----- > > >> From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] > > >> Sent: Friday, January 25, 2008 2:27 PM > > >> To: PAPADIMITRIOU Dimitri; benjamin.niven-jenkins@bt.com;=20 > > >> lberger@labn.net > > >> Cc: dwfedyk@nortel.com; dbrungard@att.com; ccamp@ops.ietf.org > > >> Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt > > >> > > >> Dimitri....see if this helps...in-line > > >> > > >>> -----Original Message----- > > >>> From: owner-ccamp@ops.ietf.org > > >>> [mailto:owner-ccamp@ops.ietf.org] On Behalf Of > > PAPADIMITRIOU Dimitri > > >>> Sent: 25 January 2008 11:36 > > >>> To: Niven-jenkins,B,Ben,DMF R; Lou Berger > > >>> Cc: Don Fedyk; BRUNGARD, DEBORAH A, ATTLABS; ccamp@ops.ietf.org > > >>> Subject: RE: Proposed WG Draft -=20 > draft-gmpls-ethernet-arch-00.txt > > >>> > > >>> > > >>> ben > > >>> > > >>>> -----Original Message----- > > >>>> From: Ben Niven-Jenkins [mailto:benjamin.niven-jenkins@bt.com] > > >>>> Sent: Thursday, January 24, 2008 3:40 PM > > >>>> To: PAPADIMITRIOU Dimitri; Lou Berger > > >>>> Cc: Don Fedyk; BRUNGARD, DEBORAH A, ATTLABS; ccamp@ops.ietf.org > > >>>> Subject: Re: Proposed WG Draft -=20 > draft-gmpls-ethernet-arch-00.txt > > >>>> > > >>>> Dimitri, > > >>>> > > >>>> I find your mail somewhat puzzling. > > >>>> > > >>>> You appear to be saying that GMPLS as per RFC 3945 is set > > >>> in stone and > > >>>> nothing should modify/enhance the behaviour as specified > > >> in RFC3945 > > >>>> which implies that when RFC3945 was produced the crystal > > ball was > > >>>> working extremely well and all possible future > > applications of the > > >>>> technology had > > >>>> been correctly envisaged. I don't believe that was the case. > > >>> this is not what i say. i am concerned in stating=20 > beforehand RFC=20 > > >>> 3945 (GMPLS Arch.) is not applicable to Ethernet. Why the doc.=20 > > >>> does not deliver any tangible explanation. > > >> NH=3D> Is your problem that you cannot differentiate between the = 3=20 > > >> network modes (of co-cs, co-ps and cl-ps)? > > >=20 > > > my concern wrt specific point you bring is that the today > > definition in > > > RFC 3945 for L2SC, and in the present case GMPLS for=20 > Ethernet (with=20 > > > local labels or domain-wide labels or any other equivalent > > to "co-ps") > > > does not result into a different definition than what's in.=20 > > on the other > > > side, i do not see how would apply GMPLS for=20 > connectionless/bridged=20 > > > Ethernet. > > >=20 > > > note also that GMPLS induces label from the interface and link=20 > > > characteristic (i.e. there is no "label type" in the > > label/label request > > > object. > > >=20 > > >> If so then looking at the work on > > >> unified modelling in SG15/Q12 may help you. But to give a more=20 > > >> specific example here: We can take an Ethernet traffic unit and=20 > > >> create either a cl-ps and co-ps layer network based on this...in=20 > > >> fact one > > can image 3 > > >> different layer network cases here: > > >> - traditional Etherent which does not have a=20 > directed routing > > >> function, ie uses MAC learning, broadcast unknown,=20 > STP...this is a=20 > > >> cl-ps layer network > > >> - Ethernet with an IGP providing a directed routing > > >> function....this is also a cl-ps layer network, but it is > > different to > > >> the one above > > >> - Ethernet with a directed routing component=20 > (centralised or > > >> distributed, ie IGP) and a signalling component that can create=20 > > >> connections....this would be a co-ps layer network. > > >> > > >> These are all based on a similar traffic unit, however=20 > they form 3=20 > > >> quite different layer networks (and in functional architecture=20 > > >> terms we would say 'the Characteristic Information is=20 > different in=20 > > >> the 3 cases'). > > >> > > >> Now GMPLS is applying a reusable set of CP components > > (which is a very > > >> good thing, as Ben points out below) for any co-cs or > > co-ps mode layer > > >> network. So we are setting up *connections* in either a space,=20 > > >> freq or time dimension of resource, and it is these 3 resource > > dimensions that > > >> create the differences in parameters...however, the notion of a=20 > > >> connection is common across all these resource dimensions. > > GMPLS does > > >> not apply to the cl-ps mode, as it plainly does not have > > connections. > > >=20 > > > well indeed, and this is the reason why i do not see any=20 > reason to=20 > > > open the space for a different set of mechanisms that=20 > would result=20 > > > from this new interface switching definition. > > >=20 > > > thanks, > > > -d. > > > =20 > > >> That is at least how I look at this issue. > > >> > > >> regards, Neil > > >>>>> the question triggered by this poll is the following: if > > >>> GMPLS for > > >>>>> Ethernet is not inline with the existing stacks what is > > >>> the value of > > >>>>> GMPLS re-use ? what's the value to borrow the term GMPLS > > >>> without its > > >>>>> substance ? and in practice, the issue is, if it is not > > >>>> GMPLS per RFC > > >>>>> 3945, what's the value compared to any other native control > > >>>> stack that > > >>>>> would be developed at IEEE for inst. for these techno's. > > >>>> If we ignore the peer model (which is unworkable in=20 > reality IMO), >=20 > > >>>> the value is obvious - significant reuse of existing code,=20 > > >>>> techniques, knowledge, skills, etc. > > >>>> > > >>>> So, we should develop the control plane from scratch > > >>> because Ethernet > > >>>> requires a few modifications/enhancements (which I believe are=20 > > >>>> backwards > > >>>> compatible) to RFC3945 - that IMO is ridiculous. > > >>> so you seem to agree with me. departing from RFC 3945=20 > makes little >=20 > > >>> sense. it would have been interesting to see the doc=20 > delivering a=20 > > >>> FIT of the GMPLS protocol arch. blocks and, in=20 > particular, label=20 > > >>> allocation and distribution for Ethernet. > > >>> > > >>> thanks, > > >>> -dimitri. > > >>>> Ben > > >>>> > > >>>> > > >>> > > >=20 > > >=20 > > >=20 > >=20 > >=20 > > -- > > Loa Andersson > >=20 > > Principal Networking Architect > > Acreo AB phone: +46 8 632 77 14 > > Isafjordsgatan 22 mobile: +46 739 81 21 64 > > Kista, Sweden email: loa.andersson@acreo.se > > loa@pi.se > >=20 >=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 30 Jan 2008 16:40: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: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Date: Wed, 30 Jan 2008 11:39:27 -0500 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA4136237B1@zrtphxm2.corp.nortel.com> Thread-Topic: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Thread-Index: AchjV50rUy/wB/z6TMO8U1IqHGt09gABMNqQ From: "Don Fedyk" To: "Adrian Farrel" , Hi Adrian This sounds good to me and certainly it was not our intent to confuse these points. If the new text can us forward that would be great.=20 Thanks, Don =20 > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel > Sent: Wednesday, January 30, 2008 10:28 AM > To: ccamp@ops.ietf.org > Subject: Re: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt >=20 > All, >=20 > We appear to be seeing good support for this document, and=20 > that suggests=20 > that we should take it forward, but I would like to at least=20 > make an attempt=20 > to close down the point raised by Dimitri. As Howard points=20 > out, this is in=20 > danger of becoming a legalistic discussion, but I've never=20 > been one to=20 > refuse the opportunity to back to first principles... >=20 > In RFC 3945 we have... >=20 > A link may support a set of encoding formats, where support means > that a link is able to carry and switch a signal of one or more of > these encoding formats. The Switching Type indicates then the type > of switching that should be performed on a particular link for that > LSP. This information is needed for links that advertise more than > one type of switching capability. >=20 > Nodes must verify that the type indicated in the Switching Type is > supported on the corresponding incoming interface; otherwise, the > node must generate a notification message with a "Routing > problem/Switching Type" indication. >=20 > Now, the question is whether we are introducing one (or more)=20 > new Switching=20 > Type and whether we need to be able to distinguish between=20 > them. Suppose=20 > (for the sake of argument) that we will over time introduce=20 > the ability to=20 > switch Ethernet frames under GMPLS control based on several=20 > different label=20 > concepts: > - 802.1Qay > - destination MAC only > - destination MAC and VLAN tag > It is likely that a GMPLS-capable Ethernet switch will want=20 > to support more=20 > than one of these switching paradigms on any single=20 > interface. So we have to=20 > decide how, during signaling, we indicate which type of LSP=20 > is requested. >=20 > There are plenty of ways that this could be done. Currently we use a=20 > combination of the parameters of the=20 > Generalized_Label_Request object and=20 > the Sender_TSpec object. The TSpec is used in the case of TDM=20 > (RFC 4606) and=20 > Ethernet to distinguish the Switching Granularity=20 > (draft-ietf-ccamp-ethernet-traffic-parameters). >=20 > As I see it, the text at issue in=20 > draft-gmpls-ethernet-arch-00.txt causes a=20 > problem because it appears to say that *no* Ethernet Label=20 > Switched Path=20 > (Eth-LSP) can be set up using an L2SC Switching Type. > It is expected that there will be no > case where an Eth-LSP will be signaled, or an Eth-LSP supporting > interface will be represented, using the L2SC switching > type/capability. >=20 > However, the draft also says... > A new switching type/capability is required to > avoid any potential current usage of the L2SC switching > type/capability in support of Ethernet. >=20 > And this clearly says that L2SC *is* allowed. >=20 > Can we fix this by agreeing some new wording? >=20 > =3D=3D > OLD > This document does not define any specific format for an Eth-LSP > label. Rather, it is expected that service specific documents will > define any signaling and routing extensions needed to support that > specific Ethernet service. Depending on the requirements of a > service, it may be necessary to define multiple GMPLS extensions, > e.g., label formats, switching types, and Traffic Engineering (TE) > routing extensions. It is expected that all such=20 > extensions will be > consistent with this document. It is expected that there will be no > case where an Eth-LSP will be signaled, or an Eth-LSP supporting > interface will be represented, using the L2SC switching > type/capability. A new switching type/capability is required to > avoid any potential current usage of the L2SC switching > type/capability in support of Ethernet. > NEW > This document does not define any specific format for an Eth-LSP > label. Rather, it is expected that service specific documents will > define any signaling and routing extensions needed to support that > specific Ethernet service. Depending on the requirements of a > service, it may be necessary to define multiple GMPLS protocol > extensions and procedures. It is expected that all such extensions > will be consistent with this document. >=20 > It is expected that key a requirement will be to describe label > formats and encodings. It may also be necessary to provide a > mechanism to identify the required Ethernet service type=20 > in signaling > and a way to advertise the capabilities of Ethernet switches in the > routing protocols. These mechanisms must make it possible to > distinguish between requests for different paradigms including new, > future, and existing paradigms. >=20 > The Switching Type and Interface Switching Capability Descriptor > share a common set of values and are defined in [RFC3945],=20 > [RFC3471], > and [RFC4202] as indicators of the type of switching that should > ([RFC3471]) and can ([RFC4202]) be performed on a=20 > particular link for > an LSP. The L2SC switching type is available for use by > implementations performing layer 2 switching including ATM and > Ethernet. To support the continued use of that switching type by > existing implementations as well as to distinguish between each new > Ethernet switching paradigm, a new switching type is expected to be > needed for each new Ethernet switching paradigm that is supported. > =3D=3D >=20 > Thanks, > Adrian=20 >=20 >=20 >=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 30 Jan 2008 15:30:16 +0000 Message-ID: <0df801c86354$a266fc00$0200a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Re: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Date: Wed, 30 Jan 2008 15:27:30 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit All, We appear to be seeing good support for this document, and that suggests that we should take it forward, but I would like to at least make an attempt to close down the point raised by Dimitri. As Howard points out, this is in danger of becoming a legalistic discussion, but I've never been one to refuse the opportunity to back to first principles... In RFC 3945 we have... A link may support a set of encoding formats, where support means that a link is able to carry and switch a signal of one or more of these encoding formats. The Switching Type indicates then the type of switching that should be performed on a particular link for that LSP. This information is needed for links that advertise more than one type of switching capability. Nodes must verify that the type indicated in the Switching Type is supported on the corresponding incoming interface; otherwise, the node must generate a notification message with a "Routing problem/Switching Type" indication. Now, the question is whether we are introducing one (or more) new Switching Type and whether we need to be able to distinguish between them. Suppose (for the sake of argument) that we will over time introduce the ability to switch Ethernet frames under GMPLS control based on several different label concepts: - 802.1Qay - destination MAC only - destination MAC and VLAN tag It is likely that a GMPLS-capable Ethernet switch will want to support more than one of these switching paradigms on any single interface. So we have to decide how, during signaling, we indicate which type of LSP is requested. There are plenty of ways that this could be done. Currently we use a combination of the parameters of the Generalized_Label_Request object and the Sender_TSpec object. The TSpec is used in the case of TDM (RFC 4606) and Ethernet to distinguish the Switching Granularity (draft-ietf-ccamp-ethernet-traffic-parameters). As I see it, the text at issue in draft-gmpls-ethernet-arch-00.txt causes a problem because it appears to say that *no* Ethernet Label Switched Path (Eth-LSP) can be set up using an L2SC Switching Type. It is expected that there will be no case where an Eth-LSP will be signaled, or an Eth-LSP supporting interface will be represented, using the L2SC switching type/capability. However, the draft also says... A new switching type/capability is required to avoid any potential current usage of the L2SC switching type/capability in support of Ethernet. And this clearly says that L2SC *is* allowed. Can we fix this by agreeing some new wording? == OLD This document does not define any specific format for an Eth-LSP label. Rather, it is expected that service specific documents will define any signaling and routing extensions needed to support that specific Ethernet service. Depending on the requirements of a service, it may be necessary to define multiple GMPLS extensions, e.g., label formats, switching types, and Traffic Engineering (TE) routing extensions. It is expected that all such extensions will be consistent with this document. It is expected that there will be no case where an Eth-LSP will be signaled, or an Eth-LSP supporting interface will be represented, using the L2SC switching type/capability. A new switching type/capability is required to avoid any potential current usage of the L2SC switching type/capability in support of Ethernet. NEW This document does not define any specific format for an Eth-LSP label. Rather, it is expected that service specific documents will define any signaling and routing extensions needed to support that specific Ethernet service. Depending on the requirements of a service, it may be necessary to define multiple GMPLS protocol extensions and procedures. It is expected that all such extensions will be consistent with this document. It is expected that key a requirement will be to describe label formats and encodings. It may also be necessary to provide a mechanism to identify the required Ethernet service type in signaling and a way to advertise the capabilities of Ethernet switches in the routing protocols. These mechanisms must make it possible to distinguish between requests for different paradigms including new, future, and existing paradigms. The Switching Type and Interface Switching Capability Descriptor share a common set of values and are defined in [RFC3945], [RFC3471], and [RFC4202] as indicators of the type of switching that should ([RFC3471]) and can ([RFC4202]) be performed on a particular link for an LSP. The L2SC switching type is available for use by implementations performing layer 2 switching including ATM and Ethernet. To support the continued use of that switching type by existing implementations as well as to distinguish between each new Ethernet switching paradigm, a new switching type is expected to be needed for each new Ethernet switching paradigm that is supported. == Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 30 Jan 2008 11:10:34 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Date: Wed, 30 Jan 2008 12:08:30 +0100 Message-ID: <56D2F550769FAA4CA70D5B2EB8419F1402A3A51E@esealmw118.eemea.ericsson.se> Thread-Topic: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Thread-Index: Achid4JetInOIvLXS36xGBjOv4vCdwAOqlZgAB8MVpA= From: "Howard Green" To: "PAPADIMITRIOU Dimitri" , "Loa Andersson" Cc: , , , , , Hi Dimitri seems to me to be making a very abstract and legalistic point. =20 The reason why this work is important is that the IEEE has been evolving Ethernet to give it carrier class features, in respect of scalability, OAM, and (with 802.1Qay) the possibility to use an external control plane. Some of these features will very likely require or enable added value from extensions to the functionality of GMPLS - for example, as has already been suggested, the addition of functionality for creating the OAM associations. Therefore this will likely not be the same as the possible use suggested in RFC3945, which may (at least in theory) have been implemented somewhere. Therefore the suggestion in the draft seems to make sense. I can't really see what important principle is being defended by the insistence upon L2SC, which, as Don Fedyk stated, was always somewhat underspecified. This is not something to be debated in the abstract. The work in ccamp should allow sensible extension of functionality where it adds value, and this needs to be discussed on a case by case basis. Therefore we should make it a working group document and get on with it. regards Howard Green -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of PAPADIMITRIOU Dimitri Sent: 30 January 2008 10:15 To: Loa Andersson Cc: neil.2.harrison@bt.com; benjamin.niven-jenkins@bt.com; lberger@labn.net; dwfedyk@nortel.com; dbrungard@att.com; ccamp@ops.ietf.org Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt loa, i think the main point as ccamp is whether or not we poll for a change or a continuation inline with RFC3945 -- when the present doc. states:=20 "It is expected that there will be no case where an Eth-LSP will be signaled, or an Eth-LSP supporting interface will be represented, using the L2SC switching type/capability. A new switching type/capability is required to avoid any potential current usage of the L2SC switching type/capability in support of Ethernet. [...] "The L2SC Interface Switching Capabilities MUST NOT be used to represent interfaces capable of supporting Eth-LSPs." it raises three issues: a) what was the previous L2SC def. per RFC 3945 meant for if not for use also in GMPLS Ethernet context ? b) why a "new one" ?=20 this is not explained. c) what is the "new one" implying in terms of GMPLS ? for inst. in the intro "The intent of this document is to reuse and align with as much of the GMPLS protocols as possible." leaves open the issue of what as much as possible means. and on the other "Additions are made only to accommodate features of Ethernet that are not already supported by GMPLS." so, how shall i interpreet the first sentence now ? inline with point a) and b) ? the doc. in WG I-D status or not is not going to provide an answer to these questions. sentences and statements in the doc. contradict each other. thanks, -d. > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.se] > Sent: Tuesday, January 29, 2008 2:04 PM > To: PAPADIMITRIOU Dimitri > Cc: neil.2.harrison@bt.com; benjamin.niven-jenkins@bt.com;=20 > lberger@labn.net; dwfedyk@nortel.com; dbrungard@att.com;=20 > ccamp@ops.ietf.org > Subject: Re: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt >=20 > Dimitri, >=20 > it is possible that you have a point that needs to be discussed, but=20 > is this really something that should stop us from adopting the doc as=20 > a working group document. >=20 > /Loa >=20 > PAPADIMITRIOU Dimitri wrote: > > neil, > >=20 > >> -----Original Message----- > >> From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] > >> Sent: Friday, January 25, 2008 2:27 PM > >> To: PAPADIMITRIOU Dimitri; benjamin.niven-jenkins@bt.com;=20 > >> lberger@labn.net > >> Cc: dwfedyk@nortel.com; dbrungard@att.com; ccamp@ops.ietf.org > >> Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt > >> > >> Dimitri....see if this helps...in-line > >> > >>> -----Original Message----- > >>> From: owner-ccamp@ops.ietf.org > >>> [mailto:owner-ccamp@ops.ietf.org] On Behalf Of > PAPADIMITRIOU Dimitri > >>> Sent: 25 January 2008 11:36 > >>> To: Niven-jenkins,B,Ben,DMF R; Lou Berger > >>> Cc: Don Fedyk; BRUNGARD, DEBORAH A, ATTLABS; ccamp@ops.ietf.org > >>> Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt > >>> > >>> > >>> ben > >>> > >>>> -----Original Message----- > >>>> From: Ben Niven-Jenkins [mailto:benjamin.niven-jenkins@bt.com] > >>>> Sent: Thursday, January 24, 2008 3:40 PM > >>>> To: PAPADIMITRIOU Dimitri; Lou Berger > >>>> Cc: Don Fedyk; BRUNGARD, DEBORAH A, ATTLABS; ccamp@ops.ietf.org > >>>> Subject: Re: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt > >>>> > >>>> Dimitri, > >>>> > >>>> I find your mail somewhat puzzling. > >>>> > >>>> You appear to be saying that GMPLS as per RFC 3945 is set > >>> in stone and > >>>> nothing should modify/enhance the behaviour as specified > >> in RFC3945 > >>>> which implies that when RFC3945 was produced the crystal > ball was > >>>> working extremely well and all possible future > applications of the > >>>> technology had > >>>> been correctly envisaged. I don't believe that was the case. > >>> this is not what i say. i am concerned in stating beforehand RFC=20 > >>> 3945 (GMPLS Arch.) is not applicable to Ethernet. Why the doc.=20 > >>> does not deliver any tangible explanation. > >> NH=3D> Is your problem that you cannot differentiate between the 3=20 > >> network modes (of co-cs, co-ps and cl-ps)? > >=20 > > my concern wrt specific point you bring is that the today > definition in > > RFC 3945 for L2SC, and in the present case GMPLS for Ethernet (with=20 > > local labels or domain-wide labels or any other equivalent > to "co-ps") > > does not result into a different definition than what's in.=20 > on the other > > side, i do not see how would apply GMPLS for connectionless/bridged=20 > > Ethernet. > >=20 > > note also that GMPLS induces label from the interface and link=20 > > characteristic (i.e. there is no "label type" in the > label/label request > > object. > >=20 > >> If so then looking at the work on > >> unified modelling in SG15/Q12 may help you. But to give a more=20 > >> specific example here: We can take an Ethernet traffic unit and=20 > >> create either a cl-ps and co-ps layer network based on this...in=20 > >> fact one > can image 3 > >> different layer network cases here: > >> - traditional Etherent which does not have a directed routing > >> function, ie uses MAC learning, broadcast unknown, STP...this is a=20 > >> cl-ps layer network > >> - Ethernet with an IGP providing a directed routing > >> function....this is also a cl-ps layer network, but it is > different to > >> the one above > >> - Ethernet with a directed routing component (centralised or > >> distributed, ie IGP) and a signalling component that can create=20 > >> connections....this would be a co-ps layer network. > >> > >> These are all based on a similar traffic unit, however they form 3=20 > >> quite different layer networks (and in functional architecture=20 > >> terms we would say 'the Characteristic Information is different in=20 > >> the 3 cases'). > >> > >> Now GMPLS is applying a reusable set of CP components > (which is a very > >> good thing, as Ben points out below) for any co-cs or > co-ps mode layer > >> network. So we are setting up *connections* in either a space,=20 > >> freq or time dimension of resource, and it is these 3 resource > dimensions that > >> create the differences in parameters...however, the notion of a=20 > >> connection is common across all these resource dimensions. > GMPLS does > >> not apply to the cl-ps mode, as it plainly does not have > connections. > >=20 > > well indeed, and this is the reason why i do not see any reason to=20 > > open the space for a different set of mechanisms that would result=20 > > from this new interface switching definition. > >=20 > > thanks, > > -d. > > =20 > >> That is at least how I look at this issue. > >> > >> regards, Neil > >>>>> the question triggered by this poll is the following: if > >>> GMPLS for > >>>>> Ethernet is not inline with the existing stacks what is > >>> the value of > >>>>> GMPLS re-use ? what's the value to borrow the term GMPLS > >>> without its > >>>>> substance ? and in practice, the issue is, if it is not > >>>> GMPLS per RFC > >>>>> 3945, what's the value compared to any other native control > >>>> stack that > >>>>> would be developed at IEEE for inst. for these techno's. > >>>> If we ignore the peer model (which is unworkable in reality IMO), > >>>> the value is obvious - significant reuse of existing code,=20 > >>>> techniques, knowledge, skills, etc. > >>>> > >>>> So, we should develop the control plane from scratch > >>> because Ethernet > >>>> requires a few modifications/enhancements (which I believe are=20 > >>>> backwards > >>>> compatible) to RFC3945 - that IMO is ridiculous. > >>> so you seem to agree with me. departing from RFC 3945 makes little > >>> sense. it would have been interesting to see the doc delivering a=20 > >>> FIT of the GMPLS protocol arch. blocks and, in particular, label=20 > >>> allocation and distribution for Ethernet. > >>> > >>> thanks, > >>> -dimitri. > >>>> Ben > >>>> > >>>> > >>> > >=20 > >=20 > >=20 >=20 >=20 > -- > Loa Andersson >=20 > Principal Networking Architect > Acreo AB phone: +46 8 632 77 14 > Isafjordsgatan 22 mobile: +46 739 81 21 64 > Kista, Sweden email: loa.andersson@acreo.se > loa@pi.se >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 30 Jan 2008 09:15:40 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Date: Wed, 30 Jan 2008 10:14:37 +0100 Message-ID: Thread-Topic: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Thread-Index: Achid4JetInOIvLXS36xGBjOv4vCdwAOqlZg From: "PAPADIMITRIOU Dimitri" To: "Loa Andersson" Cc: , , , , , loa, i think the main point as ccamp is whether or not we poll for a change or a continuation inline with RFC3945 -- when the present doc. states:=20 "It is expected that there will be no case where an Eth-LSP will be signaled, or an Eth-LSP supporting interface will be represented, using the L2SC switching type/capability. A new switching type/capability is required to avoid any potential current usage of the L2SC switching type/capability in support of Ethernet. [...] "The L2SC Interface Switching Capabilities MUST NOT be used to represent interfaces capable of supporting Eth-LSPs." it raises three issues: a) what was the previous L2SC def. per RFC 3945 meant for if not for use also in GMPLS Ethernet context ? b) why a "new one" ?=20 this is not explained. c) what is the "new one" implying in terms of GMPLS ? for inst. in the intro "The intent of this document is to reuse and align with as much of the GMPLS protocols as possible." leaves open the issue of what as much as possible means. and on the other "Additions are made only to accommodate features of Ethernet that are not already supported by GMPLS." so, how shall i interpreet the first sentence now ? inline with point a) and b) ? the doc. in WG I-D status or not is not going to provide an answer to these questions. sentences and statements in the doc. contradict each other. thanks, -d. > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.se]=20 > Sent: Tuesday, January 29, 2008 2:04 PM > To: PAPADIMITRIOU Dimitri > Cc: neil.2.harrison@bt.com; benjamin.niven-jenkins@bt.com;=20 > lberger@labn.net; dwfedyk@nortel.com; dbrungard@att.com;=20 > ccamp@ops.ietf.org > Subject: Re: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt >=20 > Dimitri, >=20 > it is possible that you have a point that needs to be discussed, > but is this really something that should stop us from adopting the > doc as a working group document. >=20 > /Loa >=20 > PAPADIMITRIOU Dimitri wrote: > > neil,=20 > >=20 > >> -----Original Message----- > >> From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]=20 > >> Sent: Friday, January 25, 2008 2:27 PM > >> To: PAPADIMITRIOU Dimitri; benjamin.niven-jenkins@bt.com;=20 > >> lberger@labn.net > >> Cc: dwfedyk@nortel.com; dbrungard@att.com; ccamp@ops.ietf.org > >> Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt > >> > >> Dimitri....see if this helps...in-line > >> > >>> -----Original Message----- > >>> From: owner-ccamp@ops.ietf.org=20 > >>> [mailto:owner-ccamp@ops.ietf.org] On Behalf Of=20 > PAPADIMITRIOU Dimitri > >>> Sent: 25 January 2008 11:36 > >>> To: Niven-jenkins,B,Ben,DMF R; Lou Berger > >>> Cc: Don Fedyk; BRUNGARD, DEBORAH A, ATTLABS; ccamp@ops.ietf.org > >>> Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt > >>> > >>> > >>> ben=20 > >>> > >>>> -----Original Message----- > >>>> From: Ben Niven-Jenkins [mailto:benjamin.niven-jenkins@bt.com] > >>>> Sent: Thursday, January 24, 2008 3:40 PM > >>>> To: PAPADIMITRIOU Dimitri; Lou Berger > >>>> Cc: Don Fedyk; BRUNGARD, DEBORAH A, ATTLABS; ccamp@ops.ietf.org > >>>> Subject: Re: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt > >>>> > >>>> Dimitri, > >>>> > >>>> I find your mail somewhat puzzling. > >>>> > >>>> You appear to be saying that GMPLS as per RFC 3945 is set=20 > >>> in stone and=20 > >>>> nothing should modify/enhance the behaviour as specified=20 > >> in RFC3945=20 > >>>> which implies that when RFC3945 was produced the crystal=20 > ball was=20 > >>>> working extremely well and all possible future=20 > applications of the > >>>> technology had > >>>> been correctly envisaged. I don't believe that was the case. > >>> this is not what i say. i am concerned in stating beforehand=20 > >>> RFC 3945 (GMPLS Arch.) is not applicable to Ethernet. Why the=20 > >>> doc. does not deliver any tangible explanation. > >> NH=3D> Is your problem that you cannot differentiate between=20 > >> the 3 network modes (of co-cs, co-ps and cl-ps)? =20 > >=20 > > my concern wrt specific point you bring is that the today=20 > definition in > > RFC 3945 for L2SC, and in the present case GMPLS for Ethernet (with > > local labels or domain-wide labels or any other equivalent=20 > to "co-ps") > > does not result into a different definition than what's in.=20 > on the other > > side, i do not see how would apply GMPLS for connectionless/bridged > > Ethernet. =20 > >=20 > > note also that GMPLS induces label from the interface and link > > characteristic (i.e. there is no "label type" in the=20 > label/label request > > object. > >=20 > >> If so then looking at the work on > >> unified modelling in SG15/Q12 may help you. But to give a=20 > >> more specific > >> example here: We can take an Ethernet traffic unit and=20 > >> create either a > >> cl-ps and co-ps layer network based on this...in fact one=20 > can image 3 > >> different layer network cases here: > >> - traditional Etherent which does not have a directed routing > >> function, ie uses MAC learning, broadcast unknown, STP...this=20 > >> is a cl-ps > >> layer network > >> - Ethernet with an IGP providing a directed routing > >> function....this is also a cl-ps layer network, but it is=20 > different to > >> the one above > >> - Ethernet with a directed routing component (centralised or > >> distributed, ie IGP) and a signalling component that can create > >> connections....this would be a co-ps layer network. > >> > >> These are all based on a similar traffic unit, however they=20 > >> form 3 quite > >> different layer networks (and in functional architecture=20 > >> terms we would > >> say 'the Characteristic Information is different in the 3 cases'). > >> > >> Now GMPLS is applying a reusable set of CP components=20 > (which is a very > >> good thing, as Ben points out below) for any co-cs or=20 > co-ps mode layer > >> network. So we are setting up *connections* in either a=20 > >> space, freq or > >> time dimension of resource, and it is these 3 resource=20 > dimensions that > >> create the differences in parameters...however, the notion of a > >> connection is common across all these resource dimensions.=20 > GMPLS does > >> not apply to the cl-ps mode, as it plainly does not have=20 > connections. > >=20 > > well indeed, and this is the reason why i do not see any reason to > > open the space for a different set of mechanisms that would result > > from this new interface switching definition. > >=20 > > thanks, > > -d. > > =20 > >> That is at least how I look at this issue. > >> > >> regards, Neil > >>>>> the question triggered by this poll is the following: if=20 > >>> GMPLS for=20 > >>>>> Ethernet is not inline with the existing stacks what is=20 > >>> the value of=20 > >>>>> GMPLS re-use ? what's the value to borrow the term GMPLS=20 > >>> without its=20 > >>>>> substance ? and in practice, the issue is, if it is not > >>>> GMPLS per RFC > >>>>> 3945, what's the value compared to any other native control > >>>> stack that > >>>>> would be developed at IEEE for inst. for these techno's. > >>>> If we ignore the peer model (which is unworkable in reality > >>>> IMO), the value > >>>> is obvious - significant reuse of existing code, techniques,=20 > >>>> knowledge, > >>>> skills, etc. > >>>> > >>>> So, we should develop the control plane from scratch=20 > >>> because Ethernet=20 > >>>> requires a few modifications/enhancements (which I believe are=20 > >>>> backwards > >>>> compatible) to RFC3945 - that IMO is ridiculous. > >>> so you seem to agree with me. departing from RFC 3945 makes=20 > >>> little sense. it would have been interesting to see the doc=20 > >>> delivering a FIT of the GMPLS protocol arch. blocks and, in=20 > >>> particular, label allocation and distribution for Ethernet. > >>> > >>> thanks, > >>> -dimitri. > >>>> Ben > >>>> > >>>> > >>> > >=20 > >=20 > >=20 >=20 >=20 > --=20 > Loa Andersson >=20 > Principal Networking Architect > Acreo AB phone: +46 8 632 77 14 > Isafjordsgatan 22 mobile: +46 739 81 21 64 > Kista, Sweden email: loa.andersson@acreo.se > loa@pi.se >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 30 Jan 2008 09:01:06 +0000 Message-Id: <47A04A5B.F14F.0066.0@acreo.se> Date: Wed, 30 Jan 2008 09:58:47 +0100 From: "Roland Elverljung" To: Cc: "DEBORAH A ATTLABS BRUNGARD" Subject: Re: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline In favor. Regards Roland Elverljung >>> On 2008-01-22 at 20:27, in message <449B2580D802A443A923DABF3EAB82AF10132C78@OCCLUST04EVS1.ugd.att.com>, wrote: > CCAMP, > > The DT proposed in their meeting presentation for their architecture and > framework document to be accepted as a WG draft: > http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt > > We received a couple of comments in the meeting, we would appreciate > additional feedback on the list. Please express your support (or > otherwise) for this I-D to become a WG draft. > > Thanks, > Deborah Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 29 Jan 2008 20:12:54 +0000 Message-ID: <0c6501c862b3$0f6ed950$0200a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "Ross Callon" , , "Scott Bradner" , "Brungard, Deborah A, ALABS" Subject: Re: Draft liaison response to ITU on GMPLS Calls Date: Tue, 29 Jan 2008 20:10:53 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit Duh-oh! Before Saturday February 2nd. Adrian ----- Original Message ----- From: "Adrian Farrel" To: Cc: "Ross Callon" ; ; "Scott Bradner" ; "Brungard, Deborah A, ALABS" Sent: Tuesday, January 29, 2008 7:43 PM Subject: Draft liaison response to ITU on GMPLS Calls > Hi, > > We need to respond to a liaison from ITU-T Study Group 15 Question 14. > https://datatracker.ietf.org/liaison/369/ > > Please comment before Saturday February 1st so I can send this in time. > > Thanks, > Adrian > > ==== > To: ITU-T Q14/15 > Cc: Kam Lam, Steve Trowbridge, Ross Callon, Dave Ward, Scott Bradner, > CCAMP Mailing List > Subject: Respnse to Your Liaison on GMPLS Calls > In Response > > Thank you for your liaison to CCAMP on GMPLS Calls from your Stuttgart > interim meeting in September 2007. > > In your liaison, you noted that the GMPLS call is assumed to be as general > as possible, and you asked what other call applications there may be in > addition to ASON and the CCAMP VCAT draft. At this moment, there are four > applications on which the CCAMP working group is working where GMPLS calls > are applied. The first two are ASON and VCAT as you note. The third is > related to ASON and is the multi-layer network. The fourth provides > support for the MEF UNI in coordination with the OIF. Other topics in the > future might include OAM coordination, billing, and client-facing port > capability negotiation. > > Your observations about how TNA information is not used in the propagation > or delivery of the [call] message, but may be used [by call controllers] > to identify the destination UNI and hence [the destination] Network Call > Controller agrees with our understanding and intentions. In practice, a > large range of information may be used by call controllers to route > calls - that is, to select a series of call controllers between call > source and call destination - although we would not wish to preclude > source-routing of calls. It is our intention that the generic call message > should be capable of being extended to carry any information required by > any application of the call message. > > In this light you ask for guidance on how to carry ASON call information > across a GMPLS network so that it can be reconstructed at ASON call > boundaries, and say that you support the resumption of work on a CCAMP I-D > on ASON applicability to address the above and would welcome the > opportunity to contribute through liaisons. We welcome your support and > look forward to working with you in this context. As above, we note that > the GMPLS call message (the Notify message) is not limited to the exchange > of information between call end points, but can also exchange information > between > transit call controllers by forming call segments as described in section > 7.3.1 of RFC 4974. Work on carrying ASON call information within a GMPLS > call message falls within the CCAMP charter and we hope that interested > parties will bring ideas forward through the normal process which is, of > course, contribution-driven. We would welcome input from all sources > either through the CCAMP mailing list or through liaisons. > > Best regards, > Adrian Farrel and Deborah Brungard > CCAMP working group co-chairs > > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 29 Jan 2008 19:46:14 +0000 Message-ID: <0c4301c862af$4e93ff60$0200a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "Ross Callon" , , "Scott Bradner" , "Brungard, Deborah A, ALABS" Subject: Draft liaison response to ITU on GMPLS Calls Date: Tue, 29 Jan 2008 19:43:45 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Hi, We need to respond to a liaison from ITU-T Study Group 15 Question 14. https://datatracker.ietf.org/liaison/369/ Please comment before Saturday February 1st so I can send this in time. Thanks, Adrian ==== To: ITU-T Q14/15 Cc: Kam Lam, Steve Trowbridge, Ross Callon, Dave Ward, Scott Bradner, CCAMP Mailing List Subject: Respnse to Your Liaison on GMPLS Calls In Response Thank you for your liaison to CCAMP on GMPLS Calls from your Stuttgart interim meeting in September 2007. In your liaison, you noted that the GMPLS call is assumed to be as general as possible, and you asked what other call applications there may be in addition to ASON and the CCAMP VCAT draft. At this moment, there are four applications on which the CCAMP working group is working where GMPLS calls are applied. The first two are ASON and VCAT as you note. The third is related to ASON and is the multi-layer network. The fourth provides support for the MEF UNI in coordination with the OIF. Other topics in the future might include OAM coordination, billing, and client-facing port capability negotiation. Your observations about how TNA information is not used in the propagation or delivery of the [call] message, but may be used [by call controllers] to identify the destination UNI and hence [the destination] Network Call Controller agrees with our understanding and intentions. In practice, a large range of information may be used by call controllers to route calls - that is, to select a series of call controllers between call source and call destination - although we would not wish to preclude source-routing of calls. It is our intention that the generic call message should be capable of being extended to carry any information required by any application of the call message. In this light you ask for guidance on how to carry ASON call information across a GMPLS network so that it can be reconstructed at ASON call boundaries, and say that you support the resumption of work on a CCAMP I-D on ASON applicability to address the above and would welcome the opportunity to contribute through liaisons. We welcome your support and look forward to working with you in this context. As above, we note that the GMPLS call message (the Notify message) is not limited to the exchange of information between call end points, but can also exchange information between transit call controllers by forming call segments as described in section 7.3.1 of RFC 4974. Work on carrying ASON call information within a GMPLS call message falls within the CCAMP charter and we hope that interested parties will bring ideas forward through the normal process which is, of course, contribution-driven. We would welcome input from all sources either through the CCAMP mailing list or through liaisons. Best regards, Adrian Farrel and Deborah Brungard CCAMP working group co-chairs Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 29 Jan 2008 13:07:24 +0000 Message-ID: <479F2458.6090201@pi.se> Date: Tue, 29 Jan 2008 14:04:24 +0100 From: Loa Andersson Organization: Acreo AB User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: PAPADIMITRIOU Dimitri CC: neil.2.harrison@bt.com, benjamin.niven-jenkins@bt.com, lberger@labn.net, dwfedyk@nortel.com, dbrungard@att.com, ccamp@ops.ietf.org Subject: Re: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dimitri, it is possible that you have a point that needs to be discussed, but is this really something that should stop us from adopting the doc as a working group document. /Loa PAPADIMITRIOU Dimitri wrote: > neil, > >> -----Original Message----- >> From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] >> Sent: Friday, January 25, 2008 2:27 PM >> To: PAPADIMITRIOU Dimitri; benjamin.niven-jenkins@bt.com; >> lberger@labn.net >> Cc: dwfedyk@nortel.com; dbrungard@att.com; ccamp@ops.ietf.org >> Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt >> >> Dimitri....see if this helps...in-line >> >>> -----Original Message----- >>> From: owner-ccamp@ops.ietf.org >>> [mailto:owner-ccamp@ops.ietf.org] On Behalf Of PAPADIMITRIOU Dimitri >>> Sent: 25 January 2008 11:36 >>> To: Niven-jenkins,B,Ben,DMF R; Lou Berger >>> Cc: Don Fedyk; BRUNGARD, DEBORAH A, ATTLABS; ccamp@ops.ietf.org >>> Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt >>> >>> >>> ben >>> >>>> -----Original Message----- >>>> From: Ben Niven-Jenkins [mailto:benjamin.niven-jenkins@bt.com] >>>> Sent: Thursday, January 24, 2008 3:40 PM >>>> To: PAPADIMITRIOU Dimitri; Lou Berger >>>> Cc: Don Fedyk; BRUNGARD, DEBORAH A, ATTLABS; ccamp@ops.ietf.org >>>> Subject: Re: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt >>>> >>>> Dimitri, >>>> >>>> I find your mail somewhat puzzling. >>>> >>>> You appear to be saying that GMPLS as per RFC 3945 is set >>> in stone and >>>> nothing should modify/enhance the behaviour as specified >> in RFC3945 >>>> which implies that when RFC3945 was produced the crystal ball was >>>> working extremely well and all possible future applications of the >>>> technology had >>>> been correctly envisaged. I don't believe that was the case. >>> this is not what i say. i am concerned in stating beforehand >>> RFC 3945 (GMPLS Arch.) is not applicable to Ethernet. Why the >>> doc. does not deliver any tangible explanation. >> NH=> Is your problem that you cannot differentiate between >> the 3 network modes (of co-cs, co-ps and cl-ps)? > > my concern wrt specific point you bring is that the today definition in > RFC 3945 for L2SC, and in the present case GMPLS for Ethernet (with > local labels or domain-wide labels or any other equivalent to "co-ps") > does not result into a different definition than what's in. on the other > side, i do not see how would apply GMPLS for connectionless/bridged > Ethernet. > > note also that GMPLS induces label from the interface and link > characteristic (i.e. there is no "label type" in the label/label request > object. > >> If so then looking at the work on >> unified modelling in SG15/Q12 may help you. But to give a >> more specific >> example here: We can take an Ethernet traffic unit and >> create either a >> cl-ps and co-ps layer network based on this...in fact one can image 3 >> different layer network cases here: >> - traditional Etherent which does not have a directed routing >> function, ie uses MAC learning, broadcast unknown, STP...this >> is a cl-ps >> layer network >> - Ethernet with an IGP providing a directed routing >> function....this is also a cl-ps layer network, but it is different to >> the one above >> - Ethernet with a directed routing component (centralised or >> distributed, ie IGP) and a signalling component that can create >> connections....this would be a co-ps layer network. >> >> These are all based on a similar traffic unit, however they >> form 3 quite >> different layer networks (and in functional architecture >> terms we would >> say 'the Characteristic Information is different in the 3 cases'). >> >> Now GMPLS is applying a reusable set of CP components (which is a very >> good thing, as Ben points out below) for any co-cs or co-ps mode layer >> network. So we are setting up *connections* in either a >> space, freq or >> time dimension of resource, and it is these 3 resource dimensions that >> create the differences in parameters...however, the notion of a >> connection is common across all these resource dimensions. GMPLS does >> not apply to the cl-ps mode, as it plainly does not have connections. > > well indeed, and this is the reason why i do not see any reason to > open the space for a different set of mechanisms that would result > from this new interface switching definition. > > thanks, > -d. > >> That is at least how I look at this issue. >> >> regards, Neil >>>>> the question triggered by this poll is the following: if >>> GMPLS for >>>>> Ethernet is not inline with the existing stacks what is >>> the value of >>>>> GMPLS re-use ? what's the value to borrow the term GMPLS >>> without its >>>>> substance ? and in practice, the issue is, if it is not >>>> GMPLS per RFC >>>>> 3945, what's the value compared to any other native control >>>> stack that >>>>> would be developed at IEEE for inst. for these techno's. >>>> If we ignore the peer model (which is unworkable in reality >>>> IMO), the value >>>> is obvious - significant reuse of existing code, techniques, >>>> knowledge, >>>> skills, etc. >>>> >>>> So, we should develop the control plane from scratch >>> because Ethernet >>>> requires a few modifications/enhancements (which I believe are >>>> backwards >>>> compatible) to RFC3945 - that IMO is ridiculous. >>> so you seem to agree with me. departing from RFC 3945 makes >>> little sense. it would have been interesting to see the doc >>> delivering a FIT of the GMPLS protocol arch. blocks and, in >>> particular, label allocation and distribution for Ethernet. >>> >>> thanks, >>> -dimitri. >>>> Ben >>>> >>>> >>> > > > -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 26 Jan 2008 08:53:13 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Date: Sat, 26 Jan 2008 08:45:44 -0000 Message-ID: <2ECAA42C79676B42AEBAC11229CA7D0C01CE874E@E03MVB2-UKBR.domain1.systemhost.net> Thread-Topic: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Thread-Index: AchdVFu8AEzlezFGRoK1wWa//yCoRwAwWYeAACBPVw4AK72dIAADM7/QAA2scYAAGUM9wA== From: To: , , Cc: , , Thanks Dimitri...I think I am understanding your concern/point a little better now......please see further comments below (I've snipped the mail to the salient bits): > > DP=3D> this is not what i say. i am concerned in stating beforehand > > > RFC 3945 (GMPLS Arch.) is not applicable to Ethernet. Why the=20 > > > doc. does not deliver any tangible explanation. > >=20 > > NH=3D> Is your problem that you cannot differentiate between > > the 3 network modes (of co-cs, co-ps and cl-ps)? =20 >=20 > my concern wrt specific point you bring is that the today=20 > definition in RFC 3945 for L2SC, NH=3D> I really don't think you should get too hung-up on what folks = have called things here, ie L2SC. Stick with the physics. Much of the misunderstandings I've encountered over many years stem from the OSI Ref Model, and the wrong impression it gives that there is only one/single 'L3 network'....it's a myth. ALL networks (any mode) are 'L3' in the OSI sense. Folks also tend to make the wrong association IP=3DL3 and since IP is cl-ps then cl-ps=3DL3.....then they come to Ethernet and because this is often used as a server to IP they call it 'L2' (OSI sense). But since native Ethernet is cl-ps then surely this must also be L3? Of course it is L3...all networks are! The only thing that truly matters is whether the resource you are partitioning and labelling is time, freq or space in nature....and it's then up to us as engineers how well we go about functionally specifying/equipping the layer networks we create in each of the 3 modes. And most critically here one can ONLY get deterministic resource assignment across a network if one creates a connection object. I could carry on here and go into great detail of exactly how all this works and why we have the 3 network modes, but I'll refer you to the work on unified modelling under Q12 of SG15. =20 Bottom-line: Look to the real world of networking and ask yourself why it is we see the 3 network modes....it really is not chance, but simply comes down to the physics of partitioning/labelling a finite resource (time/freq/space) domain....don't get hung-up on names for things without such a scientific basis. > GMPLS for Ethernet (with local labels or domain-wide labels=20 > or any other equivalent to "co-ps") does not result into a=20 > different definition than what's in. on the other side, i do=20 > not see how would apply GMPLS for connectionless/bridged Ethernet. NH=3D> I agree with you. GMPLS is a suite of CP functional components = for use in co mode layer networks. But my position is one based on an understanding of the physics at play here. This is why I tried to point out in my prior mail the importance of understanding that we can take an Ethernet traffic unit (packet) and apply either a cl-ps or co-ps mode behaviour to it (as a network). This is our choice. This does however require that specific functional fields of the traffic unit are present....in essence one can take short-cuts with labelling (ie remove information) in the co modes (eg omit SA, use link-local DA proxy labels that get swapped per hop) because we have a connection as a network object, but one can't take these short-cuts in the cl-ps mode because we don't have a connection. I'll assume this is obvious to everyone.....but it does require (from information considerations) that folks properly understand what a connection is (and also what it is not). But be very clear on this point: If we use a common traffic unit to create a cl-ps mode layer network and a co-ps mode layer network then these are 2 quite distinct layer networks, ie they do not operate in the same layer network space.....put more simply, we have to be careful not to mix-up their traffic units. The key points here are all to do with what we call 'characteristic information' in func arch terminology, and specifically how one assigns/manages resource. This is perhaps less clear to see in the co-ps mode than the co-cs mode when compared to the cl-ps mode. That is: In the co-cs mode labelling and resource assignment are fixed/deterministic actions, but in the co-ps mode they are decoupled actions....and whilst this flexibility has some advantages, it also carries a responsibility that lies with those designing co-ps mode layer networks not to screw things up, eg one can create merging constructs which result in complex resource and fault/perf management problems for network operators...actually the resource problem is intractable, and the only practical solution is to throw BW at the problem. regards, Neil Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 25 Jan 2008 19:51: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: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Date: Fri, 25 Jan 2008 20:49:41 +0100 Message-ID: Thread-Topic: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Thread-Index: AchdVFu8AEzlezFGRoK1wWa//yCoRwAwWYeAACBPVw4AK72dIAADM7/QAA2scYA= From: "PAPADIMITRIOU Dimitri" To: , , Cc: , , neil,=20 > -----Original Message----- > From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]=20 > Sent: Friday, January 25, 2008 2:27 PM > To: PAPADIMITRIOU Dimitri; benjamin.niven-jenkins@bt.com;=20 > lberger@labn.net > Cc: dwfedyk@nortel.com; dbrungard@att.com; ccamp@ops.ietf.org > Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt >=20 > Dimitri....see if this helps...in-line >=20 > > -----Original Message----- > > From: owner-ccamp@ops.ietf.org=20 > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of PAPADIMITRIOU Dimitri > > Sent: 25 January 2008 11:36 > > To: Niven-jenkins,B,Ben,DMF R; Lou Berger > > Cc: Don Fedyk; BRUNGARD, DEBORAH A, ATTLABS; ccamp@ops.ietf.org > > Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt > >=20 > >=20 > > ben=20 > >=20 > > > -----Original Message----- > > > From: Ben Niven-Jenkins [mailto:benjamin.niven-jenkins@bt.com] > > > Sent: Thursday, January 24, 2008 3:40 PM > > > To: PAPADIMITRIOU Dimitri; Lou Berger > > > Cc: Don Fedyk; BRUNGARD, DEBORAH A, ATTLABS; ccamp@ops.ietf.org > > > Subject: Re: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt > > >=20 > > > Dimitri, > > >=20 > > > I find your mail somewhat puzzling. > > >=20 > > > You appear to be saying that GMPLS as per RFC 3945 is set=20 > > in stone and=20 > > > nothing should modify/enhance the behaviour as specified=20 > in RFC3945=20 > > > which implies that when RFC3945 was produced the crystal ball was=20 > > > working extremely well and all possible future applications of the > > > technology had > > > been correctly envisaged. I don't believe that was the case. > >=20 > > this is not what i say. i am concerned in stating beforehand=20 > > RFC 3945 (GMPLS Arch.) is not applicable to Ethernet. Why the=20 > > doc. does not deliver any tangible explanation. >=20 > NH=3D> Is your problem that you cannot differentiate between=20 > the 3 network modes (of co-cs, co-ps and cl-ps)? =20 my concern wrt specific point you bring is that the today definition in RFC 3945 for L2SC, and in the present case GMPLS for Ethernet (with local labels or domain-wide labels or any other equivalent to "co-ps") does not result into a different definition than what's in. on the other side, i do not see how would apply GMPLS for connectionless/bridged Ethernet. =20 note also that GMPLS induces label from the interface and link characteristic (i.e. there is no "label type" in the label/label request object. > If so then looking at the work on > unified modelling in SG15/Q12 may help you. But to give a=20 > more specific > example here: We can take an Ethernet traffic unit and=20 > create either a > cl-ps and co-ps layer network based on this...in fact one can image 3 > different layer network cases here: > - traditional Etherent which does not have a directed routing > function, ie uses MAC learning, broadcast unknown, STP...this=20 > is a cl-ps > layer network > - Ethernet with an IGP providing a directed routing > function....this is also a cl-ps layer network, but it is different to > the one above > - Ethernet with a directed routing component (centralised or > distributed, ie IGP) and a signalling component that can create > connections....this would be a co-ps layer network. >=20 > These are all based on a similar traffic unit, however they=20 > form 3 quite > different layer networks (and in functional architecture=20 > terms we would > say 'the Characteristic Information is different in the 3 cases'). >=20 > Now GMPLS is applying a reusable set of CP components (which is a very > good thing, as Ben points out below) for any co-cs or co-ps mode layer > network. So we are setting up *connections* in either a=20 > space, freq or > time dimension of resource, and it is these 3 resource dimensions that > create the differences in parameters...however, the notion of a > connection is common across all these resource dimensions. GMPLS does > not apply to the cl-ps mode, as it plainly does not have connections. well indeed, and this is the reason why i do not see any reason to open the space for a different set of mechanisms that would result from this new interface switching definition. thanks, -d. =20 > That is at least how I look at this issue. >=20 > regards, Neil > >=20 > > > > the question triggered by this poll is the following: if=20 > > GMPLS for=20 > > > > Ethernet is not inline with the existing stacks what is=20 > > the value of=20 > > > > GMPLS re-use ? what's the value to borrow the term GMPLS=20 > > without its=20 > > > > substance ? and in practice, the issue is, if it is not > > > GMPLS per RFC > > > > 3945, what's the value compared to any other native control > > > stack that > > > > would be developed at IEEE for inst. for these techno's. > > >=20 > > > If we ignore the peer model (which is unworkable in reality > > > IMO), the value > > > is obvious - significant reuse of existing code, techniques,=20 > > > knowledge, > > > skills, etc. > > >=20 > > > So, we should develop the control plane from scratch=20 > > because Ethernet=20 > > > requires a few modifications/enhancements (which I believe are=20 > > > backwards > > > compatible) to RFC3945 - that IMO is ridiculous. > >=20 > > so you seem to agree with me. departing from RFC 3945 makes=20 > > little sense. it would have been interesting to see the doc=20 > > delivering a FIT of the GMPLS protocol arch. blocks and, in=20 > > particular, label allocation and distribution for Ethernet. > >=20 > > thanks, > > -dimitri. > > > Ben > > >=20 > > >=20 > >=20 > >=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 25 Jan 2008 18:28:48 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C85F7F.DF993ECD" Subject: Question on TLV Length Calculation Date: Fri, 25 Jan 2008 13:26:58 -0500 Message-ID: <23F9E58A916663488B3D12D1FE1A999FD0E447@mdmxm03.ciena.com> Thread-Topic: Question on TLV Length Calculation Thread-Index: Achff96tisrbld+EScO7kgUbNhjd0w== From: "Ong, Lyndon" To: This is a multi-part message in MIME format. ------_=_NextPart_001_01C85F7F.DF993ECD Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Folks, =20 Simple question on length calculation for RSVP-TE TLVs: I've noticed that=20 draft-ietf-ccamp-ethernet-traffic-parameters-03.txt has adopted a method of calculating TLV length from RFC 4420, where the length includes only the value portion of the TLV, and does not include the header (type and length bytes) or any padding bytes. =20 This is a bit different from how length is computed for objects and sub-objects, where length includes header as well. Having not followed the discussion=20 on RFC 4420 closely, can someone clarify: =20 -- is this method of length calculation to be followed on all new TLVs defined for RSVP-TE? =20 -- if not, is there some basis for deciding what calculation to follow when=20 defining a new TLV? =20 Thanks, =20 Lyndon ------_=_NextPart_001_01C85F7F.DF993ECD Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 Folks,
 
Simple = question on=20 length calculation for RSVP-TE TLVs:  I've noticed that=20
draft-ietf-ccamp-ethernet-traffic-parameters-0= 3.txt has=20 adopted a method of
calculating TLV=20 length from RFC 4420, where the length includes only = the
value = portion of the=20 TLV, and does not include the header (type and = length
bytes) = or any=20 padding bytes.
 
This = is a bit=20 different from how length is computed for objects and=20 sub-objects,
where = length=20 includes header as well.  Having not followed the discussion=20
on RFC = 4420 closely,=20 can someone clarify:
 
-- is = this method of=20 length calculation to be followed on all new TLVs = defined
for=20 RSVP-TE?
 
-- if = not, is there=20 some basis for deciding what calculation to follow when =
defining a new=20 TLV?
 
Thanks,
 
Lyndon
------_=_NextPart_001_01C85F7F.DF993ECD-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 25 Jan 2008 13:55:27 +0000 User-Agent: Microsoft-Entourage/11.2.5.060620 Date: Fri, 25 Jan 2008 13:54:23 +0000 Subject: Re: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt From: Ben Niven-Jenkins To: PAPADIMITRIOU Dimitri , Lou Berger CC: Don Fedyk , "BRUNGARD, DEBORAH A, ATTLABS" , Message-ID: Thread-Topic: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Thread-Index: AchdVFu8AEzlezFGRoK1wWa//yCoRwAwWYeAACBPVw4AK72dIAAE9SaI Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit On 25/1/08 11:36, "PAPADIMITRIOU Dimitri" wrote: > this is not what i say. i am concerned in stating beforehand > RFC 3945 (GMPLS Arch.) is not applicable to Ethernet. Why the > doc. does not deliver any tangible explanation. OK, now I understand your concerns. So, I think we're (you, me & the docs authors) are actually in agreement in our thinking, just maybe that the original wording in the doc was not the best. I'm sure the authors can do some wordsmithing once it is a WG doc. > so you seem to agree with me. departing from RFC 3945 makes > little sense. it would have been interesting to see the doc > delivering a FIT of the GMPLS protocol arch. blocks and, in > particular, label allocation and distribution for Ethernet. Departing from RFC3945 for the sake of it makes little sense. If there is a justifiable reason to depart then that is fine IMO. Ben Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 25 Jan 2008 13:29:32 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Date: Fri, 25 Jan 2008 13:26:40 -0000 Message-ID: <2ECAA42C79676B42AEBAC11229CA7D0C01C98951@E03MVB2-UKBR.domain1.systemhost.net> Thread-Topic: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Thread-Index: AchdVFu8AEzlezFGRoK1wWa//yCoRwAwWYeAACBPVw4AK72dIAADM7/Q From: To: , , Cc: , , Dimitri....see if this helps...in-line > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of PAPADIMITRIOU Dimitri > Sent: 25 January 2008 11:36 > To: Niven-jenkins,B,Ben,DMF R; Lou Berger > Cc: Don Fedyk; BRUNGARD, DEBORAH A, ATTLABS; ccamp@ops.ietf.org > Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt >=20 >=20 > ben=20 >=20 > > -----Original Message----- > > From: Ben Niven-Jenkins [mailto:benjamin.niven-jenkins@bt.com] > > Sent: Thursday, January 24, 2008 3:40 PM > > To: PAPADIMITRIOU Dimitri; Lou Berger > > Cc: Don Fedyk; BRUNGARD, DEBORAH A, ATTLABS; ccamp@ops.ietf.org > > Subject: Re: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt > >=20 > > Dimitri, > >=20 > > I find your mail somewhat puzzling. > >=20 > > You appear to be saying that GMPLS as per RFC 3945 is set=20 > in stone and=20 > > nothing should modify/enhance the behaviour as specified in RFC3945=20 > > which implies that when RFC3945 was produced the crystal ball was=20 > > working extremely well and all possible future applications of the > > technology had > > been correctly envisaged. I don't believe that was the case. >=20 > this is not what i say. i am concerned in stating beforehand=20 > RFC 3945 (GMPLS Arch.) is not applicable to Ethernet. Why the=20 > doc. does not deliver any tangible explanation. NH=3D> Is your problem that you cannot differentiate between the 3 = network modes (of co-cs, co-ps and cl-ps)? If so then looking at the work on unified modelling in SG15/Q12 may help you. But to give a more specific example here: We can take an Ethernet traffic unit and create either a cl-ps and co-ps layer network based on this...in fact one can image 3 different layer network cases here: - traditional Etherent which does not have a directed routing function, ie uses MAC learning, broadcast unknown, STP...this is a cl-ps layer network - Ethernet with an IGP providing a directed routing function....this is also a cl-ps layer network, but it is different to the one above - Ethernet with a directed routing component (centralised or distributed, ie IGP) and a signalling component that can create connections....this would be a co-ps layer network. These are all based on a similar traffic unit, however they form 3 quite different layer networks (and in functional architecture terms we would say 'the Characteristic Information is different in the 3 cases'). Now GMPLS is applying a reusable set of CP components (which is a very good thing, as Ben points out below) for any co-cs or co-ps mode layer network. So we are setting up *connections* in either a space, freq or time dimension of resource, and it is these 3 resource dimensions that create the differences in parameters...however, the notion of a connection is common across all these resource dimensions. GMPLS does not apply to the cl-ps mode, as it plainly does not have connections. That is at least how I look at this issue. regards, Neil >=20 > > > the question triggered by this poll is the following: if=20 > GMPLS for=20 > > > Ethernet is not inline with the existing stacks what is=20 > the value of=20 > > > GMPLS re-use ? what's the value to borrow the term GMPLS=20 > without its=20 > > > substance ? and in practice, the issue is, if it is not > > GMPLS per RFC > > > 3945, what's the value compared to any other native control > > stack that > > > would be developed at IEEE for inst. for these techno's. > >=20 > > If we ignore the peer model (which is unworkable in reality > > IMO), the value > > is obvious - significant reuse of existing code, techniques,=20 > > knowledge, > > skills, etc. > >=20 > > So, we should develop the control plane from scratch=20 > because Ethernet=20 > > requires a few modifications/enhancements (which I believe are=20 > > backwards > > compatible) to RFC3945 - that IMO is ridiculous. >=20 > so you seem to agree with me. departing from RFC 3945 makes=20 > little sense. it would have been interesting to see the doc=20 > delivering a FIT of the GMPLS protocol arch. blocks and, in=20 > particular, label allocation and distribution for Ethernet. >=20 > thanks, > -dimitri. > > Ben > >=20 > >=20 >=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 25 Jan 2008 11:38:22 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Date: Fri, 25 Jan 2008 12:36:23 +0100 Message-ID: Thread-Topic: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Thread-Index: AchdVFu8AEzlezFGRoK1wWa//yCoRwAwWYeAACBPVw4AK72dIA== From: "PAPADIMITRIOU Dimitri" To: "Ben Niven-Jenkins" , "Lou Berger" Cc: "Don Fedyk" , "BRUNGARD, DEBORAH A, ATTLABS" , ben=20 > -----Original Message----- > From: Ben Niven-Jenkins [mailto:benjamin.niven-jenkins@bt.com]=20 > Sent: Thursday, January 24, 2008 3:40 PM > To: PAPADIMITRIOU Dimitri; Lou Berger > Cc: Don Fedyk; BRUNGARD, DEBORAH A, ATTLABS; ccamp@ops.ietf.org > Subject: Re: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt >=20 > Dimitri, >=20 > I find your mail somewhat puzzling. >=20 > You appear to be saying that GMPLS as per RFC 3945 is set in stone and > nothing should modify/enhance the behaviour as specified in=20 > RFC3945 which > implies that when RFC3945 was produced the crystal ball was working > extremely well and all possible future applications of the=20 > technology had > been correctly envisaged. I don't believe that was the case. this is not what i say. i am concerned in stating beforehand RFC 3945 (GMPLS Arch.) is not applicable to Ethernet. Why the doc. does not deliver any tangible explanation. > > the question triggered by this poll is the following: if GMPLS for > > Ethernet is not inline with the existing stacks what is the value of > > GMPLS re-use ? what's the value to borrow the term GMPLS without its > > substance ? and in practice, the issue is, if it is not=20 > GMPLS per RFC > > 3945, what's the value compared to any other native control=20 > stack that > > would be developed at IEEE for inst. for these techno's. >=20 > If we ignore the peer model (which is unworkable in reality=20 > IMO), the value > is obvious - significant reuse of existing code, techniques,=20 > knowledge, > skills, etc. >=20 > So, we should develop the control plane from scratch because Ethernet > requires a few modifications/enhancements (which I believe=20 > are backwards > compatible) to RFC3945 - that IMO is ridiculous. so you seem to agree with me. departing from RFC 3945 makes little sense. it would have been interesting to see the doc delivering a FIT of the GMPLS protocol arch. blocks and, in particular, label allocation and distribution for Ethernet. thanks, -dimitri. > Ben >=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 25 Jan 2008 09:48:42 +0000 User-Agent: Microsoft-Entourage/11.2.5.060620 Date: Thu, 24 Jan 2008 14:40:00 +0000 Subject: Re: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt From: Ben Niven-Jenkins To: PAPADIMITRIOU Dimitri , Lou Berger CC: Don Fedyk , "BRUNGARD, DEBORAH A, ATTLABS" , Message-ID: Thread-Topic: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Thread-Index: AchdVFu8AEzlezFGRoK1wWa//yCoRwAwWYeAACBPVw4= Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Dimitri, I find your mail somewhat puzzling. You appear to be saying that GMPLS as per RFC 3945 is set in stone and nothing should modify/enhance the behaviour as specified in RFC3945 which implies that when RFC3945 was produced the crystal ball was working extremely well and all possible future applications of the technology had been correctly envisaged. I don't believe that was the case. > the question triggered by this poll is the following: if GMPLS for > Ethernet is not inline with the existing stacks what is the value of > GMPLS re-use ? what's the value to borrow the term GMPLS without its > substance ? and in practice, the issue is, if it is not GMPLS per RFC > 3945, what's the value compared to any other native control stack that > would be developed at IEEE for inst. for these techno's. If we ignore the peer model (which is unworkable in reality IMO), the value is obvious - significant reuse of existing code, techniques, knowledge, skills, etc. So, we should develop the control plane from scratch because Ethernet requires a few modifications/enhancements (which I believe are backwards compatible) to RFC3945 - that IMO is ridiculous. Ben Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 25 Jan 2008 09:06:22 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C85F31.21C359D3" Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Date: Fri, 25 Jan 2008 10:03:29 +0100 Message-ID: <0428AC48A879ED46A94F39D5665DF6840100234F@esealmw110.eemea.ericsson.se> Thread-Topic: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt thread-index: AchdLOH3JrqySZgzQVuueGk7Nk+CoACBCarA From: "Diego Caviglia" To: "BRUNGARD, DEBORAH A, ATTLABS" , This is a multi-part message in MIME format. ------_=_NextPart_001_01C85F31.21C359D3 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I support this as WG even if I'd like to have the Dimitri questions = addressed, may in next WG version of the doc. =20 LBR Diego =20 ________________________________ From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On = Behalf Of BRUNGARD, DEBORAH A, ATTLABS Sent: marted=EC 22 gennaio 2008 20.28 To: ccamp@ops.ietf.org Subject: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt =20 CCAMP, =20 The DT proposed in their meeting presentation for their architecture and = framework document to be accepted as a WG draft: http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt =20 We received a couple of comments in the meeting, we would appreciate = additional feedback on the list. Please express your support (or = otherwise) for this I-D to become a WG draft. =20 Thanks, Deborah ------_=_NextPart_001_01C85F31.21C359D3 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I support this as WG even if = I’d like to have the Dimitri questions addressed, may in next WG version of = the doc.

 

LBR


Diego

 

From: = owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On = Behalf Of BRUNGARD, DEBORAH A, ATTLABS
Sent: marted=EC 22 = gennaio 2008 20.28
To: = ccamp@ops.ietf.org
Subject: Proposed WG = Draft - draft-gmpls-ethernet-arch-00.txt

 

CCAMP,

 

The DT proposed in their meeting = presentation for their architecture and framework document to be accepted as = a WG draft:

 

We received a couple of comments in the meeting, = we would appreciate additional feedback on the list. Please express = your support (or otherwise) for this I-D to become a WG = draft.

 

Thanks,

Deborah

------_=_NextPart_001_01C85F31.21C359D3-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 24 Jan 2008 23:32:31 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C85EE0.A815503E" Subject: LSPID for Segment Recovery Date: Thu, 24 Jan 2008 17:27:16 -0600 Message-ID: Thread-Topic: LSPID for Segment Recovery Thread-Index: Ache4KgQ2YcByof3RWGUMtyDsZsljw== From: "Bardalai, Snigdho" To: "Ccamp (E-mail)" Cc: "Adrian Farrel (E-mail)" , "Lou Berger (E-mail)" This is a multi-part message in MIME format. ------_=_NextPart_001_01C85EE0.A815503E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I have a doubt on the relationship between LSPID and association ID for = tunnels with segment recovery. Would appreciate it if someone could = clarify. RFC4872 suggests using the working LSP's LSPID as the association ID in = the ASSOCIATION object for the recovery LSP and the reverse for the = working LSP and RFC4873 requires the use of this definition as per the = following extract: 2. Segment Recovery snip ...... snip When [RFC4090] isn't being used, the association between segment recovery LSPs with other LSPs is indicated using the ASSOCIATION object defined in [RFC4872] snip...... I would expect this definition includes the way the association ID value = should be assigned, is my understanding correct?=20 I can understand how the ASSOCIATION object for the recovery LSP can = have its association ID set to the working LSP LSPID but it may not be = possible for the reverse since there could be multiple recovery LSP = segments.=20 I would like to understand what should the working LSP association ID be = in case of segment recovery, should it be set to its own LSPID? Also, my understanding is that the association ID needs to be unique in = the context of the association source, if that is the case does it mean = if LSPID is used as the association ID then the LSPID should also be = unique in the context of the association source rather than the context = of a tunnel. Thanks, Snigdho ------_=_NextPart_001_01C85EE0.A815503E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable LSPID for Segment Recovery

Hi,

I have a doubt on the relationship = between LSPID and association ID for tunnels with segment recovery. = Would appreciate it if someone could clarify.

RFC4872 suggests using the working = LSP's LSPID as the association ID in the ASSOCIATION object for the = recovery LSP and the reverse for the working LSP and RFC4873 requires = the use of this definition as per the following extract:

2.  Segment Recovery

   snip ...... snip

   When [RFC4090] isn't being = used, the association between segment
   recovery LSPs with other = LSPs is indicated using the ASSOCIATION
   object defined in = [RFC4872]

   snip......

I would expect this definition includes = the way the association ID value should be assigned, is my understanding = correct?

I can understand how the ASSOCIATION = object for the recovery LSP can have its association ID set to the = working LSP LSPID but it may not be possible for the reverse since there = could be multiple recovery LSP segments.

I would like to understand what should = the working LSP association ID be in case of segment recovery, should it = be set to its own LSPID?

Also, my understanding is that the = association ID needs to be unique in the context of the association = source, if that is the case does it mean if LSPID is used as the = association ID then the LSPID should also be unique in the context of = the association source rather than the context of a tunnel.

Thanks,
Snigdho

------_=_NextPart_001_01C85EE0.A815503E-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 24 Jan 2008 17:51:29 +0000 Message-ID: <4798CFB3.3030605@grotto-networking.com> Date: Thu, 24 Jan 2008 09:49:39 -0800 From: Greg Bernstein User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: ccamp CC: Adrian Farrel Subject: Calls, Connections and VCAT... Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello all, and Adrian and "GMPLS call" authors in particular. I've been reviewing the requirements for VCAT/LCAS and potential additions, the definition of "call" from G.8081 (2004) and trying to reconcile these in an efficient manner so we can move forward with the GMPLS/VCAT draft. Definitions from G.8081: 3.2.6 call: An association between endpoints that supports an instance of a service. 3.2.7 call control: Call control is a signalling association between one or more user applications and the network to control the set-up, release, modification and maintenance of sets of connections. Additional information from G.8080 (2006) section 5.1: "Additionally, call control is provided at interlayer NCC boundaries." From these definitions it seems that the use of "call control" to coordinate an inverse multiplexing technology is actually recommended (since this is the domain boundary between to layers). However in trying to use RFC4974 along with the additional requirements that have come up (and seem desired), I seem to have a problem when I want to utilize an existing connection with a new call. In RFC4974. Section 5.2.2. It says: "The Connections (LSPs) associated with a Call need to carry a reference to the Call - the short Call ID. A new field is added to the signaling protocol to identify an individual LSP with the Call to which it belongs." This is where the complications come in, since we cannot change "session" information on an LSP and hence can't change the Call ID. But do we always need the call ID with the LSP? In section 4.2 of RFC4974 the hierarchy of of calls, connections, tunnels and LSP is given and it seems that (Session, Tunnel ID, LSP ID) can be used to uniquely identify the LSP too. The feedback I received concerning VCAT signaling approaches included: (a) support for Notify based mechanism (b) strong opposition to the current multiple VCGs per call work around for "resource sharing" (c) mild interest, but no proposals in something else entirely. Hence at this stage and based on my reading of G.8080, G.8081, I'd like to try to fix the "call" approach. Other solution proposals are welcome, but I will not be actively pursuing them. Regards Greg B. -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 24 Jan 2008 16:03:40 +0000 Date: Thu, 24 Jan 2008 11:00:34 -0500 To: ccamp@ops.ietf.org From: Lou Berger Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Cc: "BRUNGARD, DEBORAH A, ATTLABS" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-Id: All, I think this level of theoretical/hypothetical discussion can continue ad infinitum. I propose we leave the text as is, and revisit the decision (and text) in the context of the anticipated mechanism specific documents if and when someone propose to use L2SC. WG-chairs, Does this make sense? Is it acceptable? Thanks, Lou At 09:51 PM 1/23/2008, Don Fedyk wrote: >Hi Dimitri > >The document clearly states: > >"The intent of this document is to reuse and align with as much of the > GMPLS protocols as possible. For example reusing the IP control > plane addressing allows the existing signaling, routing, LMP and path > computation to be used as specified. Additions are made only to > accommodate features of Ethernet that are not already supported by > GMPLS. The GMPLS protocols support a set of tools for hierarchical > LSPs as well as contiguous LSPs. GMPLS specific protocol mechanisms > support a variety of networks from peer to peer to UNIs and NNIs." > >So your question comes down to why we make the statement on L2SC? Like >Lou said when we discussed this we thought that L2SC came with baggage >and was not precise. The switching capabilities would be specified in >documents that address the particular Ethernet data plane. It is true >that if there was a valid Ethernet data plane that could use L2SC >unambiguously it should fit under the architecture. At any rate getting >this right is something that can be accomplished when this is a WG >draft. > >Regards, >Don > > > > > -----Original Message----- > > From: PAPADIMITRIOU Dimitri > > [mailto:Dimitri.Papadimitriou@alcatel-lucent.be] > > Sent: Wednesday, January 23, 2008 7:05 PM > > To: Lou Berger > > Cc: Fedyk, Don (BL60:1A00); BRUNGARD, DEBORAH A, ATTLABS; > > ccamp@ops.ietf.org > > Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt > > > > the question triggered by this poll is the following: if GMPLS for > > Ethernet is not inline with the existing stacks what is the value of > > GMPLS re-use ? what's the value to borrow the term GMPLS without its > > substance ? and in practice, the issue is, if it is not GMPLS per RFC > > 3945, what's the value compared to any other native control stack that > > would be developed at IEEE for inst. for these techno's. > > > > you quote: > > > > > L2SC was always underspecified (e.g., covers both ATM and Ether), > > > > additional specification does not result in departing from the initial > > definition but refinement of the initial definition (definition of a > > sub-set not a side definition). > > > > probably the document is not mature enough to respond to the > > tie-breaker: what about the FIT of GMPLS for Ethernet but not > > within the > > L2SC space (as defined today) ? but in the meantime preclude > > any allowed > > use of GMPLS per IETF RFCs to Ethernet if they do not comply > > with a new > > WG i-d would create a precedent in the history of this WG with really > > disastrous impact (including on other application of GMPLS) > > > > we're at a turning point (equivalent to RSVP vs RSVP-TE). we need to > > assess consequences before going one way or another and under which > > conditions. > > > > -d. > > > > > -----Original Message----- > > > From: owner-ccamp@ops.ietf.org > > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Lou Berger > > > Sent: Wednesday, January 23, 2008 1:09 AM > > > To: PAPADIMITRIOU Dimitri > > > Cc: Lou Berger; Don Fedyk; BRUNGARD, DEBORAH A, ATTLABS; > > > ccamp@ops.ietf.org > > > Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt > > > > > > We've always had different switching type/capability in > > > GMPLS. Nothing new here. > > > > > > L2SC was always underspecified (e.g., covers both ATM and > > Ether), is > > > currently used by some for different purposes, and doesn't allow > > > unique identification of switching capabilities of an interface. I > > > *really* don't see the unique identification of an interface's > > > Ethernet switching function as any different from what is done for > > > today for the other types or as any big deal or change in GMPLS > > > direction or architecture. > > > > > > but, that's just my perspective. > > > > > > Lou > > > > > > At 05:44 PM 1/22/2008, PAPADIMITRIOU Dimitri wrote: > > > >thus the question is whether or not to ask for a change > > CCAMP "common > > > >control" in DCAMP "differentiated control" per technology ? > > > > > > > >we never have had a techno inducing a base building block > > > change (GMPLS > > > >being a generalisation of MPLS-TE). i'm afraid that > > generalized LSP, > > > >generalized LSR, generalized label, etc. per GMPLS arch (RFC > > > 3945) would > > > >simply be unapplicable as known today and thus the corr. > > > base protocol > > > >specs unapplicable. at the end the term "GMPLS" would be > > > emptied of any > > > >real substance. > > > > > > > >it's a choice but let's ask the questions from the right > > perspective. > > > > > > > >-d. > > > > > > > > > -----Original Message----- > > > > > From: Lou Berger [mailto:lberger@labn.net] > > > > > Sent: Tuesday, January 22, 2008 11:28 PM > > > > > To: PAPADIMITRIOU Dimitri > > > > > Cc: Lou Berger; Don Fedyk; BRUNGARD, DEBORAH A, ATTLABS; > > > > > ccamp@ops.ietf.org > > > > > Subject: RE: Proposed WG Draft - > > draft-gmpls-ethernet-arch-00.txt > > > > > > > > > > I have no objection to adding "Updates: 3945" to the > > > document header > > > > > and matching 3945's category. > > > > > > > > > > Lou > > > > > > > > > > At 05:11 PM 1/22/2008, PAPADIMITRIOU Dimitri wrote: > > > > > >Lou > > > > > > > > > > > >what i am concerned with: is that the doc extends > > > > > applicability of GMPLS > > > > > >to Ethernet by excluding GMPLS for Ethernet per RFC 3945 > > > ? does that > > > > > >make sense ? > > > > > > > > > > > >what's needed instead of hiding behind terms is to state > > > GMPLS for Y, > > > > > >where Y includes the set of Ethernet-based techno's under > > > > > development at > > > > > >places as indicated in the doc itself. instead of > > > inducing by a title > > > > > >such as "GMPLS for Ethernet" that this doc supersedes any > > > > > previous work > > > > > >in that > > > > > >space. > > > > > > > > > > > >-d. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: owner-ccamp@ops.ietf.org > > > > > > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Lou Berger > > > > > > > Sent: Tuesday, January 22, 2008 10:50 PM > > > > > > > To: Don Fedyk > > > > > > > Cc: PAPADIMITRIOU Dimitri; BRUNGARD, DEBORAH A, ATTLABS; > > > > > > > ccamp@ops.ietf.org > > > > > > > Subject: RE: Proposed WG Draft - > > > draft-gmpls-ethernet-arch-00.txt > > > > > > > > > > > > > > Don, > > > > > > > I agree 100%. Furthermore there is no > > > statement in the > > > > > > > draft that 3945 doesn't apply, in fact it explicitly > > > says just the > > > > > > > opposite. The reason for the statement in question is > > > > > simply as you > > > > > > > say, and to ensure full ETH-LSP definition and interoperable > > > > > > > operation a new switching type/capability is required. > > > > > > > > > > > > > > It's really not such a bid deal or major change. > > > > > > > > > > > > > > Lou > > > > > > > > > > > > > > At 04:34 PM 1/22/2008, Don Fedyk wrote: > > > > > > > >Hi Dimitri > > > > > > > > > > > > > > > >The text you quote was put in the architecture/ > > > framework, not to > > > > > > > >exclude L2 Switch Capable (L2SC) but to prevent redefining > > > > > > > L2SC, which > > > > > > > >has been there for many years and may be in use. > > > > > > > > > > > > > > > >Perhaps the working needs to be adjusted but I don't think > > > > > > > it is a major > > > > > > > >issue. > > > > > > > > > > > > > > > >Regards, > > > > > > > >Don > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: owner-ccamp@ops.ietf.org > > > > > > > > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of > > > > > > > PAPADIMITRIOU Dimitri > > > > > > > > > Sent: Tuesday, January 22, 2008 4:16 PM > > > > > > > > > To: BRUNGARD, DEBORAH A, ATTLABS; ccamp@ops.ietf.org > > > > > > > > > Subject: RE: Proposed WG Draft - > > > > > draft-gmpls-ethernet-arch-00.txt > > > > > > > > > > > > > > > > > > All, > > > > > > > > > > > > > > > > > > > We received a couple of comments in the > > > meeting, we would > > > > > > > > > > appreciate additional feedback on the list. > > > > > > > > > > > > > > > > > > The document states: > > > > > > > > > > > > > > > > > > "The L2SC Interface Switching Capabilities MUST > > > NOT be used > > > > > > > > > to represent > > > > > > > > > interfaces capable of supporting Eth-LSPs. > > > Interface Switching > > > > > > > > > Capability specific TE information may be defined as > > > > > > > needed to support > > > > > > > > > the requirements of a specific Ethernet Switching > > > > > Service Type." > > > > > > > > > > > > > > > > > > [...] > > > > > > > > > > > > > > > > > > "It is expected that there will be no case where an > > > > > > > Eth-LSP will be > > > > > > > > > signaled, or an Eth-LSP supporting interface will be > > > > > > > > > represented, using > > > > > > > > > the L2SC switching type/capability. A new switching > > > > > > > type/capability is > > > > > > > > > required to avoid any potential current usage > > of the L2SC > > > > > > > switching > > > > > > > > > type/capability in support of Ethernet." > > > > > > > > > > > > > > > > > > This is explicit statement that GMPLS per RFC > > 3945 is not > > > > > > > applicable. > > > > > > > > > So, it is much more than just an additional > > codepoint, as > > > > > > > the control > > > > > > > > > plane behaviour is to be defined for this > > > codepoint. So, it > > > > > > > > > is the open > > > > > > > > > door for a new control plane behaviour. > > > > > > > > > > > > > > > > > > so, let's have a more basic questioning before jumping > > > > > > > into the single > > > > > > > > > alternative resulting from this doc.: > > > > > > > > > > > > > > > > > > - either it is GMPLS for Ethernet architecture and then > > > > > > > what exist in > > > > > > > > > current RFCs should be applicable (because i do not see > > > > > > > any rationale > > > > > > > > > for L2SC def. departure for Ethernet frame processing); > > > > > > > > > > > > > > > > > > - or not it is X for Y architecture, where X is an IP > > > > > > > control protocol > > > > > > > > > based some potentially on some existing GMPLS blocks > > > > > and Y is not > > > > > > > > > compatible with the existing definition of Eth frame > > > > > processing. > > > > > > > > > > > > > > > > > > In the latter case, i do not know how this WG can deal > > > > > > > with such case > > > > > > > > > (from the control plane perspective). > > > > > > > > > > > > > > > > > > -d. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: owner-ccamp@ops.ietf.org > > > > > > > > > > [mailto:owner-ccamp@ops.ietf.org] On Behalf > > Of BRUNGARD, > > > > > > > > > > DEBORAH A, ATTLABS > > > > > > > > > > Sent: Tuesday, January 22, 2008 8:28 PM > > > > > > > > > > To: ccamp@ops.ietf.org > > > > > > > > > > Subject: Proposed WG Draft - > > > > > draft-gmpls-ethernet-arch-00.txt > > > > > > > > > > > > > > > > > > > > CCAMP, > > > > > > > > > > > > > > > > > > > > The DT proposed in their meeting presentation > > for their > > > > > > > > > > architecture and framework document to be > > accepted as a > > > > > > > WG draft: > > > > > > > > > > > > > > > > > > > > > > > > > http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt > > > > > > > > > > > > > > > > > > > > We received a couple of comments in the > > > meeting, we would > > > > > > > > > > appreciate additional feedback on the list. > > > Please express > > > > > > > > > > your support (or otherwise) for this I-D to become > > > > > a WG draft. > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > Deborah > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 24 Jan 2008 08:25:40 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Date: Thu, 24 Jan 2008 09:23:21 +0100 Message-ID: Thread-Topic: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Thread-Index: AchdVFu8AEzlezFGRoK1wWa//yCoRwAwWYeAAAbEl1AAC/YakA== From: "PAPADIMITRIOU Dimitri" To: "Don Fedyk" , "Lou Berger" Cc: "BRUNGARD, DEBORAH A, ATTLABS" , Hi Don so, what's wrong with the definition of L2SC then ? from 3945: 2. Layer-2 Switch Capable (L2SC) interfaces: Interfaces that recognize frame/cell boundaries and can switch data based on the content of the frame/cell header. Examples include interfaces on Ethernet bridges that switch data based on the content of the MAC header and interfaces on ATM-LSRs that forward data based on the ATM VPI/VCI.=20 as such the statement "A new switching type/capability is required to avoid any potential current usage of the L2SC switching type/capability=20 in support of Ethernet." is made but never explained why in the doc - now coming down to the first sentence you indicated from your doc. "The intent of this document is to reuse and align with as much of the GMPLS protocols as possible.... Additions are made only to accommodate=20 features of Ethernet that are not already supported by GMPLS." It should have been something like: "This doc. details the GMPLS protocol suite architecture for Ethernet. Extensions are made only=20 to accommodate features of Ethernet that are not already supported=20 by GMPLS RFCs and inline with its architecture defined in RFC 3945." otherwise the result would be progressively that all GMPLS RFCs are cracked down to accommodate Ethernet. thanks, -d. > -----Original Message----- > From: Don Fedyk [mailto:dwfedyk@nortel.com]=20 > Sent: Thursday, January 24, 2008 3:51 AM > To: PAPADIMITRIOU Dimitri; Lou Berger > Cc: BRUNGARD, DEBORAH A, ATTLABS; ccamp@ops.ietf.org > Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt >=20 > Hi Dimitri >=20 > The document clearly states: >=20 > "The intent of this document is to reuse and align with as much of the > GMPLS protocols as possible. For example reusing the IP control > plane addressing allows the existing signaling, routing,=20 > LMP and path > computation to be used as specified. Additions are made only to > accommodate features of Ethernet that are not already supported by > GMPLS. The GMPLS protocols support a set of tools for hierarchical > LSPs as well as contiguous LSPs. GMPLS specific protocol mechanisms > support a variety of networks from peer to peer to UNIs and NNIs." >=20 > So your question comes down to why we make the statement on=20 > L2SC? Like > Lou said when we discussed this we thought that L2SC came with baggage > and was not precise. The switching capabilities would be specified in > documents that address the particular Ethernet data plane. It is true > that if there was a valid Ethernet data plane that could use L2SC > unambiguously it should fit under the architecture. At any=20 > rate getting > this right is something that can be accomplished when this is a WG > draft.=20 >=20 > Regards, > Don=20 >=20 >=20 >=20 > > -----Original Message----- > > From: PAPADIMITRIOU Dimitri=20 > > [mailto:Dimitri.Papadimitriou@alcatel-lucent.be]=20 > > Sent: Wednesday, January 23, 2008 7:05 PM > > To: Lou Berger > > Cc: Fedyk, Don (BL60:1A00); BRUNGARD, DEBORAH A, ATTLABS;=20 > > ccamp@ops.ietf.org > > Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt > >=20 > > the question triggered by this poll is the following: if GMPLS for > > Ethernet is not inline with the existing stacks what is the value of > > GMPLS re-use ? what's the value to borrow the term GMPLS without its > > substance ? and in practice, the issue is, if it is not=20 > GMPLS per RFC > > 3945, what's the value compared to any other native control=20 > stack that > > would be developed at IEEE for inst. for these techno's. > >=20 > > you quote: > >=20 > > > L2SC was always underspecified (e.g., covers both ATM and Ether), > >=20 > > additional specification does not result in departing from=20 > the initial > > definition but refinement of the initial definition (definition of a > > sub-set not a side definition). > >=20 > > probably the document is not mature enough to respond to the > > tie-breaker: what about the FIT of GMPLS for Ethernet but not=20 > > within the > > L2SC space (as defined today) ? but in the meantime preclude=20 > > any allowed > > use of GMPLS per IETF RFCs to Ethernet if they do not comply=20 > > with a new > > WG i-d would create a precedent in the history of this WG=20 > with really > > disastrous impact (including on other application of GMPLS) > >=20 > > we're at a turning point (equivalent to RSVP vs RSVP-TE). we need to > > assess consequences before going one way or another and under which > > conditions. > >=20 > > -d. > >=20 > > > -----Original Message----- > > > From: owner-ccamp@ops.ietf.org=20 > > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Lou Berger > > > Sent: Wednesday, January 23, 2008 1:09 AM > > > To: PAPADIMITRIOU Dimitri > > > Cc: Lou Berger; Don Fedyk; BRUNGARD, DEBORAH A, ATTLABS;=20 > > > ccamp@ops.ietf.org > > > Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt > > >=20 > > > We've always had different switching type/capability in=20 > > > GMPLS. Nothing new here. > > >=20 > > > L2SC was always underspecified (e.g., covers both ATM and=20 > > Ether), is=20 > > > currently used by some for different purposes, and doesn't allow=20 > > > unique identification of switching capabilities of an=20 > interface. I=20 > > > *really* don't see the unique identification of an interface's=20 > > > Ethernet switching function as any different from what is=20 > done for=20 > > > today for the other types or as any big deal or change in GMPLS=20 > > > direction or architecture. > > >=20 > > > but, that's just my perspective. > > >=20 > > > Lou > > >=20 > > > At 05:44 PM 1/22/2008, PAPADIMITRIOU Dimitri wrote: > > > >thus the question is whether or not to ask for a change=20 > > CCAMP "common > > > >control" in DCAMP "differentiated control" per technology ? > > > > > > > >we never have had a techno inducing a base building block=20 > > > change (GMPLS > > > >being a generalisation of MPLS-TE). i'm afraid that=20 > > generalized LSP, > > > >generalized LSR, generalized label, etc. per GMPLS arch (RFC=20 > > > 3945) would > > > >simply be unapplicable as known today and thus the corr.=20 > > > base protocol > > > >specs unapplicable. at the end the term "GMPLS" would be=20 > > > emptied of any > > > >real substance. > > > > > > > >it's a choice but let's ask the questions from the right=20 > > perspective. > > > > > > > >-d. > > > > > > > > > -----Original Message----- > > > > > From: Lou Berger [mailto:lberger@labn.net] > > > > > Sent: Tuesday, January 22, 2008 11:28 PM > > > > > To: PAPADIMITRIOU Dimitri > > > > > Cc: Lou Berger; Don Fedyk; BRUNGARD, DEBORAH A, ATTLABS; > > > > > ccamp@ops.ietf.org > > > > > Subject: RE: Proposed WG Draft -=20 > > draft-gmpls-ethernet-arch-00.txt > > > > > > > > > > I have no objection to adding "Updates: 3945" to the=20 > > > document header > > > > > and matching 3945's category. > > > > > > > > > > Lou > > > > > > > > > > At 05:11 PM 1/22/2008, PAPADIMITRIOU Dimitri wrote: > > > > > >Lou > > > > > > > > > > > >what i am concerned with: is that the doc extends > > > > > applicability of GMPLS > > > > > >to Ethernet by excluding GMPLS for Ethernet per RFC 3945=20 > > > ? does that > > > > > >make sense ? > > > > > > > > > > > >what's needed instead of hiding behind terms is to state=20 > > > GMPLS for Y, > > > > > >where Y includes the set of Ethernet-based techno's under > > > > > development at > > > > > >places as indicated in the doc itself. instead of=20 > > > inducing by a title > > > > > >such as "GMPLS for Ethernet" that this doc supersedes any > > > > > previous work > > > > > >in that > > > > > >space. > > > > > > > > > > > >-d. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: owner-ccamp@ops.ietf.org > > > > > > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Lou Berger > > > > > > > Sent: Tuesday, January 22, 2008 10:50 PM > > > > > > > To: Don Fedyk > > > > > > > Cc: PAPADIMITRIOU Dimitri; BRUNGARD, DEBORAH A, ATTLABS; > > > > > > > ccamp@ops.ietf.org > > > > > > > Subject: RE: Proposed WG Draft -=20 > > > draft-gmpls-ethernet-arch-00.txt > > > > > > > > > > > > > > Don, > > > > > > > I agree 100%. Furthermore there is no=20 > > > statement in the > > > > > > > draft that 3945 doesn't apply, in fact it explicitly=20 > > > says just the > > > > > > > opposite. The reason for the statement in question is > > > > > simply as you > > > > > > > say, and to ensure full ETH-LSP definition and=20 > interoperable > > > > > > > operation a new switching type/capability is required. > > > > > > > > > > > > > > It's really not such a bid deal or major change. > > > > > > > > > > > > > > Lou > > > > > > > > > > > > > > At 04:34 PM 1/22/2008, Don Fedyk wrote: > > > > > > > >Hi Dimitri > > > > > > > > > > > > > > > >The text you quote was put in the architecture/=20 > > > framework, not to > > > > > > > >exclude L2 Switch Capable (L2SC) but to prevent=20 > redefining > > > > > > > L2SC, which > > > > > > > >has been there for many years and may be in use. > > > > > > > > > > > > > > > >Perhaps the working needs to be adjusted but I=20 > don't think > > > > > > > it is a major > > > > > > > >issue. > > > > > > > > > > > > > > > >Regards, > > > > > > > >Don > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: owner-ccamp@ops.ietf.org > > > > > > > > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of > > > > > > > PAPADIMITRIOU Dimitri > > > > > > > > > Sent: Tuesday, January 22, 2008 4:16 PM > > > > > > > > > To: BRUNGARD, DEBORAH A, ATTLABS; ccamp@ops.ietf.org > > > > > > > > > Subject: RE: Proposed WG Draft - > > > > > draft-gmpls-ethernet-arch-00.txt > > > > > > > > > > > > > > > > > > All, > > > > > > > > > > > > > > > > > > > We received a couple of comments in the=20 > > > meeting, we would > > > > > > > > > > appreciate additional feedback on the list. > > > > > > > > > > > > > > > > > > The document states: > > > > > > > > > > > > > > > > > > "The L2SC Interface Switching Capabilities MUST=20 > > > NOT be used > > > > > > > > > to represent > > > > > > > > > interfaces capable of supporting Eth-LSPs.=20 > > > Interface Switching > > > > > > > > > Capability specific TE information may be defined as > > > > > > > needed to support > > > > > > > > > the requirements of a specific Ethernet Switching > > > > > Service Type." > > > > > > > > > > > > > > > > > > [...] > > > > > > > > > > > > > > > > > > "It is expected that there will be no case where an > > > > > > > Eth-LSP will be > > > > > > > > > signaled, or an Eth-LSP supporting interface will be > > > > > > > > > represented, using > > > > > > > > > the L2SC switching type/capability. A new switching > > > > > > > type/capability is > > > > > > > > > required to avoid any potential current usage=20 > > of the L2SC > > > > > > > switching > > > > > > > > > type/capability in support of Ethernet." > > > > > > > > > > > > > > > > > > This is explicit statement that GMPLS per RFC=20 > > 3945 is not > > > > > > > applicable. > > > > > > > > > So, it is much more than just an additional=20 > > codepoint, as > > > > > > > the control > > > > > > > > > plane behaviour is to be defined for this=20 > > > codepoint. So, it > > > > > > > > > is the open > > > > > > > > > door for a new control plane behaviour. > > > > > > > > > > > > > > > > > > so, let's have a more basic questioning before jumping > > > > > > > into the single > > > > > > > > > alternative resulting from this doc.: > > > > > > > > > > > > > > > > > > - either it is GMPLS for Ethernet=20 > architecture and then > > > > > > > what exist in > > > > > > > > > current RFCs should be applicable (because i=20 > do not see > > > > > > > any rationale > > > > > > > > > for L2SC def. departure for Ethernet frame=20 > processing); > > > > > > > > > > > > > > > > > > - or not it is X for Y architecture, where X is an IP > > > > > > > control protocol > > > > > > > > > based some potentially on some existing GMPLS blocks > > > > > and Y is not > > > > > > > > > compatible with the existing definition of Eth frame > > > > > processing. > > > > > > > > > > > > > > > > > > In the latter case, i do not know how this WG can deal > > > > > > > with such case > > > > > > > > > (from the control plane perspective). > > > > > > > > > > > > > > > > > > -d. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: owner-ccamp@ops.ietf.org > > > > > > > > > > [mailto:owner-ccamp@ops.ietf.org] On Behalf=20 > > Of BRUNGARD, > > > > > > > > > > DEBORAH A, ATTLABS > > > > > > > > > > Sent: Tuesday, January 22, 2008 8:28 PM > > > > > > > > > > To: ccamp@ops.ietf.org > > > > > > > > > > Subject: Proposed WG Draft - > > > > > draft-gmpls-ethernet-arch-00.txt > > > > > > > > > > > > > > > > > > > > CCAMP, > > > > > > > > > > > > > > > > > > > > The DT proposed in their meeting presentation=20 > > for their > > > > > > > > > > architecture and framework document to be=20 > > accepted as a > > > > > > > WG draft: > > > > > > > > > > > > > > > > > > > > > >=20 > > >=20 > http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt > > > > > > > > > > > > > > > > > > > > We received a couple of comments in the=20 > > > meeting, we would > > > > > > > > > > appreciate additional feedback on the list.=20 > > > Please express > > > > > > > > > > your support (or otherwise) for this I-D to become > > > > > a WG draft. > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > Deborah > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=20 > > >=20 > > >=20 > >=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 24 Jan 2008 02:53:10 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Date: Wed, 23 Jan 2008 21:51:11 -0500 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA41349EF98@zrtphxm2.corp.nortel.com> Thread-Topic: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Thread-Index: AchdVFu8AEzlezFGRoK1wWa//yCoRwAwWYeAAAbEl1A= From: "Don Fedyk" To: "PAPADIMITRIOU Dimitri" , "Lou Berger" Cc: "BRUNGARD, DEBORAH A, ATTLABS" , Hi Dimitri The document clearly states: "The intent of this document is to reuse and align with as much of the GMPLS protocols as possible. For example reusing the IP control plane addressing allows the existing signaling, routing, LMP and path computation to be used as specified. Additions are made only to accommodate features of Ethernet that are not already supported by GMPLS. The GMPLS protocols support a set of tools for hierarchical LSPs as well as contiguous LSPs. GMPLS specific protocol mechanisms support a variety of networks from peer to peer to UNIs and NNIs." So your question comes down to why we make the statement on L2SC? Like Lou said when we discussed this we thought that L2SC came with baggage and was not precise. The switching capabilities would be specified in documents that address the particular Ethernet data plane. It is true that if there was a valid Ethernet data plane that could use L2SC unambiguously it should fit under the architecture. At any rate getting this right is something that can be accomplished when this is a WG draft.=20 Regards, Don=20 > -----Original Message----- > From: PAPADIMITRIOU Dimitri=20 > [mailto:Dimitri.Papadimitriou@alcatel-lucent.be]=20 > Sent: Wednesday, January 23, 2008 7:05 PM > To: Lou Berger > Cc: Fedyk, Don (BL60:1A00); BRUNGARD, DEBORAH A, ATTLABS;=20 > ccamp@ops.ietf.org > Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt >=20 > the question triggered by this poll is the following: if GMPLS for > Ethernet is not inline with the existing stacks what is the value of > GMPLS re-use ? what's the value to borrow the term GMPLS without its > substance ? and in practice, the issue is, if it is not GMPLS per RFC > 3945, what's the value compared to any other native control stack that > would be developed at IEEE for inst. for these techno's. >=20 > you quote: >=20 > > L2SC was always underspecified (e.g., covers both ATM and Ether), >=20 > additional specification does not result in departing from the initial > definition but refinement of the initial definition (definition of a > sub-set not a side definition). >=20 > probably the document is not mature enough to respond to the > tie-breaker: what about the FIT of GMPLS for Ethernet but not=20 > within the > L2SC space (as defined today) ? but in the meantime preclude=20 > any allowed > use of GMPLS per IETF RFCs to Ethernet if they do not comply=20 > with a new > WG i-d would create a precedent in the history of this WG with really > disastrous impact (including on other application of GMPLS) >=20 > we're at a turning point (equivalent to RSVP vs RSVP-TE). we need to > assess consequences before going one way or another and under which > conditions. >=20 > -d. >=20 > > -----Original Message----- > > From: owner-ccamp@ops.ietf.org=20 > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Lou Berger > > Sent: Wednesday, January 23, 2008 1:09 AM > > To: PAPADIMITRIOU Dimitri > > Cc: Lou Berger; Don Fedyk; BRUNGARD, DEBORAH A, ATTLABS;=20 > > ccamp@ops.ietf.org > > Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt > >=20 > > We've always had different switching type/capability in=20 > > GMPLS. Nothing new here. > >=20 > > L2SC was always underspecified (e.g., covers both ATM and=20 > Ether), is=20 > > currently used by some for different purposes, and doesn't allow=20 > > unique identification of switching capabilities of an interface. I=20 > > *really* don't see the unique identification of an interface's=20 > > Ethernet switching function as any different from what is done for=20 > > today for the other types or as any big deal or change in GMPLS=20 > > direction or architecture. > >=20 > > but, that's just my perspective. > >=20 > > Lou > >=20 > > At 05:44 PM 1/22/2008, PAPADIMITRIOU Dimitri wrote: > > >thus the question is whether or not to ask for a change=20 > CCAMP "common > > >control" in DCAMP "differentiated control" per technology ? > > > > > >we never have had a techno inducing a base building block=20 > > change (GMPLS > > >being a generalisation of MPLS-TE). i'm afraid that=20 > generalized LSP, > > >generalized LSR, generalized label, etc. per GMPLS arch (RFC=20 > > 3945) would > > >simply be unapplicable as known today and thus the corr.=20 > > base protocol > > >specs unapplicable. at the end the term "GMPLS" would be=20 > > emptied of any > > >real substance. > > > > > >it's a choice but let's ask the questions from the right=20 > perspective. > > > > > >-d. > > > > > > > -----Original Message----- > > > > From: Lou Berger [mailto:lberger@labn.net] > > > > Sent: Tuesday, January 22, 2008 11:28 PM > > > > To: PAPADIMITRIOU Dimitri > > > > Cc: Lou Berger; Don Fedyk; BRUNGARD, DEBORAH A, ATTLABS; > > > > ccamp@ops.ietf.org > > > > Subject: RE: Proposed WG Draft -=20 > draft-gmpls-ethernet-arch-00.txt > > > > > > > > I have no objection to adding "Updates: 3945" to the=20 > > document header > > > > and matching 3945's category. > > > > > > > > Lou > > > > > > > > At 05:11 PM 1/22/2008, PAPADIMITRIOU Dimitri wrote: > > > > >Lou > > > > > > > > > >what i am concerned with: is that the doc extends > > > > applicability of GMPLS > > > > >to Ethernet by excluding GMPLS for Ethernet per RFC 3945=20 > > ? does that > > > > >make sense ? > > > > > > > > > >what's needed instead of hiding behind terms is to state=20 > > GMPLS for Y, > > > > >where Y includes the set of Ethernet-based techno's under > > > > development at > > > > >places as indicated in the doc itself. instead of=20 > > inducing by a title > > > > >such as "GMPLS for Ethernet" that this doc supersedes any > > > > previous work > > > > >in that > > > > >space. > > > > > > > > > >-d. > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: owner-ccamp@ops.ietf.org > > > > > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Lou Berger > > > > > > Sent: Tuesday, January 22, 2008 10:50 PM > > > > > > To: Don Fedyk > > > > > > Cc: PAPADIMITRIOU Dimitri; BRUNGARD, DEBORAH A, ATTLABS; > > > > > > ccamp@ops.ietf.org > > > > > > Subject: RE: Proposed WG Draft -=20 > > draft-gmpls-ethernet-arch-00.txt > > > > > > > > > > > > Don, > > > > > > I agree 100%. Furthermore there is no=20 > > statement in the > > > > > > draft that 3945 doesn't apply, in fact it explicitly=20 > > says just the > > > > > > opposite. The reason for the statement in question is > > > > simply as you > > > > > > say, and to ensure full ETH-LSP definition and interoperable > > > > > > operation a new switching type/capability is required. > > > > > > > > > > > > It's really not such a bid deal or major change. > > > > > > > > > > > > Lou > > > > > > > > > > > > At 04:34 PM 1/22/2008, Don Fedyk wrote: > > > > > > >Hi Dimitri > > > > > > > > > > > > > >The text you quote was put in the architecture/=20 > > framework, not to > > > > > > >exclude L2 Switch Capable (L2SC) but to prevent redefining > > > > > > L2SC, which > > > > > > >has been there for many years and may be in use. > > > > > > > > > > > > > >Perhaps the working needs to be adjusted but I don't think > > > > > > it is a major > > > > > > >issue. > > > > > > > > > > > > > >Regards, > > > > > > >Don > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: owner-ccamp@ops.ietf.org > > > > > > > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of > > > > > > PAPADIMITRIOU Dimitri > > > > > > > > Sent: Tuesday, January 22, 2008 4:16 PM > > > > > > > > To: BRUNGARD, DEBORAH A, ATTLABS; ccamp@ops.ietf.org > > > > > > > > Subject: RE: Proposed WG Draft - > > > > draft-gmpls-ethernet-arch-00.txt > > > > > > > > > > > > > > > > All, > > > > > > > > > > > > > > > > > We received a couple of comments in the=20 > > meeting, we would > > > > > > > > > appreciate additional feedback on the list. > > > > > > > > > > > > > > > > The document states: > > > > > > > > > > > > > > > > "The L2SC Interface Switching Capabilities MUST=20 > > NOT be used > > > > > > > > to represent > > > > > > > > interfaces capable of supporting Eth-LSPs.=20 > > Interface Switching > > > > > > > > Capability specific TE information may be defined as > > > > > > needed to support > > > > > > > > the requirements of a specific Ethernet Switching > > > > Service Type." > > > > > > > > > > > > > > > > [...] > > > > > > > > > > > > > > > > "It is expected that there will be no case where an > > > > > > Eth-LSP will be > > > > > > > > signaled, or an Eth-LSP supporting interface will be > > > > > > > > represented, using > > > > > > > > the L2SC switching type/capability. A new switching > > > > > > type/capability is > > > > > > > > required to avoid any potential current usage=20 > of the L2SC > > > > > > switching > > > > > > > > type/capability in support of Ethernet." > > > > > > > > > > > > > > > > This is explicit statement that GMPLS per RFC=20 > 3945 is not > > > > > > applicable. > > > > > > > > So, it is much more than just an additional=20 > codepoint, as > > > > > > the control > > > > > > > > plane behaviour is to be defined for this=20 > > codepoint. So, it > > > > > > > > is the open > > > > > > > > door for a new control plane behaviour. > > > > > > > > > > > > > > > > so, let's have a more basic questioning before jumping > > > > > > into the single > > > > > > > > alternative resulting from this doc.: > > > > > > > > > > > > > > > > - either it is GMPLS for Ethernet architecture and then > > > > > > what exist in > > > > > > > > current RFCs should be applicable (because i do not see > > > > > > any rationale > > > > > > > > for L2SC def. departure for Ethernet frame processing); > > > > > > > > > > > > > > > > - or not it is X for Y architecture, where X is an IP > > > > > > control protocol > > > > > > > > based some potentially on some existing GMPLS blocks > > > > and Y is not > > > > > > > > compatible with the existing definition of Eth frame > > > > processing. > > > > > > > > > > > > > > > > In the latter case, i do not know how this WG can deal > > > > > > with such case > > > > > > > > (from the control plane perspective). > > > > > > > > > > > > > > > > -d. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: owner-ccamp@ops.ietf.org > > > > > > > > > [mailto:owner-ccamp@ops.ietf.org] On Behalf=20 > Of BRUNGARD, > > > > > > > > > DEBORAH A, ATTLABS > > > > > > > > > Sent: Tuesday, January 22, 2008 8:28 PM > > > > > > > > > To: ccamp@ops.ietf.org > > > > > > > > > Subject: Proposed WG Draft - > > > > draft-gmpls-ethernet-arch-00.txt > > > > > > > > > > > > > > > > > > CCAMP, > > > > > > > > > > > > > > > > > > The DT proposed in their meeting presentation=20 > for their > > > > > > > > > architecture and framework document to be=20 > accepted as a > > > > > > WG draft: > > > > > > > > > > > > > > > > > > >=20 > > http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt > > > > > > > > > > > > > > > > > > We received a couple of comments in the=20 > > meeting, we would > > > > > > > > > appreciate additional feedback on the list.=20 > > Please express > > > > > > > > > your support (or otherwise) for this I-D to become > > > > a WG draft. > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > Deborah > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=20 > >=20 > >=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 24 Jan 2008 00:06:31 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Date: Thu, 24 Jan 2008 01:04:33 +0100 Message-ID: Thread-Topic: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Thread-Index: AchdVFu8AEzlezFGRoK1wWa//yCoRwAwWYeA From: "PAPADIMITRIOU Dimitri" To: "Lou Berger" Cc: "Don Fedyk" , "BRUNGARD, DEBORAH A, ATTLABS" , the question triggered by this poll is the following: if GMPLS for Ethernet is not inline with the existing stacks what is the value of GMPLS re-use ? what's the value to borrow the term GMPLS without its substance ? and in practice, the issue is, if it is not GMPLS per RFC 3945, what's the value compared to any other native control stack that would be developed at IEEE for inst. for these techno's. you quote: > L2SC was always underspecified (e.g., covers both ATM and Ether), additional specification does not result in departing from the initial definition but refinement of the initial definition (definition of a sub-set not a side definition). probably the document is not mature enough to respond to the tie-breaker: what about the FIT of GMPLS for Ethernet but not within the L2SC space (as defined today) ? but in the meantime preclude any allowed use of GMPLS per IETF RFCs to Ethernet if they do not comply with a new WG i-d would create a precedent in the history of this WG with really disastrous impact (including on other application of GMPLS) we're at a turning point (equivalent to RSVP vs RSVP-TE). we need to assess consequences before going one way or another and under which conditions. -d. > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Lou Berger > Sent: Wednesday, January 23, 2008 1:09 AM > To: PAPADIMITRIOU Dimitri > Cc: Lou Berger; Don Fedyk; BRUNGARD, DEBORAH A, ATTLABS;=20 > ccamp@ops.ietf.org > Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt >=20 > We've always had different switching type/capability in=20 > GMPLS. Nothing new here. >=20 > L2SC was always underspecified (e.g., covers both ATM and Ether), is=20 > currently used by some for different purposes, and doesn't allow=20 > unique identification of switching capabilities of an interface. I=20 > *really* don't see the unique identification of an interface's=20 > Ethernet switching function as any different from what is done for=20 > today for the other types or as any big deal or change in GMPLS=20 > direction or architecture. >=20 > but, that's just my perspective. >=20 > Lou >=20 > At 05:44 PM 1/22/2008, PAPADIMITRIOU Dimitri wrote: > >thus the question is whether or not to ask for a change CCAMP "common > >control" in DCAMP "differentiated control" per technology ? > > > >we never have had a techno inducing a base building block=20 > change (GMPLS > >being a generalisation of MPLS-TE). i'm afraid that generalized LSP, > >generalized LSR, generalized label, etc. per GMPLS arch (RFC=20 > 3945) would > >simply be unapplicable as known today and thus the corr.=20 > base protocol > >specs unapplicable. at the end the term "GMPLS" would be=20 > emptied of any > >real substance. > > > >it's a choice but let's ask the questions from the right perspective. > > > >-d. > > > > > -----Original Message----- > > > From: Lou Berger [mailto:lberger@labn.net] > > > Sent: Tuesday, January 22, 2008 11:28 PM > > > To: PAPADIMITRIOU Dimitri > > > Cc: Lou Berger; Don Fedyk; BRUNGARD, DEBORAH A, ATTLABS; > > > ccamp@ops.ietf.org > > > Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt > > > > > > I have no objection to adding "Updates: 3945" to the=20 > document header > > > and matching 3945's category. > > > > > > Lou > > > > > > At 05:11 PM 1/22/2008, PAPADIMITRIOU Dimitri wrote: > > > >Lou > > > > > > > >what i am concerned with: is that the doc extends > > > applicability of GMPLS > > > >to Ethernet by excluding GMPLS for Ethernet per RFC 3945=20 > ? does that > > > >make sense ? > > > > > > > >what's needed instead of hiding behind terms is to state=20 > GMPLS for Y, > > > >where Y includes the set of Ethernet-based techno's under > > > development at > > > >places as indicated in the doc itself. instead of=20 > inducing by a title > > > >such as "GMPLS for Ethernet" that this doc supersedes any > > > previous work > > > >in that > > > >space. > > > > > > > >-d. > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: owner-ccamp@ops.ietf.org > > > > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Lou Berger > > > > > Sent: Tuesday, January 22, 2008 10:50 PM > > > > > To: Don Fedyk > > > > > Cc: PAPADIMITRIOU Dimitri; BRUNGARD, DEBORAH A, ATTLABS; > > > > > ccamp@ops.ietf.org > > > > > Subject: RE: Proposed WG Draft -=20 > draft-gmpls-ethernet-arch-00.txt > > > > > > > > > > Don, > > > > > I agree 100%. Furthermore there is no=20 > statement in the > > > > > draft that 3945 doesn't apply, in fact it explicitly=20 > says just the > > > > > opposite. The reason for the statement in question is > > > simply as you > > > > > say, and to ensure full ETH-LSP definition and interoperable > > > > > operation a new switching type/capability is required. > > > > > > > > > > It's really not such a bid deal or major change. > > > > > > > > > > Lou > > > > > > > > > > At 04:34 PM 1/22/2008, Don Fedyk wrote: > > > > > >Hi Dimitri > > > > > > > > > > > >The text you quote was put in the architecture/=20 > framework, not to > > > > > >exclude L2 Switch Capable (L2SC) but to prevent redefining > > > > > L2SC, which > > > > > >has been there for many years and may be in use. > > > > > > > > > > > >Perhaps the working needs to be adjusted but I don't think > > > > > it is a major > > > > > >issue. > > > > > > > > > > > >Regards, > > > > > >Don > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: owner-ccamp@ops.ietf.org > > > > > > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of > > > > > PAPADIMITRIOU Dimitri > > > > > > > Sent: Tuesday, January 22, 2008 4:16 PM > > > > > > > To: BRUNGARD, DEBORAH A, ATTLABS; ccamp@ops.ietf.org > > > > > > > Subject: RE: Proposed WG Draft - > > > draft-gmpls-ethernet-arch-00.txt > > > > > > > > > > > > > > All, > > > > > > > > > > > > > > > We received a couple of comments in the=20 > meeting, we would > > > > > > > > appreciate additional feedback on the list. > > > > > > > > > > > > > > The document states: > > > > > > > > > > > > > > "The L2SC Interface Switching Capabilities MUST=20 > NOT be used > > > > > > > to represent > > > > > > > interfaces capable of supporting Eth-LSPs.=20 > Interface Switching > > > > > > > Capability specific TE information may be defined as > > > > > needed to support > > > > > > > the requirements of a specific Ethernet Switching > > > Service Type." > > > > > > > > > > > > > > [...] > > > > > > > > > > > > > > "It is expected that there will be no case where an > > > > > Eth-LSP will be > > > > > > > signaled, or an Eth-LSP supporting interface will be > > > > > > > represented, using > > > > > > > the L2SC switching type/capability. A new switching > > > > > type/capability is > > > > > > > required to avoid any potential current usage of the L2SC > > > > > switching > > > > > > > type/capability in support of Ethernet." > > > > > > > > > > > > > > This is explicit statement that GMPLS per RFC 3945 is not > > > > > applicable. > > > > > > > So, it is much more than just an additional codepoint, as > > > > > the control > > > > > > > plane behaviour is to be defined for this=20 > codepoint. So, it > > > > > > > is the open > > > > > > > door for a new control plane behaviour. > > > > > > > > > > > > > > so, let's have a more basic questioning before jumping > > > > > into the single > > > > > > > alternative resulting from this doc.: > > > > > > > > > > > > > > - either it is GMPLS for Ethernet architecture and then > > > > > what exist in > > > > > > > current RFCs should be applicable (because i do not see > > > > > any rationale > > > > > > > for L2SC def. departure for Ethernet frame processing); > > > > > > > > > > > > > > - or not it is X for Y architecture, where X is an IP > > > > > control protocol > > > > > > > based some potentially on some existing GMPLS blocks > > > and Y is not > > > > > > > compatible with the existing definition of Eth frame > > > processing. > > > > > > > > > > > > > > In the latter case, i do not know how this WG can deal > > > > > with such case > > > > > > > (from the control plane perspective). > > > > > > > > > > > > > > -d. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: owner-ccamp@ops.ietf.org > > > > > > > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of BRUNGARD, > > > > > > > > DEBORAH A, ATTLABS > > > > > > > > Sent: Tuesday, January 22, 2008 8:28 PM > > > > > > > > To: ccamp@ops.ietf.org > > > > > > > > Subject: Proposed WG Draft - > > > draft-gmpls-ethernet-arch-00.txt > > > > > > > > > > > > > > > > CCAMP, > > > > > > > > > > > > > > > > The DT proposed in their meeting presentation for their > > > > > > > > architecture and framework document to be accepted as a > > > > > WG draft: > > > > > > > > > > > > > > > >=20 > http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt > > > > > > > > > > > > > > > > We received a couple of comments in the=20 > meeting, we would > > > > > > > > appreciate additional feedback on the list.=20 > Please express > > > > > > > > your support (or otherwise) for this I-D to become > > > a WG draft. > > > > > > > > > > > > > > > > Thanks, > > > > > > > > Deborah > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=20 >=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 23 Jan 2008 22:34:04 +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=PTGHQT6s3V1WCcbXKgzjSYtuFzyzr4o+ZxIxHrpl3vs=; b=P75sE66oG7b1VgW6y2Ff24uVo2glYfuxWdAru3x1HEUnugjBxiRgWFWMpz3SjPupEK6yP+0YF0IK/K0mnWzf2i6u7PJFFk/tKSkGehP9MCpIJRjLyFpC85aB5TcmZaaDEuAnbKmIMXoADL1eOGYm2N5+CYHHJd+XQmRSB8hA62k= 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=AQhT6pzQPBFJH7sYU1yHgGVdbKkYWDxv/w0AO43AXb1xTYKA1A0mcAgXf3jMUY8reSv3IurZRhA7JrPATi39sk362+jvXpka/vdciXKKop1Mr74TocMW1MPGQHRR75QBjIowWrG/KWQ1HYKM6DG5qlC0vKZU8X5gb3XbRajj0I8= Message-ID: <8c99930d0801231431h6c573bf6x63fa7cca3a4333ea@mail.gmail.com> Date: Wed, 23 Jan 2008 17:31:10 -0500 From: "Andrew G. Malis" To: ccamp@ops.ietf.org Subject: Re: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Cc: "BRUNGARD, DEBORAH A, ATTLABS" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Also in favor. Cheers, Andy > BRUNGARD, DEBORAH A, ATTLABS wrote: > CCAMP, > > The DT proposed in their meeting presentation for their architecture and > framework document to be accepted as a WG draft: > http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt > > We received a couple of comments in the meeting, we would appreciate > additional feedback on the list. Please express your support (or otherwise) > for this I-D to become a WG draft. > > Thanks, > Deborah Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 23 Jan 2008 15:13:50 +0000 Message-ID: <47975978.60508@grotto-networking.com> Date: Wed, 23 Jan 2008 07:12:56 -0800 From: Greg Bernstein User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "BRUNGARD, DEBORAH A, ATTLABS" CC: ccamp@ops.ietf.org Subject: Re: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Content-Type: multipart/alternative; boundary="------------020605090909000502090101" This is a multi-part message in MIME format. --------------020605090909000502090101 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit In favor. Regards Greg B. BRUNGARD, DEBORAH A, ATTLABS wrote: > CCAMP, > > The DT proposed in their meeting presentation for their architecture > and framework document to be accepted as a WG draft: > http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt > > We received a couple of comments in the meeting, we would appreciate > additional feedback on the list. Please express your support (or > otherwise) for this I-D to become a WG draft. > > Thanks, > Deborah -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 --------------020605090909000502090101 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit In favor.
Regards

Greg B.

BRUNGARD, DEBORAH A, ATTLABS wrote:
CCAMP,
 
The DT proposed in their meeting presentation for their architecture and framework document to be accepted as a WG draft:
 
We received a couple of comments in the meeting, we would appreciate additional feedback on the list. Please express your support (or otherwise) for this I-D to become a WG draft.
 
Thanks,
Deborah

-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237
--------------020605090909000502090101-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 23 Jan 2008 14:49:16 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C85DCE.E3F56E52" Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Date: Wed, 23 Jan 2008 09:47:48 -0500 Message-ID: <085091CB2CA14E4B8B163FFC37C84E9D1355B715@zcarhxm0.corp.nortel.com> Thread-Topic: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Thread-Index: AchdLOH3JrqySZgzQVuueGk7Nk+CoAAogWTA From: "Hamid Ould-Brahim" To: "BRUNGARD, DEBORAH A, ATTLABS" , This is a multi-part message in MIME format. ------_=_NextPart_001_01C85DCE.E3F56E52 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In favor. =20 Hamid. ________________________________ From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of BRUNGARD, DEBORAH A, ATTLABS Sent: Tuesday, January 22, 2008 2:28 PM To: ccamp@ops.ietf.org Subject: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt =09 =09 CCAMP, =20 The DT proposed in their meeting presentation for their architecture and framework document to be accepted as a WG draft: =09 http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt =20 We received a couple of comments in the meeting, we would appreciate additional feedback on the list. Please express your support (or otherwise) for this I-D to become a WG draft. =20 Thanks, Deborah ------_=_NextPart_001_01C85DCE.E3F56E52 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
In favor.
 
Hamid.

From: owner-ccamp@ops.ietf.org=20 [mailto:owner-ccamp@ops.ietf.org] On Behalf Of BRUNGARD, = DEBORAH A,=20 ATTLABS
Sent: Tuesday, January 22, 2008 2:28 = PM
To:=20 ccamp@ops.ietf.org
Subject: Proposed WG Draft -=20 draft-gmpls-ethernet-arch-00.txt

CCAMP,
 
The = DT proposed in=20 their meeting presentation for their architecture and framework=20 document to be accepted as a WG = draft:
http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt=
 
We = received a=20 couple of comments in the meeting, we would appreciate additional = feedback on the list. Please express your support (or otherwise) = for this=20 I-D to become a WG draft.
 
Thanks,
Deborah
------_=_NextPart_001_01C85DCE.E3F56E52-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 23 Jan 2008 13:31:30 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C85DC4.129C2CE7" Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Date: Wed, 23 Jan 2008 07:30:08 -0600 Message-ID: <8ECB099B6E0A044695BD93961F3498820682D379@eusrcmw720.eamcs.ericsson.se> Thread-Topic: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Thread-Index: AchdLOH3JrqySZgzQVuueGk7Nk+CoAAlyQFg From: "David Sinicrope" To: "BRUNGARD, DEBORAH A, ATTLABS" , This is a multi-part message in MIME format. ------_=_NextPart_001_01C85DC4.129C2CE7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support for WG draft. ________________________________ From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of BRUNGARD, DEBORAH A, ATTLABS Sent: Tuesday, January 22, 2008 2:28 PM To: ccamp@ops.ietf.org Subject: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt CCAMP, =20 The DT proposed in their meeting presentation for their architecture and framework document to be accepted as a WG draft: http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt =20 We received a couple of comments in the meeting, we would appreciate additional feedback on the list. Please express your support (or otherwise) for this I-D to become a WG draft. =20 Thanks, Deborah ------_=_NextPart_001_01C85DC4.129C2CE7 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Support for WG draft.

From: owner-ccamp@ops.ietf.org=20 [mailto:owner-ccamp@ops.ietf.org] On Behalf Of BRUNGARD, DEBORAH = A,=20 ATTLABS
Sent: Tuesday, January 22, 2008 2:28 PM
To:=20 ccamp@ops.ietf.org
Subject: Proposed WG Draft -=20 draft-gmpls-ethernet-arch-00.txt

CCAMP,
 
The DT = proposed in=20 their meeting presentation for their architecture and framework=20 document to be accepted as a WG = draft:
http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt=
 
We = received a couple=20 of comments in the meeting, we would appreciate additional = feedback on=20 the list. Please express your support (or otherwise) for this I-D to = become a WG=20 draft.
 
Thanks,
Deborah
------_=_NextPart_001_01C85DC4.129C2CE7-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 23 Jan 2008 12:38:27 +0000 Message-Id: <479742C4.6F67.00AA.0@acreo.se> Date: Wed, 23 Jan 2008 13:36:05 +0100 From: "Anders Gavler" To: "DEBORAH A ATTLABS BRUNGARD" , Subject: Re: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=__Part290FF4A5.1__=" This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part290FF4A5.1__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline In favor of this! Anders Gavler Acreo AB Electrum 236 SE - 164 40 Kista Phone: +46 8 632 77 29 Homepage: http://www.acreo.se >>> "BRUNGARD, DEBORAH A, ATTLABS" 2008-01-22 20:27 >>> CCAMP, The DT proposed in their meeting presentation for their architecture and framework document to be accepted as a WG draft: http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt We received a couple of comments in the meeting, we would appreciate additional feedback on the list. Please express your support (or otherwise) for this I-D to become a WG draft. Thanks, Deborah --=__Part290FF4A5.1__= Content-Type: text/plain; name="Anders Gavler1.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Anders Gavler1.vcf" BEGIN:VCARD VERSION:2.1 X-GWTYPE:USER FN:Anders Gavler TEL;WORK:08-6327729 EMAIL;WORK;PREF;NGW:Anders.Gavler@acreo.se N:Gavler;Anders END:VCARD BEGIN:VCARD VERSION:2.1 X-GWTYPE:USER FN:Anders Gavler TEL;WORK:08-6327729 EMAIL;WORK;PREF;NGW:Anders.Gavler@acreo.se N:Gavler;Anders END:VCARD BEGIN:VCARD VERSION:2.1 X-GWTYPE:USER FN:Anders Gavler TEL;WORK:08-6327729 EMAIL;WORK;PREF;NGW:Anders.Gavler@acreo.se N:Gavler;Anders END:VCARD BEGIN:VCARD VERSION:2.1 X-GWTYPE:USER FN:Anders Gavler TEL;WORK:08-6327729 EMAIL;WORK;PREF;NGW:Anders.Gavler@acreo.se N:Gavler;Anders END:VCARD --=__Part290FF4A5.1__=-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 23 Jan 2008 09:55:21 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C85DA5.B712FDC4" Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Date: Wed, 23 Jan 2008 10:52:50 +0100 Message-ID: <53CCFDD6E346CB43994852666C210E91026246AE@esealmw116.eemea.ericsson.se> Thread-Topic: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Thread-Index: AchdLOH3JrqySZgzQVuueGk7Nk+CoAAeLaiw From: "Attila Takacs" To: "BRUNGARD, DEBORAH A, ATTLABS" , This is a multi-part message in MIME format. ------_=_NextPart_001_01C85DA5.B712FDC4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In favor. Attila ________________________________ From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of BRUNGARD, DEBORAH A, ATTLABS Sent: Tuesday, January 22, 2008 8:28 PM To: ccamp@ops.ietf.org Subject: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt =09 =09 CCAMP, =20 The DT proposed in their meeting presentation for their architecture and framework document to be accepted as a WG draft: =09 http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt =20 We received a couple of comments in the meeting, we would appreciate additional feedback on the list. Please express your support (or otherwise) for this I-D to become a WG draft. =20 Thanks, Deborah ------_=_NextPart_001_01C85DA5.B712FDC4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
In=20 favor.
Attila

From: owner-ccamp@ops.ietf.org=20 [mailto:owner-ccamp@ops.ietf.org] On Behalf Of BRUNGARD, = DEBORAH A,=20 ATTLABS
Sent: Tuesday, January 22, 2008 8:28 = PM
To:=20 ccamp@ops.ietf.org
Subject: Proposed WG Draft -=20 draft-gmpls-ethernet-arch-00.txt

CCAMP,
 
The = DT proposed in=20 their meeting presentation for their architecture and framework=20 document to be accepted as a WG = draft:
http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt=
 
We = received a=20 couple of comments in the meeting, we would appreciate additional = feedback on the list. Please express your support (or otherwise) = for this=20 I-D to become a WG draft.
 
Thanks,
Deborah
------_=_NextPart_001_01C85DA5.B712FDC4-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 23 Jan 2008 00:10:16 +0000 Date: Tue, 22 Jan 2008 19:08:41 -0500 To: "PAPADIMITRIOU Dimitri" From: Lou Berger Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Cc: "Lou Berger" ,"Don Fedyk" , "BRUNGARD, DEBORAH A, ATTLABS" , Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-Id: We've always had different switching type/capability in GMPLS. Nothing new here. L2SC was always underspecified (e.g., covers both ATM and Ether), is currently used by some for different purposes, and doesn't allow unique identification of switching capabilities of an interface. I *really* don't see the unique identification of an interface's Ethernet switching function as any different from what is done for today for the other types or as any big deal or change in GMPLS direction or architecture. but, that's just my perspective. Lou At 05:44 PM 1/22/2008, PAPADIMITRIOU Dimitri wrote: >thus the question is whether or not to ask for a change CCAMP "common >control" in DCAMP "differentiated control" per technology ? > >we never have had a techno inducing a base building block change (GMPLS >being a generalisation of MPLS-TE). i'm afraid that generalized LSP, >generalized LSR, generalized label, etc. per GMPLS arch (RFC 3945) would >simply be unapplicable as known today and thus the corr. base protocol >specs unapplicable. at the end the term "GMPLS" would be emptied of any >real substance. > >it's a choice but let's ask the questions from the right perspective. > >-d. > > > -----Original Message----- > > From: Lou Berger [mailto:lberger@labn.net] > > Sent: Tuesday, January 22, 2008 11:28 PM > > To: PAPADIMITRIOU Dimitri > > Cc: Lou Berger; Don Fedyk; BRUNGARD, DEBORAH A, ATTLABS; > > ccamp@ops.ietf.org > > Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt > > > > I have no objection to adding "Updates: 3945" to the document header > > and matching 3945's category. > > > > Lou > > > > At 05:11 PM 1/22/2008, PAPADIMITRIOU Dimitri wrote: > > >Lou > > > > > >what i am concerned with: is that the doc extends > > applicability of GMPLS > > >to Ethernet by excluding GMPLS for Ethernet per RFC 3945 ? does that > > >make sense ? > > > > > >what's needed instead of hiding behind terms is to state GMPLS for Y, > > >where Y includes the set of Ethernet-based techno's under > > development at > > >places as indicated in the doc itself. instead of inducing by a title > > >such as "GMPLS for Ethernet" that this doc supersedes any > > previous work > > >in that > > >space. > > > > > >-d. > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: owner-ccamp@ops.ietf.org > > > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Lou Berger > > > > Sent: Tuesday, January 22, 2008 10:50 PM > > > > To: Don Fedyk > > > > Cc: PAPADIMITRIOU Dimitri; BRUNGARD, DEBORAH A, ATTLABS; > > > > ccamp@ops.ietf.org > > > > Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt > > > > > > > > Don, > > > > I agree 100%. Furthermore there is no statement in the > > > > draft that 3945 doesn't apply, in fact it explicitly says just the > > > > opposite. The reason for the statement in question is > > simply as you > > > > say, and to ensure full ETH-LSP definition and interoperable > > > > operation a new switching type/capability is required. > > > > > > > > It's really not such a bid deal or major change. > > > > > > > > Lou > > > > > > > > At 04:34 PM 1/22/2008, Don Fedyk wrote: > > > > >Hi Dimitri > > > > > > > > > >The text you quote was put in the architecture/ framework, not to > > > > >exclude L2 Switch Capable (L2SC) but to prevent redefining > > > > L2SC, which > > > > >has been there for many years and may be in use. > > > > > > > > > >Perhaps the working needs to be adjusted but I don't think > > > > it is a major > > > > >issue. > > > > > > > > > >Regards, > > > > >Don > > > > > > > > > > > -----Original Message----- > > > > > > From: owner-ccamp@ops.ietf.org > > > > > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of > > > > PAPADIMITRIOU Dimitri > > > > > > Sent: Tuesday, January 22, 2008 4:16 PM > > > > > > To: BRUNGARD, DEBORAH A, ATTLABS; ccamp@ops.ietf.org > > > > > > Subject: RE: Proposed WG Draft - > > draft-gmpls-ethernet-arch-00.txt > > > > > > > > > > > > All, > > > > > > > > > > > > > We received a couple of comments in the meeting, we would > > > > > > > appreciate additional feedback on the list. > > > > > > > > > > > > The document states: > > > > > > > > > > > > "The L2SC Interface Switching Capabilities MUST NOT be used > > > > > > to represent > > > > > > interfaces capable of supporting Eth-LSPs. Interface Switching > > > > > > Capability specific TE information may be defined as > > > > needed to support > > > > > > the requirements of a specific Ethernet Switching > > Service Type." > > > > > > > > > > > > [...] > > > > > > > > > > > > "It is expected that there will be no case where an > > > > Eth-LSP will be > > > > > > signaled, or an Eth-LSP supporting interface will be > > > > > > represented, using > > > > > > the L2SC switching type/capability. A new switching > > > > type/capability is > > > > > > required to avoid any potential current usage of the L2SC > > > > switching > > > > > > type/capability in support of Ethernet." > > > > > > > > > > > > This is explicit statement that GMPLS per RFC 3945 is not > > > > applicable. > > > > > > So, it is much more than just an additional codepoint, as > > > > the control > > > > > > plane behaviour is to be defined for this codepoint. So, it > > > > > > is the open > > > > > > door for a new control plane behaviour. > > > > > > > > > > > > so, let's have a more basic questioning before jumping > > > > into the single > > > > > > alternative resulting from this doc.: > > > > > > > > > > > > - either it is GMPLS for Ethernet architecture and then > > > > what exist in > > > > > > current RFCs should be applicable (because i do not see > > > > any rationale > > > > > > for L2SC def. departure for Ethernet frame processing); > > > > > > > > > > > > - or not it is X for Y architecture, where X is an IP > > > > control protocol > > > > > > based some potentially on some existing GMPLS blocks > > and Y is not > > > > > > compatible with the existing definition of Eth frame > > processing. > > > > > > > > > > > > In the latter case, i do not know how this WG can deal > > > > with such case > > > > > > (from the control plane perspective). > > > > > > > > > > > > -d. > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: owner-ccamp@ops.ietf.org > > > > > > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of BRUNGARD, > > > > > > > DEBORAH A, ATTLABS > > > > > > > Sent: Tuesday, January 22, 2008 8:28 PM > > > > > > > To: ccamp@ops.ietf.org > > > > > > > Subject: Proposed WG Draft - > > draft-gmpls-ethernet-arch-00.txt > > > > > > > > > > > > > > CCAMP, > > > > > > > > > > > > > > The DT proposed in their meeting presentation for their > > > > > > > architecture and framework document to be accepted as a > > > > WG draft: > > > > > > > > > > > > > http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt > > > > > > > > > > > > > > We received a couple of comments in the meeting, we would > > > > > > > appreciate additional feedback on the list. Please express > > > > > > > your support (or otherwise) for this I-D to become > > a WG draft. > > > > > > > > > > > > > > Thanks, > > > > > > > Deborah > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 22 Jan 2008 22:46:54 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Date: Tue, 22 Jan 2008 23:44:49 +0100 Message-ID: Thread-Topic: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Thread-Index: AchdRg0gQbG+sqB3QeGKnEMmTkpUoAAACQTQ From: "PAPADIMITRIOU Dimitri" To: "Lou Berger" Cc: "Don Fedyk" , "BRUNGARD, DEBORAH A, ATTLABS" , thus the question is whether or not to ask for a change CCAMP "common control" in DCAMP "differentiated control" per technology ?=20 we never have had a techno inducing a base building block change (GMPLS being a generalisation of MPLS-TE). i'm afraid that generalized LSP, generalized LSR, generalized label, etc. per GMPLS arch (RFC 3945) would simply be unapplicable as known today and thus the corr. base protocol specs unapplicable. at the end the term "GMPLS" would be emptied of any real substance. it's a choice but let's ask the questions from the right perspective. -d.=20 > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net]=20 > Sent: Tuesday, January 22, 2008 11:28 PM > To: PAPADIMITRIOU Dimitri > Cc: Lou Berger; Don Fedyk; BRUNGARD, DEBORAH A, ATTLABS;=20 > ccamp@ops.ietf.org > Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt >=20 > I have no objection to adding "Updates: 3945" to the document header=20 > and matching 3945's category. >=20 > Lou >=20 > At 05:11 PM 1/22/2008, PAPADIMITRIOU Dimitri wrote: > >Lou > > > >what i am concerned with: is that the doc extends=20 > applicability of GMPLS > >to Ethernet by excluding GMPLS for Ethernet per RFC 3945 ? does that > >make sense ? > > > >what's needed instead of hiding behind terms is to state GMPLS for Y, > >where Y includes the set of Ethernet-based techno's under=20 > development at > >places as indicated in the doc itself. instead of inducing by a title > >such as "GMPLS for Ethernet" that this doc supersedes any=20 > previous work > >in that > >space. > > > >-d. > > > > > > > > > > > -----Original Message----- > > > From: owner-ccamp@ops.ietf.org > > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Lou Berger > > > Sent: Tuesday, January 22, 2008 10:50 PM > > > To: Don Fedyk > > > Cc: PAPADIMITRIOU Dimitri; BRUNGARD, DEBORAH A, ATTLABS; > > > ccamp@ops.ietf.org > > > Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt > > > > > > Don, > > > I agree 100%. Furthermore there is no statement in the > > > draft that 3945 doesn't apply, in fact it explicitly says just the > > > opposite. The reason for the statement in question is=20 > simply as you > > > say, and to ensure full ETH-LSP definition and interoperable > > > operation a new switching type/capability is required. > > > > > > It's really not such a bid deal or major change. > > > > > > Lou > > > > > > At 04:34 PM 1/22/2008, Don Fedyk wrote: > > > >Hi Dimitri > > > > > > > >The text you quote was put in the architecture/ framework, not to > > > >exclude L2 Switch Capable (L2SC) but to prevent redefining > > > L2SC, which > > > >has been there for many years and may be in use. > > > > > > > >Perhaps the working needs to be adjusted but I don't think > > > it is a major > > > >issue. > > > > > > > >Regards, > > > >Don > > > > > > > > > -----Original Message----- > > > > > From: owner-ccamp@ops.ietf.org > > > > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of > > > PAPADIMITRIOU Dimitri > > > > > Sent: Tuesday, January 22, 2008 4:16 PM > > > > > To: BRUNGARD, DEBORAH A, ATTLABS; ccamp@ops.ietf.org > > > > > Subject: RE: Proposed WG Draft -=20 > draft-gmpls-ethernet-arch-00.txt > > > > > > > > > > All, > > > > > > > > > > > We received a couple of comments in the meeting, we would > > > > > > appreciate additional feedback on the list. > > > > > > > > > > The document states: > > > > > > > > > > "The L2SC Interface Switching Capabilities MUST NOT be used > > > > > to represent > > > > > interfaces capable of supporting Eth-LSPs. Interface Switching > > > > > Capability specific TE information may be defined as > > > needed to support > > > > > the requirements of a specific Ethernet Switching=20 > Service Type." > > > > > > > > > > [...] > > > > > > > > > > "It is expected that there will be no case where an > > > Eth-LSP will be > > > > > signaled, or an Eth-LSP supporting interface will be > > > > > represented, using > > > > > the L2SC switching type/capability. A new switching > > > type/capability is > > > > > required to avoid any potential current usage of the L2SC > > > switching > > > > > type/capability in support of Ethernet." > > > > > > > > > > This is explicit statement that GMPLS per RFC 3945 is not > > > applicable. > > > > > So, it is much more than just an additional codepoint, as > > > the control > > > > > plane behaviour is to be defined for this codepoint. So, it > > > > > is the open > > > > > door for a new control plane behaviour. > > > > > > > > > > so, let's have a more basic questioning before jumping > > > into the single > > > > > alternative resulting from this doc.: > > > > > > > > > > - either it is GMPLS for Ethernet architecture and then > > > what exist in > > > > > current RFCs should be applicable (because i do not see > > > any rationale > > > > > for L2SC def. departure for Ethernet frame processing); > > > > > > > > > > - or not it is X for Y architecture, where X is an IP > > > control protocol > > > > > based some potentially on some existing GMPLS blocks=20 > and Y is not > > > > > compatible with the existing definition of Eth frame=20 > processing. > > > > > > > > > > In the latter case, i do not know how this WG can deal > > > with such case > > > > > (from the control plane perspective). > > > > > > > > > > -d. > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: owner-ccamp@ops.ietf.org > > > > > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of BRUNGARD, > > > > > > DEBORAH A, ATTLABS > > > > > > Sent: Tuesday, January 22, 2008 8:28 PM > > > > > > To: ccamp@ops.ietf.org > > > > > > Subject: Proposed WG Draft -=20 > draft-gmpls-ethernet-arch-00.txt > > > > > > > > > > > > CCAMP, > > > > > > > > > > > > The DT proposed in their meeting presentation for their > > > > > > architecture and framework document to be accepted as a > > > WG draft: > > > > > > > > >=20 > http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt > > > > > > > > > > > > We received a couple of comments in the meeting, we would > > > > > > appreciate additional feedback on the list. Please express > > > > > > your support (or otherwise) for this I-D to become=20 > a WG draft. > > > > > > > > > > > > Thanks, > > > > > > Deborah > > > > > > > > > > > > > > > > > > > > > > > > > >=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 22 Jan 2008 22:28:38 +0000 Date: Tue, 22 Jan 2008 17:28:08 -0500 To: "PAPADIMITRIOU Dimitri" From: Lou Berger Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Cc: "Lou Berger" ,"Don Fedyk" , "BRUNGARD, DEBORAH A, ATTLABS" , Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-Id: I have no objection to adding "Updates: 3945" to the document header and matching 3945's category. Lou At 05:11 PM 1/22/2008, PAPADIMITRIOU Dimitri wrote: >Lou > >what i am concerned with: is that the doc extends applicability of GMPLS >to Ethernet by excluding GMPLS for Ethernet per RFC 3945 ? does that >make sense ? > >what's needed instead of hiding behind terms is to state GMPLS for Y, >where Y includes the set of Ethernet-based techno's under development at >places as indicated in the doc itself. instead of inducing by a title >such as "GMPLS for Ethernet" that this doc supersedes any previous work >in that >space. > >-d. > > > > > > -----Original Message----- > > From: owner-ccamp@ops.ietf.org > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Lou Berger > > Sent: Tuesday, January 22, 2008 10:50 PM > > To: Don Fedyk > > Cc: PAPADIMITRIOU Dimitri; BRUNGARD, DEBORAH A, ATTLABS; > > ccamp@ops.ietf.org > > Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt > > > > Don, > > I agree 100%. Furthermore there is no statement in the > > draft that 3945 doesn't apply, in fact it explicitly says just the > > opposite. The reason for the statement in question is simply as you > > say, and to ensure full ETH-LSP definition and interoperable > > operation a new switching type/capability is required. > > > > It's really not such a bid deal or major change. > > > > Lou > > > > At 04:34 PM 1/22/2008, Don Fedyk wrote: > > >Hi Dimitri > > > > > >The text you quote was put in the architecture/ framework, not to > > >exclude L2 Switch Capable (L2SC) but to prevent redefining > > L2SC, which > > >has been there for many years and may be in use. > > > > > >Perhaps the working needs to be adjusted but I don't think > > it is a major > > >issue. > > > > > >Regards, > > >Don > > > > > > > -----Original Message----- > > > > From: owner-ccamp@ops.ietf.org > > > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of > > PAPADIMITRIOU Dimitri > > > > Sent: Tuesday, January 22, 2008 4:16 PM > > > > To: BRUNGARD, DEBORAH A, ATTLABS; ccamp@ops.ietf.org > > > > Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt > > > > > > > > All, > > > > > > > > > We received a couple of comments in the meeting, we would > > > > > appreciate additional feedback on the list. > > > > > > > > The document states: > > > > > > > > "The L2SC Interface Switching Capabilities MUST NOT be used > > > > to represent > > > > interfaces capable of supporting Eth-LSPs. Interface Switching > > > > Capability specific TE information may be defined as > > needed to support > > > > the requirements of a specific Ethernet Switching Service Type." > > > > > > > > [...] > > > > > > > > "It is expected that there will be no case where an > > Eth-LSP will be > > > > signaled, or an Eth-LSP supporting interface will be > > > > represented, using > > > > the L2SC switching type/capability. A new switching > > type/capability is > > > > required to avoid any potential current usage of the L2SC > > switching > > > > type/capability in support of Ethernet." > > > > > > > > This is explicit statement that GMPLS per RFC 3945 is not > > applicable. > > > > So, it is much more than just an additional codepoint, as > > the control > > > > plane behaviour is to be defined for this codepoint. So, it > > > > is the open > > > > door for a new control plane behaviour. > > > > > > > > so, let's have a more basic questioning before jumping > > into the single > > > > alternative resulting from this doc.: > > > > > > > > - either it is GMPLS for Ethernet architecture and then > > what exist in > > > > current RFCs should be applicable (because i do not see > > any rationale > > > > for L2SC def. departure for Ethernet frame processing); > > > > > > > > - or not it is X for Y architecture, where X is an IP > > control protocol > > > > based some potentially on some existing GMPLS blocks and Y is not > > > > compatible with the existing definition of Eth frame processing. > > > > > > > > In the latter case, i do not know how this WG can deal > > with such case > > > > (from the control plane perspective). > > > > > > > > -d. > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: owner-ccamp@ops.ietf.org > > > > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of BRUNGARD, > > > > > DEBORAH A, ATTLABS > > > > > Sent: Tuesday, January 22, 2008 8:28 PM > > > > > To: ccamp@ops.ietf.org > > > > > Subject: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt > > > > > > > > > > CCAMP, > > > > > > > > > > The DT proposed in their meeting presentation for their > > > > > architecture and framework document to be accepted as a > > WG draft: > > > > > > > http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt > > > > > > > > > > We received a couple of comments in the meeting, we would > > > > > appreciate additional feedback on the list. Please express > > > > > your support (or otherwise) for this I-D to become a WG draft. > > > > > > > > > > Thanks, > > > > > Deborah > > > > > > > > > > > > > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 22 Jan 2008 22:13:09 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Date: Tue, 22 Jan 2008 23:11:21 +0100 Message-ID: Thread-Topic: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Thread-Index: AchdQOk1q100BH0uRjeUnZJetJe7CQAAOPUQ From: "PAPADIMITRIOU Dimitri" To: "Lou Berger" , "Don Fedyk" Cc: "BRUNGARD, DEBORAH A, ATTLABS" , Lou what i am concerned with: is that the doc extends applicability of GMPLS to Ethernet by excluding GMPLS for Ethernet per RFC 3945 ? does that make sense ? what's needed instead of hiding behind terms is to state GMPLS for Y, where Y includes the set of Ethernet-based techno's under development at places as indicated in the doc itself. instead of inducing by a title such as "GMPLS for Ethernet" that this doc supersedes any previous work in that space. -d. =20 > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Lou Berger > Sent: Tuesday, January 22, 2008 10:50 PM > To: Don Fedyk > Cc: PAPADIMITRIOU Dimitri; BRUNGARD, DEBORAH A, ATTLABS;=20 > ccamp@ops.ietf.org > Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt >=20 > Don, > I agree 100%. Furthermore there is no statement in the=20 > draft that 3945 doesn't apply, in fact it explicitly says just the=20 > opposite. The reason for the statement in question is simply as you=20 > say, and to ensure full ETH-LSP definition and interoperable=20 > operation a new switching type/capability is required. >=20 > It's really not such a bid deal or major change. >=20 > Lou >=20 > At 04:34 PM 1/22/2008, Don Fedyk wrote: > >Hi Dimitri > > > >The text you quote was put in the architecture/ framework, not to > >exclude L2 Switch Capable (L2SC) but to prevent redefining=20 > L2SC, which > >has been there for many years and may be in use. > > > >Perhaps the working needs to be adjusted but I don't think=20 > it is a major > >issue. > > > >Regards, > >Don > > > > > -----Original Message----- > > > From: owner-ccamp@ops.ietf.org > > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of=20 > PAPADIMITRIOU Dimitri > > > Sent: Tuesday, January 22, 2008 4:16 PM > > > To: BRUNGARD, DEBORAH A, ATTLABS; ccamp@ops.ietf.org > > > Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt > > > > > > All, > > > > > > > We received a couple of comments in the meeting, we would > > > > appreciate additional feedback on the list. > > > > > > The document states: > > > > > > "The L2SC Interface Switching Capabilities MUST NOT be used > > > to represent > > > interfaces capable of supporting Eth-LSPs. Interface Switching > > > Capability specific TE information may be defined as=20 > needed to support > > > the requirements of a specific Ethernet Switching Service Type." > > > > > > [...] > > > > > > "It is expected that there will be no case where an=20 > Eth-LSP will be > > > signaled, or an Eth-LSP supporting interface will be > > > represented, using > > > the L2SC switching type/capability. A new switching=20 > type/capability is > > > required to avoid any potential current usage of the L2SC=20 > switching > > > type/capability in support of Ethernet." > > > > > > This is explicit statement that GMPLS per RFC 3945 is not=20 > applicable. > > > So, it is much more than just an additional codepoint, as=20 > the control > > > plane behaviour is to be defined for this codepoint. So, it > > > is the open > > > door for a new control plane behaviour. > > > > > > so, let's have a more basic questioning before jumping=20 > into the single > > > alternative resulting from this doc.: > > > > > > - either it is GMPLS for Ethernet architecture and then=20 > what exist in > > > current RFCs should be applicable (because i do not see=20 > any rationale > > > for L2SC def. departure for Ethernet frame processing); > > > > > > - or not it is X for Y architecture, where X is an IP=20 > control protocol > > > based some potentially on some existing GMPLS blocks and Y is not > > > compatible with the existing definition of Eth frame processing. > > > > > > In the latter case, i do not know how this WG can deal=20 > with such case > > > (from the control plane perspective). > > > > > > -d. > > > > > > > > > > > > > -----Original Message----- > > > > From: owner-ccamp@ops.ietf.org > > > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of BRUNGARD, > > > > DEBORAH A, ATTLABS > > > > Sent: Tuesday, January 22, 2008 8:28 PM > > > > To: ccamp@ops.ietf.org > > > > Subject: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt > > > > > > > > CCAMP, > > > > > > > > The DT proposed in their meeting presentation for their > > > > architecture and framework document to be accepted as a=20 > WG draft: > > > >=20 > http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt > > > > > > > > We received a couple of comments in the meeting, we would > > > > appreciate additional feedback on the list. Please express > > > > your support (or otherwise) for this I-D to become a WG draft. > > > > > > > > Thanks, > > > > Deborah > > > > > > > > > > >=20 >=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 22 Jan 2008 21:53: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: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Date: Tue, 22 Jan 2008 22:52:55 +0100 Message-ID: Thread-Topic: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Thread-Index: AchdLOH3JrqySZgzQVuueGk7Nk+CoAACAVJwAAJDMzAAAET6AA== From: "PAPADIMITRIOU Dimitri" To: "Don Fedyk" , "BRUNGARD, DEBORAH A, ATTLABS" , Don, then two things are missing that this new xSC is not resulting in a control plane departing from RFC 3945 and this xSC is not part overlapping with L2SC.=20 you are thus in the alternative: GMPLS for Y architecture, where Y is not compatible with the existing definition of Eth frame processing per L2SC ? is that correct. thanks, -d. =20 > -----Original Message----- > From: Don Fedyk [mailto:dwfedyk@nortel.com]=20 > Sent: Tuesday, January 22, 2008 10:35 PM > To: PAPADIMITRIOU Dimitri; BRUNGARD, DEBORAH A, ATTLABS;=20 > ccamp@ops.ietf.org > Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt >=20 > Hi Dimitri >=20 > The text you quote was put in the architecture/ framework, not to > exclude L2 Switch Capable (L2SC) but to prevent redefining L2SC, which > has been there for many years and may be in use.=20 >=20 > Perhaps the working needs to be adjusted but I don't think it=20 > is a major > issue. >=20 > Regards, > Don=20 >=20 > > -----Original Message----- > > From: owner-ccamp@ops.ietf.org=20 > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of PAPADIMITRIOU Dimitri > > Sent: Tuesday, January 22, 2008 4:16 PM > > To: BRUNGARD, DEBORAH A, ATTLABS; ccamp@ops.ietf.org > > Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt > >=20 > > All, > >=20 > > > We received a couple of comments in the meeting, we would=20 > > > appreciate additional feedback on the list. > >=20 > > The document states: > >=20 > > "The L2SC Interface Switching Capabilities MUST NOT be used=20 > > to represent > > interfaces capable of supporting Eth-LSPs. Interface Switching > > Capability specific TE information may be defined as needed=20 > to support > > the requirements of a specific Ethernet Switching Service Type." > >=20 > > [...] > >=20 > > "It is expected that there will be no case where an Eth-LSP will be > > signaled, or an Eth-LSP supporting interface will be=20 > > represented, using > > the L2SC switching type/capability. A new switching=20 > type/capability is > > required to avoid any potential current usage of the L2SC switching > > type/capability in support of Ethernet." > >=20 > > This is explicit statement that GMPLS per RFC 3945 is not=20 > applicable. > > So, it is much more than just an additional codepoint, as=20 > the control > > plane behaviour is to be defined for this codepoint. So, it=20 > > is the open > > door for a new control plane behaviour.=20 > >=20 > > so, let's have a more basic questioning before jumping into=20 > the single > > alternative resulting from this doc.: > >=20 > > - either it is GMPLS for Ethernet architecture and then=20 > what exist in > > current RFCs should be applicable (because i do not see any=20 > rationale > > for L2SC def. departure for Ethernet frame processing); > >=20 > > - or not it is X for Y architecture, where X is an IP=20 > control protocol > > based some potentially on some existing GMPLS blocks and Y is not > > compatible with the existing definition of Eth frame processing. > >=20 > > In the latter case, i do not know how this WG can deal with=20 > such case > > (from the control plane perspective). > >=20 > > -d. > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: owner-ccamp@ops.ietf.org=20 > > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of BRUNGARD,=20 > > > DEBORAH A, ATTLABS > > > Sent: Tuesday, January 22, 2008 8:28 PM > > > To: ccamp@ops.ietf.org > > > Subject: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt > > >=20 > > > CCAMP, > > > =20 > > > The DT proposed in their meeting presentation for their=20 > > > architecture and framework document to be accepted as a WG draft: > > >=20 > http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt > > > =20 > > > We received a couple of comments in the meeting, we would=20 > > > appreciate additional feedback on the list. Please express=20 > > > your support (or otherwise) for this I-D to become a WG draft. > > > =20 > > > Thanks, > > > Deborah > > >=20 > >=20 > >=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 22 Jan 2008 21:51:07 +0000 Date: Tue, 22 Jan 2008 16:50:25 -0500 To: "Don Fedyk" From: Lou Berger Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Cc: "PAPADIMITRIOU Dimitri" , "BRUNGARD, DEBORAH A, ATTLABS" , Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-Id: Don, I agree 100%. Furthermore there is no statement in the draft that 3945 doesn't apply, in fact it explicitly says just the opposite. The reason for the statement in question is simply as you say, and to ensure full ETH-LSP definition and interoperable operation a new switching type/capability is required. It's really not such a bid deal or major change. Lou At 04:34 PM 1/22/2008, Don Fedyk wrote: >Hi Dimitri > >The text you quote was put in the architecture/ framework, not to >exclude L2 Switch Capable (L2SC) but to prevent redefining L2SC, which >has been there for many years and may be in use. > >Perhaps the working needs to be adjusted but I don't think it is a major >issue. > >Regards, >Don > > > -----Original Message----- > > From: owner-ccamp@ops.ietf.org > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of PAPADIMITRIOU Dimitri > > Sent: Tuesday, January 22, 2008 4:16 PM > > To: BRUNGARD, DEBORAH A, ATTLABS; ccamp@ops.ietf.org > > Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt > > > > All, > > > > > We received a couple of comments in the meeting, we would > > > appreciate additional feedback on the list. > > > > The document states: > > > > "The L2SC Interface Switching Capabilities MUST NOT be used > > to represent > > interfaces capable of supporting Eth-LSPs. Interface Switching > > Capability specific TE information may be defined as needed to support > > the requirements of a specific Ethernet Switching Service Type." > > > > [...] > > > > "It is expected that there will be no case where an Eth-LSP will be > > signaled, or an Eth-LSP supporting interface will be > > represented, using > > the L2SC switching type/capability. A new switching type/capability is > > required to avoid any potential current usage of the L2SC switching > > type/capability in support of Ethernet." > > > > This is explicit statement that GMPLS per RFC 3945 is not applicable. > > So, it is much more than just an additional codepoint, as the control > > plane behaviour is to be defined for this codepoint. So, it > > is the open > > door for a new control plane behaviour. > > > > so, let's have a more basic questioning before jumping into the single > > alternative resulting from this doc.: > > > > - either it is GMPLS for Ethernet architecture and then what exist in > > current RFCs should be applicable (because i do not see any rationale > > for L2SC def. departure for Ethernet frame processing); > > > > - or not it is X for Y architecture, where X is an IP control protocol > > based some potentially on some existing GMPLS blocks and Y is not > > compatible with the existing definition of Eth frame processing. > > > > In the latter case, i do not know how this WG can deal with such case > > (from the control plane perspective). > > > > -d. > > > > > > > > > -----Original Message----- > > > From: owner-ccamp@ops.ietf.org > > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of BRUNGARD, > > > DEBORAH A, ATTLABS > > > Sent: Tuesday, January 22, 2008 8:28 PM > > > To: ccamp@ops.ietf.org > > > Subject: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt > > > > > > CCAMP, > > > > > > The DT proposed in their meeting presentation for their > > > architecture and framework document to be accepted as a WG draft: > > > http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt > > > > > > We received a couple of comments in the meeting, we would > > > appreciate additional feedback on the list. Please express > > > your support (or otherwise) for this I-D to become a WG draft. > > > > > > Thanks, > > > Deborah > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 22 Jan 2008 21:35:55 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Date: Tue, 22 Jan 2008 16:34:58 -0500 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA41340D7D1@zrtphxm2.corp.nortel.com> Thread-Topic: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Thread-Index: AchdLOH3JrqySZgzQVuueGk7Nk+CoAACAVJwAAJDMzA= From: "Don Fedyk" To: "PAPADIMITRIOU Dimitri" , "BRUNGARD, DEBORAH A, ATTLABS" , Hi Dimitri The text you quote was put in the architecture/ framework, not to exclude L2 Switch Capable (L2SC) but to prevent redefining L2SC, which has been there for many years and may be in use.=20 Perhaps the working needs to be adjusted but I don't think it is a major issue. Regards, Don=20 > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of PAPADIMITRIOU Dimitri > Sent: Tuesday, January 22, 2008 4:16 PM > To: BRUNGARD, DEBORAH A, ATTLABS; ccamp@ops.ietf.org > Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt >=20 > All, >=20 > > We received a couple of comments in the meeting, we would=20 > > appreciate additional feedback on the list. >=20 > The document states: >=20 > "The L2SC Interface Switching Capabilities MUST NOT be used=20 > to represent > interfaces capable of supporting Eth-LSPs. Interface Switching > Capability specific TE information may be defined as needed to support > the requirements of a specific Ethernet Switching Service Type." >=20 > [...] >=20 > "It is expected that there will be no case where an Eth-LSP will be > signaled, or an Eth-LSP supporting interface will be=20 > represented, using > the L2SC switching type/capability. A new switching type/capability is > required to avoid any potential current usage of the L2SC switching > type/capability in support of Ethernet." >=20 > This is explicit statement that GMPLS per RFC 3945 is not applicable. > So, it is much more than just an additional codepoint, as the control > plane behaviour is to be defined for this codepoint. So, it=20 > is the open > door for a new control plane behaviour.=20 >=20 > so, let's have a more basic questioning before jumping into the single > alternative resulting from this doc.: >=20 > - either it is GMPLS for Ethernet architecture and then what exist in > current RFCs should be applicable (because i do not see any rationale > for L2SC def. departure for Ethernet frame processing); >=20 > - or not it is X for Y architecture, where X is an IP control protocol > based some potentially on some existing GMPLS blocks and Y is not > compatible with the existing definition of Eth frame processing. >=20 > In the latter case, i do not know how this WG can deal with such case > (from the control plane perspective). >=20 > -d. >=20 >=20 >=20 > > -----Original Message----- > > From: owner-ccamp@ops.ietf.org=20 > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of BRUNGARD,=20 > > DEBORAH A, ATTLABS > > Sent: Tuesday, January 22, 2008 8:28 PM > > To: ccamp@ops.ietf.org > > Subject: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt > >=20 > > CCAMP, > > =20 > > The DT proposed in their meeting presentation for their=20 > > architecture and framework document to be accepted as a WG draft: > > http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt > > =20 > > We received a couple of comments in the meeting, we would=20 > > appreciate additional feedback on the list. Please express=20 > > your support (or otherwise) for this I-D to become a WG draft. > > =20 > > Thanks, > > Deborah > >=20 >=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 22 Jan 2008 21:16: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: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Date: Tue, 22 Jan 2008 22:16:00 +0100 Message-ID: Thread-Topic: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Thread-Index: AchdLOH3JrqySZgzQVuueGk7Nk+CoAACAVJw From: "PAPADIMITRIOU Dimitri" To: "BRUNGARD, DEBORAH A, ATTLABS" , All, > We received a couple of comments in the meeting, we would=20 > appreciate additional feedback on the list. The document states: "The L2SC Interface Switching Capabilities MUST NOT be used to represent interfaces capable of supporting Eth-LSPs. Interface Switching Capability specific TE information may be defined as needed to support the requirements of a specific Ethernet Switching Service Type." [...] "It is expected that there will be no case where an Eth-LSP will be signaled, or an Eth-LSP supporting interface will be represented, using the L2SC switching type/capability. A new switching type/capability is required to avoid any potential current usage of the L2SC switching type/capability in support of Ethernet." This is explicit statement that GMPLS per RFC 3945 is not applicable. So, it is much more than just an additional codepoint, as the control plane behaviour is to be defined for this codepoint. So, it is the open door for a new control plane behaviour.=20 so, let's have a more basic questioning before jumping into the single alternative resulting from this doc.: - either it is GMPLS for Ethernet architecture and then what exist in current RFCs should be applicable (because i do not see any rationale for L2SC def. departure for Ethernet frame processing); - or not it is X for Y architecture, where X is an IP control protocol based some potentially on some existing GMPLS blocks and Y is not compatible with the existing definition of Eth frame processing. In the latter case, i do not know how this WG can deal with such case (from the control plane perspective). -d. > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of BRUNGARD,=20 > DEBORAH A, ATTLABS > Sent: Tuesday, January 22, 2008 8:28 PM > To: ccamp@ops.ietf.org > Subject: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt >=20 > CCAMP, > =20 > The DT proposed in their meeting presentation for their=20 > architecture and framework document to be accepted as a WG draft: > http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt > =20 > We received a couple of comments in the meeting, we would=20 > appreciate additional feedback on the list. Please express=20 > your support (or otherwise) for this I-D to become a WG draft. > =20 > Thanks, > Deborah >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 22 Jan 2008 21:13:35 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C85D3B.919D98EF" Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Date: Tue, 22 Jan 2008 16:13:00 -0500 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA41340D74F@zrtphxm2.corp.nortel.com> Thread-Topic: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Thread-Index: AchdLOH3JrqySZgzQVuueGk7Nk+CoAADfNJQ From: "Don Fedyk" To: This is a multi-part message in MIME format. ------_=_NextPart_001_01C85D3B.919D98EF Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In Favor, =20 Thanks, Don=20 ________________________________ From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of BRUNGARD, DEBORAH A, ATTLABS Sent: Tuesday, January 22, 2008 2:28 PM To: ccamp@ops.ietf.org Subject: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt =09 =09 CCAMP, =20 The DT proposed in their meeting presentation for their architecture and framework document to be accepted as a WG draft: =09 http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt =20 We received a couple of comments in the meeting, we would appreciate additional feedback on the list. Please express your support (or otherwise) for this I-D to become a WG draft. =20 Thanks, Deborah ------_=_NextPart_001_01C85D3B.919D98EF Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
In Favor,
 
Thanks,
Don

From: owner-ccamp@ops.ietf.org=20 [mailto:owner-ccamp@ops.ietf.org] On Behalf Of BRUNGARD, = DEBORAH A,=20 ATTLABS
Sent: Tuesday, January 22, 2008 2:28 = PM
To:=20 ccamp@ops.ietf.org
Subject: Proposed WG Draft -=20 draft-gmpls-ethernet-arch-00.txt

CCAMP,
 
The = DT proposed in=20 their meeting presentation for their architecture and framework=20 document to be accepted as a WG = draft:
http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt=
 
We = received a=20 couple of comments in the meeting, we would appreciate additional = feedback on the list. Please express your support (or otherwise) = for this=20 I-D to become a WG draft.
 
Thanks,
Deborah
------_=_NextPart_001_01C85D3B.919D98EF-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 22 Jan 2008 21:05:46 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C85D3A.5AE561BA" Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Date: Tue, 22 Jan 2008 16:04:19 -0500 Message-ID: <3C13767EA2F93441AFB13A630204F1B29FBBD4@mamxm02.ciena.com> Thread-Topic: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Thread-Index: AchdLOH3JrqySZgzQVuueGk7Nk+CoAADWTFA From: "Shah, Himanshu" To: "BRUNGARD, DEBORAH A, ATTLABS" , This is a multi-part message in MIME format. ------_=_NextPart_001_01C85D3A.5AE561BA Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable support for WG draft.. =20 /himanshu -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On = Behalf Of BRUNGARD, DEBORAH A, ATTLABS Sent: Tuesday, January 22, 2008 2:28 PM To: ccamp@ops.ietf.org Subject: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt CCAMP, =20 The DT proposed in their meeting presentation for their architecture and = framework document to be accepted as a WG draft: http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt =20 We received a couple of comments in the meeting, we would appreciate = additional feedback on the list. Please express your support (or = otherwise) for this I-D to become a WG draft. =20 Thanks, Deborah ------_=_NextPart_001_01C85D3A.5AE561BA Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
support=20 for WG draft..
 
/himanshu
-----Original Message-----
From: = owner-ccamp@ops.ietf.org=20 [mailto:owner-ccamp@ops.ietf.org]On Behalf Of BRUNGARD, DEBORAH = A,=20 ATTLABS
Sent: Tuesday, January 22, 2008 2:28 = PM
To:=20 ccamp@ops.ietf.org
Subject: Proposed WG Draft -=20 draft-gmpls-ethernet-arch-00.txt

CCAMP,
 
The = DT proposed in=20 their meeting presentation for their architecture and framework=20 document to be accepted as a WG = draft:
http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt=
 
We = received a=20 couple of comments in the meeting, we would appreciate additional = feedback on the list. Please express your support (or otherwise) = for this=20 I-D to become a WG draft.
 
Thanks,
Deborah
------_=_NextPart_001_01C85D3A.5AE561BA-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 22 Jan 2008 20:29:03 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C85D35.6195E455" Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Date: Tue, 22 Jan 2008 22:28:36 +0200 Message-ID: Thread-Topic: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Thread-Index: AchdLOH3JrqySZgzQVuueGk7Nk+CoAABQxBwAACgXMAAADc4QA== From: "Nurit Sprecher" To: "ext BRUNGARD, DEBORAH A, ATTLABS" Cc: This is a multi-part message in MIME format. ------_=_NextPart_001_01C85D35.6195E455 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Deborah, I am in favor of this as well :-) Best regards, Nurit =20 ________________________________ From: ext BRUNGARD, DEBORAH A, ATTLABS [mailto:dbrungard@att.com]=20 Sent: Tuesday, January 22, 2008 22:25 To: Nurit Sprecher Cc: ccamp@ops.ietf.org Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt =20 Hi Nurit, =20 We will poll one-by-one to ensure separation;-) =20 Deborah =20 ________________________________ From: Nurit Sprecher [mailto:nurit.sprecher@nsn.com]=20 Sent: Tuesday, January 22, 2008 3:10 PM To: BRUNGARD, DEBORAH A, ATTLABS Cc: ccamp@ops.ietf.org Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Hi, =20 I think that draft-gmpls-ethernet-arch-00.txt should be a WG draft. =20 In addition, the authors of draft-fedyk-gmpls-ethernet-pbb-te-02.txt also proposed that their draft is accepted as a WG draft. Naturally, I am in favor of this as well. Can we ask feedback for this draft as well? =20 Best regards, Nurit ________________________________ From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of ext BRUNGARD, DEBORAH A, ATTLABS Sent: Tuesday, January 22, 2008 21:28 To: ccamp@ops.ietf.org Subject: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt =20 CCAMP, =20 The DT proposed in their meeting presentation for their architecture and framework document to be accepted as a WG draft: http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt =20 We received a couple of comments in the meeting, we would appreciate additional feedback on the list. Please express your support (or otherwise) for this I-D to become a WG draft. =20 Thanks, Deborah ------_=_NextPart_001_01C85D35.6195E455 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Deborah,

I am in favor of = this as well J

Best = regards,

Nurit<= /span>

 =

From: ext BRUNGARD, DEBORAH A, ATTLABS [mailto:dbrungard@att.com]
Sent: Tuesday, January = 22, 2008 22:25
To: Nurit Sprecher
Cc: = ccamp@ops.ietf.org
Subject: RE: Proposed WG = Draft - draft-gmpls-ethernet-arch-00.txt

 

Hi = Nurit,

 

We will poll = one-by-one to ensure separation;-)

 

Deborah

 

From: Nurit Sprecher [mailto:nurit.sprecher@nsn.com]
Sent: Tuesday, January = 22, 2008 3:10 PM
To: BRUNGARD, DEBORAH A, = ATTLABS
Cc: = ccamp@ops.ietf.org
Subject: RE: Proposed WG = Draft - draft-gmpls-ethernet-arch-00.txt

Hi,

 =

I think that draft-gmpls-ethernet-arch-00.txt should be a WG = draft.

 =

In addition, the = authors of draft-fedyk-gmpls-ethernet-pbb-te-02.txt also proposed that their = draft is accepted as a WG draft. Naturally, I am in favor of this as well. Can we = ask feedback for this draft as well?

 =

Best = regards,

Nurit<= /span>

From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of ext BRUNGARD, DEBORAH = A, ATTLABS
Sent: Tuesday, January = 22, 2008 21:28
To: = ccamp@ops.ietf.org
Subject: Proposed WG = Draft - draft-gmpls-ethernet-arch-00.txt

 

CCAMP,

 

The DT proposed in their meeting = presentation for their architecture and framework document to be accepted as = a WG draft:

 

We received a couple of comments in the meeting, = we would appreciate additional feedback on the list. Please express = your support (or otherwise) for this I-D to become a WG = draft.

 

Thanks,

Deborah

------_=_NextPart_001_01C85D35.6195E455-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 22 Jan 2008 20:25:22 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C85D34.D26ACD5F" Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Date: Tue, 22 Jan 2008 14:24:42 -0600 Message-ID: <449B2580D802A443A923DABF3EAB82AF10132D87@OCCLUST04EVS1.ugd.att.com> Thread-Topic: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Thread-Index: AchdLOH3JrqySZgzQVuueGk7Nk+CoAABQxBwAACgXMA= From: "BRUNGARD, DEBORAH A, ATTLABS" To: "Nurit Sprecher" Cc: This is a multi-part message in MIME format. ------_=_NextPart_001_01C85D34.D26ACD5F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Nurit, =20 We will poll one-by-one to ensure separation;-) =20 Deborah ________________________________ From: Nurit Sprecher [mailto:nurit.sprecher@nsn.com]=20 Sent: Tuesday, January 22, 2008 3:10 PM To: BRUNGARD, DEBORAH A, ATTLABS Cc: ccamp@ops.ietf.org Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Hi, =20 I think that draft-gmpls-ethernet-arch-00.txt should be a WG draft. =20 In addition, the authors of draft-fedyk-gmpls-ethernet-pbb-te-02.txt also proposed that their draft is accepted as a WG draft. Naturally, I am in favor of this as well. Can we ask feedback for this draft as well? =20 Best regards, Nurit ________________________________ From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of ext BRUNGARD, DEBORAH A, ATTLABS Sent: Tuesday, January 22, 2008 21:28 To: ccamp@ops.ietf.org Subject: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt =20 CCAMP, =20 The DT proposed in their meeting presentation for their architecture and framework document to be accepted as a WG draft: http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt =20 We received a couple of comments in the meeting, we would appreciate additional feedback on the list. Please express your support (or otherwise) for this I-D to become a WG draft. =20 Thanks, Deborah ------_=_NextPart_001_01C85D34.D26ACD5F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Nurit,
 
We will poll one-by-one to ensure=20 separation;-)
 
Deborah

From: Nurit Sprecher=20 [mailto:nurit.sprecher@nsn.com]
Sent: Tuesday, January 22, = 2008 3:10=20 PM
To: BRUNGARD, DEBORAH A, ATTLABS
Cc:=20 ccamp@ops.ietf.org
Subject: RE: Proposed WG Draft -=20 draft-gmpls-ethernet-arch-00.txt

Hi,

 

I think that=20 draft-gmpls-ethernet-arch-00.txt should be a WG=20 draft.

 

In addition, = the=20 authors of draft-fedyk-gmpls-ethernet-pbb-te-02.txt also proposed that = their=20 draft is accepted as a WG draft. Naturally, I am in favor of this as = well. Can=20 we ask feedback for this draft as well?

 

Best=20 regards,

Nurit

From:=20 owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of ext BRUNGARD, = DEBORAH A,=20 ATTLABS
Sent: = Tuesday, January=20 22, 2008 21:28
To:=20 ccamp@ops.ietf.org
Subject:=20 Proposed WG Draft -=20 draft-gmpls-ethernet-arch-00.txt

 

CCAMP,

 

The DT proposed in their = meeting=20 presentation for their architecture and framework document to=20 be accepted as a WG draft:

http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt=

 

We received a couple of=20 comments in the meeting, we would appreciate additional = feedback on=20 the list. Please express your support (or otherwise) for this I-D to = become a WG=20 draft.

 

Thanks,

Deborah

------_=_NextPart_001_01C85D34.D26ACD5F-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 22 Jan 2008 20:10:36 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C85D32.BA8099CD" Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Date: Tue, 22 Jan 2008 22:09:37 +0200 Message-ID: Thread-Topic: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Thread-Index: AchdLOH3JrqySZgzQVuueGk7Nk+CoAABQxBw From: "Nurit Sprecher" To: "ext BRUNGARD, DEBORAH A, ATTLABS" Cc: This is a multi-part message in MIME format. ------_=_NextPart_001_01C85D32.BA8099CD Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 I think that draft-gmpls-ethernet-arch-00.txt should be a WG draft. =20 In addition, the authors of draft-fedyk-gmpls-ethernet-pbb-te-02.txt also proposed that their draft is accepted as a WG draft. Naturally, I am in favor of this as well. Can we ask feedback for this draft as well? =20 Best regards, Nurit ________________________________ From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of ext BRUNGARD, DEBORAH A, ATTLABS Sent: Tuesday, January 22, 2008 21:28 To: ccamp@ops.ietf.org Subject: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt =20 CCAMP, =20 The DT proposed in their meeting presentation for their architecture and framework document to be accepted as a WG draft: http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt =20 We received a couple of comments in the meeting, we would appreciate additional feedback on the list. Please express your support (or otherwise) for this I-D to become a WG draft. =20 Thanks, Deborah ------_=_NextPart_001_01C85D32.BA8099CD Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 =

I think that draft-gmpls-ethernet-arch-00.txt should be a WG = draft.

 =

In addition, the = authors of draft-fedyk-gmpls-ethernet-pbb-te-02.txt also proposed that their = draft is accepted as a WG draft. Naturally, I am in favor of this as well. Can we = ask feedback for this draft as well?

 =

Best = regards,

Nurit<= /span>

From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of ext BRUNGARD, DEBORAH = A, ATTLABS
Sent: Tuesday, January = 22, 2008 21:28
To: = ccamp@ops.ietf.org
Subject: Proposed WG = Draft - draft-gmpls-ethernet-arch-00.txt

 

CCAMP,

 

The DT proposed in their meeting = presentation for their architecture and framework document to be accepted as = a WG draft:

 

We received a couple of comments in the meeting, = we would appreciate additional feedback on the list. Please express = your support (or otherwise) for this I-D to become a WG = draft.

 

Thanks,

Deborah

------_=_NextPart_001_01C85D32.BA8099CD-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 22 Jan 2008 19:30:36 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C85D2C.E28C7353" Subject: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Date: Tue, 22 Jan 2008 13:27:53 -0600 Message-ID: <449B2580D802A443A923DABF3EAB82AF10132C78@OCCLUST04EVS1.ugd.att.com> Thread-Topic: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt Thread-Index: AchdLOH3JrqySZgzQVuueGk7Nk+CoA== From: "BRUNGARD, DEBORAH A, ATTLABS" To: This is a multi-part message in MIME format. ------_=_NextPart_001_01C85D2C.E28C7353 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable CCAMP, =20 The DT proposed in their meeting presentation for their architecture and framework document to be accepted as a WG draft: http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt =20 We received a couple of comments in the meeting, we would appreciate additional feedback on the list. Please express your support (or otherwise) for this I-D to become a WG draft. =20 Thanks, Deborah ------_=_NextPart_001_01C85D2C.E28C7353 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
CCAMP,
 
The DT = proposed in=20 their meeting presentation for their architecture and framework=20 document to be accepted as a WG = draft:
http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt=
 
We = received a couple=20 of comments in the meeting, we would appreciate additional = feedback on=20 the list. Please express your support (or otherwise) for this I-D to = become a WG=20 draft.
 
Thanks,
Deborah
------_=_NextPart_001_01C85D2C.E28C7353-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 18 Jan 2008 21:39:49 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: FW: Internet-Drafts Submission Cutoff Dates for the 71st IETF Meeting in Philadelphia, PA, USA Date: Fri, 18 Jan 2008 15:37:04 -0600 Message-ID: <449B2580D802A443A923DABF3EAB82AF100C23FE@OCCLUST04EVS1.ugd.att.com> Thread-Topic: Internet-Drafts Submission Cutoff Dates for the 71st IETF Meeting in Philadelphia, PA, USA Thread-Index: AchZj3z1Jh0Sq67wRFC4lRiYhD6W4gAipcIw From: "BRUNGARD, DEBORAH A, ATTLABS" To: FYI - dates for submitting drafts. -----Original Message----- From: ietf-secretariat@ietf.org [mailto:ietf-secretariat@ietf.org]=20 Sent: Friday, January 18, 2008 12:00 AM To: ietf-announce@ietf.org Subject: Internet-Drafts Submission Cutoff Dates for the 71st IETF Meeting in Philadelphia, PA, USA=20 There are two (2) Internet-Draft cutoff dates for the 71st=20 IETF Meeting in Philadelphia, PA, USA: February 18th: Cutoff Date for Initial (i.e., version -00)=20 Internet-Draft Submissions=20 All initial Internet-Drafts (version -00) must be submitted by Monday,=20 February 18th at 9:00 AM ET (14:00 UTC/GMT).The only exception is for version -00 WG drafts that replace existing non-WG drafts. Such drafts may be submitted until the cutoff date for version -01 and higher drafts. As always, all initial submissions with a filename beginning with=20 "draft-ietf" must be approved by the appropriate WG Chair before they=20 can be processed or announced. The Secretariat would appreciate=20 receiving WG Chair approval by Monday, February 11th at 9:00 AM ET (14:00 UTC/GMT). February (14:00 UTC/GMT): Cutoff Date for Revised (i.e., version -01 and higher)=20 Internet-Draft Submissions=20 All revised Internet-Drafts (version -01 and higher) must be submitted=20 by Monday, February 25th at 9:00 AM ET (14:00 UTC/GMT). Initial and revised Internet-Drafts received after their respective=20 cutoff dates will not be made available in the Internet-Drafts=20 directory or announced until on or after Monday, March 10th at 9:00=20 AM ET (13:00 UTC/GMT), when Internet-Draft posting resumes. Please do not wait until=20 the last minute to submit. The Secretariat encourages you to submit your Internet-Drafts via the=20 Internet-Draft Submission Tool (IDST) https://datatracker.ietf.org/idst/upload.cgi.=20 If you are unable to do so, then you may still submit your Internet- Drafts manually by sending them to internet-drafts@ietf.org. If you=20 are submitting a version -00 WG draft that replaces non-WG draft, then=20 you must submit it manually as the current IDST cannot handle=20 replacements. Please be sure to state that one draft replaces another=20 in the cover note that accompanies your submission. Also, please note=20 that the IDST will not accept drafts submitted after their respective=20 cutoff dates. Thank you for your understanding and cooperation. If you have any=20 questions or concerns, then please send a message to=20 internet-drafts@ietf.org. The IETF Secretariat FYI: The Internet-Draft cutoff dates as well as other significant dates for the 71st IETF Meeting can be found at http://www.ietf.org/meetings/71-cutoff_dates.html. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 17 Jan 2008 22:03:10 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C85954.5B0F5017" Subject: Draft Liaison Response "Response to Liaison on GMPLS Signaling for VCAT/LCAS" Date: Thu, 17 Jan 2008 16:00:20 -0600 Message-ID: <449B2580D802A443A923DABF3EAB82AF100C1B8A@OCCLUST04EVS1.ugd.att.com> Thread-Topic: Draft Liaison Response "Response to Liaison on GMPLS Signaling for VCAT/LCAS" Thread-Index: AchZVFowqiu/zB1tTPaCDHj9ua2p4w== From: "BRUNGARD, DEBORAH A, ATTLABS" To: Cc: "Adrian Farrel" , "Ross Callon" , "David Ward" This is a multi-part message in MIME format. ------_=_NextPart_001_01C85954.5B0F5017 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable CCAMP, Here's a proposed response to ITU's Liaison: https://datatracker.ietf.org/liaison/371/ Any comments? Thanks, Deborah and Adrian =3D=3D=3D=3D Title: Response to Liaison on GMPLS Signaling for VCAT/LCAS Purpose: For Action Body: The CCAMP Working Group thanks you for your liaison of September 2007 (Q12-14 Interim meeting - LS 005). Here are our responses to the questions in your liaison: Your Question 1: We provide here further clarification regarding our previous comment re protocol extensibility to encompass technologies other than SONET/SDH. An example technology of interest to the community was provided regarding the usage of virtually concatenated ODUs for carriage of IEEE 802.3 HSSG proposed 100 Gbit/s over an existing OTN infrastructure. How this is accomplished is not defined at this time and might not be using VCAT. A technology neutral approach (i.e., one not dependent upon VCAT over SONET/SDH-unique parameters) would avoid the need for developing a series of specialized solutions. Our response: As we noted previously, it is certainly our intention that functionality and any protocol extensions that we develop should be easily extensible to support other than SONET/SDH technology, especially technologies covered by GMPLS (e.g. OTN). This is the basis of GMPLS and GMPLS call functionality development. If you have identified any specific concerns with the current approach, we would appreciate your input. Your Question 2: VCAT group signaling relates closely to multi-layer call modeling, and it is our understanding that the draft is only addressing the constituent server layer call. We plan to perform further work to clarify the interlayer call relationship in terms of the ASON multilayer "call supporting call construct". Our response: Noted. We look forward to further communication from you. Your Question 3: We agree that connections are not moved between calls; the ASON "call supporting calls" construct is consistent with not moving connections between calls. Rec. G.7041 and G.7042 are only concerned with membership of the VCAT group, and not with the use of a member that has been removed (it is assumed to simply go back into the pool of resources, where it can be drawn upon for other purposes). Thus G.7041 and G.7042 do not support the direct movement of a connection from one VCAT group to another. Changing the association of a server layer call/connection to a VCAT group does not necessarily result in removal/deletion of that call/connection. Our response: Noted. Your Question 4: We appreciate your clarification of the use of a single call. However we suggest that you do not preclude extension to use multiple calls. This is useful for example in diverse routing applications. Our response: As noted in our previous liaison, the call construct as proposed in this draft is used to coordinate the (single type) server layer connections for the VCAT functionality. This does not preclude use of RFC 4974 in support of G.8080 call functionality. To ensure that we understand correctly your request, can you provide additional information regarding using multiple calls in support of diverse routing applications? Your Question 5: We understand that this draft is only addressing the constituent server layer call; i.e., not the ASON multilayer call supporting call construct. However, we suggest that you do not preclude extensions to use a call in the VCAT layer. Our response: As noted above, this is not precluded. We look forward to future communication from you as you progress this work. Your Question 6: We understand that GMPLS only supports the IP address format, and that the actual addresses may be different in each layer. We believe it would be useful to clarify the difference between addresses used in regards to delivering messages to a control component, and identifiers used for the forwarding plane resources themselves. Our response: Please refer to RFC 4990. This draft does not modify existing procedures. If you have any questions with regard to GMPLS addressing, we welcome informal dialogue on the CCAMP exploder and, of course, you may also ask via Liaison. Your Question 7: Thank you for the clarification which confirms that the VCAT layer Call Controllers are assumed to be adjacent from a control plane perspective. Our response: Noted. To ensure that we understand your question on "direct signalling connectivity" and "adjacent", to be precise, it is assumed that the Call Controllers can exchange call control messages. This does not require that they be adjacent. Your Question 8: Thank you for the clarification. Our response: Noted. Your Question 9: Based upon your observation, we view that a protocol independent definition of the call ID should be abstracted from G.7713.2, where it is expressed in protocol specific terms; the most appropriate Recommendation for this definition would be G.7713. Our response: Thank you for the clarification. Your Question 10: Your interpretation of G.8080 is correct regarding E-NNI reference points and adjacent call controllers. There is no reference to RSVP sessions in G.8080; it was used as an example of the consequence of using different protocols in different domains. It is our understanding from the discussions that concatenated GMPLS RSVP-TE connections (homogenous signaling protocol) that are part of the same end-to-end network connection do not need to change the session object, and policy could be applied at a transit (inter-domain) hop. Please confirm that our understanding is correct. Our response: Your understanding is correct that even though one session is used, policy may be applied by any processing node (manager) of the call message, and RFC4974 supports multiple call managers along the path between ingress and egress. Please refer to RFC 4974. Note, the RSVP signaling protocol model allows for the application of local policy by any processing node of the request (regardless if a connection or call). The latest version of this work can be found at: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-vcat-lcas-03. txt We welcome any further comments. Best regards, Adrian Farrel and Deborah Brungard IETF CCAMP working group co-chairs Attachment(s): No document has been attached =20 ------_=_NextPart_001_01C85954.5B0F5017 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

CCAMP,

Here's a proposed=20 response to ITU's Liaison:

https://datatracker.ie= tf.org/liaison/371/

Any=20 comments?

Thanks,

Deborah and=20 Adrian

=3D=3D=3D=3D

Title: Response to Liaison on GMPLS Signaling for=20 VCAT/LCAS

Purpose: For Action

Body:

The = CCAMP Working=20 Group thanks you for your liaison of September 2007 (Q12-14 Interim = meeting - LS=20 005).

Here = are our=20 responses to the questions in your liaison:

Your=20 Question 1: We=20 provide here further clarification regarding our previous comment re = protocol=20 extensibility to encompass technologies other than SONET/SDH.  An example technology of = interest to the=20 community was provided regarding the usage of virtually concatenated = ODUs for=20 carriage of IEEE 802.3 HSSG proposed 100 Gbit/s over an existing OTN=20 infrastructure.  How this = is=20 accomplished is not defined at this time and might not be using VCAT. A=20 technology neutral approach (i.e., one not dependent upon VCAT over=20 SONET/SDH-unique parameters) would avoid the need for developing a = series of=20 specialized solutions.

Our = response: As we=20 noted previously, it is certainly our intention that functionality and = any=20 protocol extensions that we develop should be easily extensible to = support other=20 than SONET/SDH technology, especially technologies covered by GMPLS = (e.g. OTN).=20 This is the basis of GMPLS and GMPLS call functionality development. If = you have=20 identified any specific concerns with the current approach, we would = appreciate=20 your input.

Your Question=20 2:  VCAT group signaling = relates=20 closely to multi-layer call modeling, and it is our understanding that = the draft=20 is only addressing the constituent server layer call.   We plan to perform = further work to=20 clarify the interlayer call relationship in terms of the ASON multilayer = “call=20 supporting call construct”.

Our=20 response: Noted. We look forward to further communication from=20 you.

Your=20 Question 3:   We = agree that=20 connections are not moved between calls; the ASON “call supporting = calls”=20 construct is consistent with not moving connections between calls.  Rec. G.7041 and G.7042 are = only=20 concerned with membership of the VCAT group, and not with the use of a = member=20 that has been removed (it is assumed to simply go back into the pool of=20 resources, where it can be drawn upon for other purposes).  Thus G.7041 and G.7042 do not = support=20 the direct movement of a connection from one VCAT group to another. = Changing the=20 association of a server layer call/connection to a VCAT group does not=20 necessarily result in removal/deletion of that=20 call/connection.

Our=20 response: Noted.

Your Question=20 4:  We appreciate your = clarification=20 of the use of a single call. However we suggest that you do not preclude = extension to use multiple calls. This is useful for example in diverse = routing=20 applications.

=

Our=20 response: As=20 noted in our previous liaison, the call construct as proposed in this = draft is=20 used to coordinate the (single type) server layer connections for the = VCAT=20 functionality. This does not preclude use of RFC 4974 in support of = G.8080 call=20 functionality. To ensure that we understand correctly your request, can = you=20 provide additional information regarding using multiple calls in support = of=20 diverse routing=20 applications?

Your Question=20 5:  We understand that = this draft is=20 only addressing the constituent server layer call; i.e., not the ASON = multilayer=20 call supporting call construct. However, we suggest that you do not = preclude=20 extensions to use a call in the VCAT=20 layer.

Our=20 response: As noted above, this is not precluded. We look forward to = future=20 communication from you as you progress this=20 work.

Your Question=20 6:  We understand that = GMPLS only=20 supports the IP address format, and that the actual addresses may be = different=20 in each layer.  We believe = it would=20 be useful to clarify the difference between addresses used in regards to = delivering messages to a control component, and identifiers used for the = forwarding plane resources=20 themselves.

Our=20 response: Please=20 refer to RFC 4990. This draft does not modify existing procedures. If = you have=20 any questions with regard to GMPLS addressing, we welcome informal = dialogue on=20 the CCAMP exploder and, of course, you may also ask via=20 Liaison.

Your=20 Question=20 7:  Thank you for the = clarification=20 which confirms that the VCAT layer Call Controllers are assumed to be = adjacent=20 from a control plane=20 perspective.

Our=20 response: Noted. To ensure that we understand your question on "direct=20 signalling connectivity" and "adjacent", to be precise, it is assumed = that the=20 Call Controllers can exchange call control messages. This does not = require that=20 they be=20 adjacent.<= /SPAN>

Your=20 Question=20 8:  Thank you for the=20 clarification.

Our=20 response:=20 Noted.

Your=20 Question=20 9:  Based upon your = observation, we=20 view that a protocol independent definition of the call ID should be = abstracted=20 from G.7713.2, where it is expressed in protocol specific terms; the = most=20 appropriate Recommendation for this definition would be=20 G.7713.

Our=20 response: Thank you for the=20 clarification.

Your=20 Question=20 10:  Your interpretation = of G.8080=20 is correct regarding E-NNI reference points and adjacent call = controllers.  There is no reference to RSVP = sessions=20 in G.8080; it was used as an example of the consequence of using = different=20 protocols in different domains.  = It=20 is our understanding from the discussions that concatenated GMPLS = RSVP-TE=20 connections (homogenous signaling protocol) that are part of the same = end-to-end=20 network connection do not need to change the session object, and policy = could be=20 applied at a transit (inter-domain) hop.  Please confirm that our = understanding is=20 correct.

Our=20 response: Your=20 understanding is correct that even though one session is used, policy = may be=20 applied by any processing node (manager) of the call message, = and=20 RFC4974 supports multiple call managers along the path between ingress = and=20 egress. Please refer to RFC 4974. Note, the RSVP signaling protocol = model allows=20 for the application of local policy by any processing node of the=20 request (regardless if a connection or=20 call).

The latest = version of this=20 work can be found at:

http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-vc= at-lcas-03.txt

We = welcome any=20 further comments.

Best regards,

Adrian Farrel and=20 Deborah Brungard

IETF CCAMP=20 working group co-chairs

Attachment(s):=20 No document has been attached

 

 ------_=_NextPart_001_01C85954.5B0F5017-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 17 Jan 2008 19:32:09 +0000 From: The IESG To: IETF-Announce Cc: Internet Architecture Board , RFC Editor , ccamp mailing list , ccamp chair Subject: Document Action: 'Interworking Requirements to Support operation of MPLS-TE over GMPLS Networks' to Informational RFC Message-Id: Date: Thu, 17 Jan 2008 14:30:41 -0500 The IESG has approved the following document: - 'Interworking Requirements to Support operation of MPLS-TE over GMPLS Networks ' as an Informational RFC This document is the product of the Common Control and Measurement Plane Working Group. The IESG contact persons are Ross Callon and David Ward. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-mpls-gmpls-interwork-reqts-04.txt Technical Summary This informational document describes Service Provider requirements for operating MPLS-TE networks over GMPLS networks. Working Group Summary No dissent reported (see PROTO writeup by Adrian Farrel). Protocol Quality Ross Callon has reviewed this document for the IESG, and it has been updated based on my (mostly minor clarifying) comments. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 17 Jan 2008 17:18: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: Moving forward with VCAT/LCAS... Date: Thu, 17 Jan 2008 12:17:59 -0500 Message-ID: <29D15BBCA340DA4D8146D38B4924FC7A10E4E010@zcarhxm0.corp.nortel.com> Thread-Topic: Moving forward with VCAT/LCAS... Thread-Index: AchW6HpMEE3z8pLDR6uJiaS5bLNJLwCQ7yHQ From: "Stephen Shew" To: Alex, I assume that the "one step" case below is simply an optimization of the "loose coupling + policy" approach. That is, the policy is to teardown the server when the client no longer needs it. I think it would be a mistake to define this behaviour in a protocol without the ability to control whether the server layer is torn down when its association with the client layer is removed. Stephen -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Alex Conta Sent: January 14, 2008 14:47 To: ccamp@ops.ietf.org Subject: RE: Moving forward with VCAT/LCAS... Greg, =20 >From the perspective of the "users" of a VCG - applications or clients of the VCG which are the layers above the VCG (above both VCG client and server). - the awareness, the information about the VCG members, and furthermore, their presence before, or after VCG creation or tear down, does not really seem relevant, or directly useful.=20 =20 >From a "management/provisioning" perspective, setting up the components, independently from the client layer - as a first setup step - and then converting/transforming these elements into VCG members, once a VCG group (and client) has been set up - as a second setup step - and then at tear down, after VCGs tear down, keeping the server elements around, seem to be reducing the number of subsequent setup operations, if those elements can be and are reused with subsequent newly created VCGs. =20 It can be argued though, that in a case - a VCG application - in which existing server elements CANNOT be reused, a one step creation or tearing down of VCGs - in which client and server elements are created/setup, or torn down together, instead of a two step, and keeping server layer elements around - is more appropriate.=20 =20 So the preferred "default" behavior may depend on the type of VCG applications, and could be best left as a choice for the system developer to make.=20 =20 Regards, Alex Conta =20 -----Original Message----- From: Greg Bernstein [mailto:gregb@grotto-networking.com] Sent: Friday, January 11, 2008 11:03 AM To: Alex Conta Subject: Re: Moving forward with VCAT/LCAS... Nice analysis/summary Alex. I like the "looser coupling" + policy (default behavior) approach that you put forward. Let me know if you've got solution preferences (on or off the list). Regards Greg B. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 17 Jan 2008 17:13:06 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Moving forward with VCAT/LCAS... Date: Thu, 17 Jan 2008 12:08:15 -0500 Message-ID: <29D15BBCA340DA4D8146D38B4924FC7A10E4DFDD@zcarhxm0.corp.nortel.com> Thread-Topic: Moving forward with VCAT/LCAS... Thread-Index: AchT/D3n1O6MvMXwQymz43Q3TU1u/QFLk2cQ From: "Stephen Shew" To: Sorry about the delay in responding, I don't check this list daily. A connection can't exist outside of a call. However, if you mean can a server call (with associated connection) exist outside of a client (in this case VCAT) call, the answer is yes. The model I'm responding from assumes that a VCAT call contains only one VCG, and that it has a relationship with one or more server layer calls where those server layer calls contain a connection or connections. It's a more general model for inverse mux. The server layer call could exist ahead of time, and then be allocated to a client call. The client could also disassociate itself from a server layer call and it is an independent decision as to whether that server layer call then releases its connection(s) and terminates. If it stays up, it could be associated with a different client call at a later time. Stephen -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel Sent: January 10, 2008 21:34 To: ccamp@ops.ietf.org Subject: Re: Moving forward with VCAT/LCAS... Stephen, In this architecture, can a connection exist outside a call and then be designated as a connection that fulfils the service identified by the call? Thanks, Adrian ----- Original Message ----- From: "Stephen Shew" To: Sent: Thursday, January 10, 2008 3:04 PM Subject: RE: Moving forward with VCAT/LCAS... Greg, I support these requirements. In transport architecture, layers are separated and this allows a business separation of service. The relationship between the client layer (VCAT in this case) and server layer should be policy driven. That is, the setup/teardown of server layer LSPs in response to client layer requests, should not be automatically coded in a protocol/implementation, but be subject to a policy decision. An additional requirement that's similar to (a), would be to be able to use an existing LSP in response to a VCAT setup. Stephen -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Greg Bernstein Sent: January 8, 2008 12:28 To: ccamp@ops.ietf.org Subject: Moving forward with VCAT/LCAS... Hi CCAMPers, at the Vancouver meeting the status of the VCAT/LCAS draft was discussed and there seemed to be two possible additions to the requirements section of the draft. From the slide presentation these were: (a) Be able to set up member LSPs (and data plane LSPs -- server connections) prior to creation of VCG (Virtual Concatenation Group). (b) "Member" LSPs (data plane and control plane) can exist after a VCG using them has been removed. For those interested in VCAT/LCAS what is your opinion on these additional requirements? This is a WG draft so polling of the list is required (right Adrian?). I'll clean up the language if there is a desire to add these to the current draft. Note that these requirements may break or require rework of the current "multiple co-signaled member sets" solution in the draft. Regards Greg B. -- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=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 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 15 Jan 2008 02:35:45 +0000 From: The IESG To: IETF-Announce Cc: Internet Architecture Board , RFC Editor , ccamp mailing list , ccamp chair Subject: Document Action: 'Framework for MPLS-TE to GMPLS migration' to Informational RFC Message-Id: Date: Mon, 14 Jan 2008 21:32:55 -0500 The IESG has approved the following document: - 'Framework for MPLS-TE to GMPLS migration ' as an Informational RFC This document is the product of the Common Control and Measurement Plane Working Group. The IESG contact persons are Ross Callon and David Ward. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-05.txt Technical Summary This informational framework document presents several migration models and strategies for migrating from MPLS-TE to GMPLS. This document provides a migration toolkit to aid the operator in selection of an appropriate strategy. This framework document also lists a set of solutions that may aid in interworking, and highlights a set of potential issues. Working Group Summary No dissent reported (see PROTO writeup by Adrian Farrel) Protocol Quality Ross Callon has reviewed this for the IESG. As this informational document just describes possibilities for migration, it is not implemented per se. Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 14 Jan 2008 19:49:22 +0000 Date: Mon, 14 Jan 2008 14:47:26 -0500 From: Alex Conta Subject: RE: Moving forward with VCAT/LCAS... To: ccamp@ops.ietf.org Message-id: <005901c856e6$4a9429f0$6501a8c0@alnostro> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Greg, >From the perspective of the "users" of a VCG - applications or clients of the VCG which are the layers above the VCG (above both VCG client and server). - the awareness, the information about the VCG members, and furthermore, their presence before, or after VCG creation or tear down, does not really seem relevant, or directly useful. >From a "management/provisioning" perspective, setting up the components, independently from the client layer - as a first setup step - and then converting/transforming these elements into VCG members, once a VCG group (and client) has been set up - as a second setup step - and then at tear down, after VCGs tear down, keeping the server elements around, seem to be reducing the number of subsequent setup operations, if those elements can be and are reused with subsequent newly created VCGs. It can be argued though, that in a case - a VCG application - in which existing server elements CANNOT be reused, a one step creation or tearing down of VCGs - in which client and server elements are created/setup, or torn down together, instead of a two step, and keeping server layer elements around - is more appropriate. So the preferred "default" behavior may depend on the type of VCG applications, and could be best left as a choice for the system developer to make. Regards, Alex Conta -----Original Message----- From: Greg Bernstein [mailto:gregb@grotto-networking.com] Sent: Friday, January 11, 2008 11:03 AM To: Alex Conta Subject: Re: Moving forward with VCAT/LCAS... Nice analysis/summary Alex. I like the "looser coupling" + policy (default behavior) approach that you put forward. Let me know if you've got solution preferences (on or off the list). Regards Greg B. Alex Conta wrote: Supporting the two requirements makes sense. A VCG member (server) has some basic functionality that is similar to non-VCG members, and the mechanisms to setup that functionality is usually similar/same (for instance, setting up the DS3 functionality of the DS3 members of a VCG is similar to setting up non-VCG DS3s.) Transforming a non-VCG member into a VCG member, and vice-versa, a VCG member into a non-VCG member, is just a matter of additional setup - VCG setup (through management, control plane, policy driver, etc...) An implication of the support of these two requirements seems to be a choice of behavior of the implementation of the VCG tear down functions. 1. provide the function of terminating all functions and tearing down all VCG members (servers) at the time of tearing down their VCG (client). 2. provide the function of terminating only the "VCG member" functions, transforming VCG members into non-VCG members, and thus have the non-VCG functionality of the server layer entities survive the tear down of the VCG (client). An implementation may have a choice of "default behavior", which could be mentioned in the draft. Regards, Alex Conta -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Greg Bernstein Sent: Tuesday, January 08, 2008 12:28 PM To: ccamp@ops.ietf.org Subject: Moving forward with VCAT/LCAS... Hi CCAMPers, at the Vancouver meeting the status of the VCAT/LCAS draft was discussed and there seemed to be two possible additions to the requirements section of the draft. From the slide presentation these were: (a) Be able to set up member LSPs (and data plane LSPs -- server connections) prior to creation of VCG (Virtual Concatenation Group). (b) "Member" LSPs (data plane and control plane) can exist after a VCG using them has been removed. For those interested in VCAT/LCAS what is your opinion on these additional requirements? This is a WG draft so polling of the list is required (right Adrian?). I'll clean up the language if there is a desire to add these to the current draft. Note that these requirements may break or require rework of the current "multiple co-signaled member sets" solution in the draft. Regards Greg B. -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 14 Jan 2008 16:16:42 +0000 Date: Mon, 14 Jan 2008 11:14:26 -0500 From: Alex Conta Subject: RE: Moving forward with VCAT/LCAS... To: ccamp@ops.ietf.org Message-id: <004101c856c8$89e0acf0$6501a8c0@alnostro> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Supporting the two requirements makes sense. A VCG member (server) has some basic functionality that is similar to non-VCG members, and the mechanisms to setup that functionality is usually similar/same (for instance, setting up the DS3 functionality of the DS3 members of a VCG is similar to setting up non-VCG DS3s.) Transforming a non-VCG member into a VCG member, and vice-versa, a VCG member into a non-VCG member, is just a matter of additional setup - VCG setup (through management, control plane, policy driver, etc...) An implication of the support of these two requirements seems to be a choice of behavior of the implementation of the VCG tear down functions. 1. provide the function of terminating all functions and tearing down all VCG members (servers) at the time of tearing down their VCG (client). 2. provide the function of terminating only the "VCG member" functions, transforming VCG members into non-VCG members, and thus have the non-VCG functionality of the server layer entities survive the tear down of the VCG (client). An implementation may have a choice of "default behavior", which could be mentioned in the draft. Regards, Alex Conta Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 13 Jan 2008 17:19:24 +0000 Message-ID: <053801c85608$35d30c90$0200a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "Ross Callon" , , "Ronald Bonica" , "Kenji Kumaki" , "Brungard, Deborah A, ALABS" Subject: draft-ietf-ccamp-mpls-gmpls-interwork-reqts revised after IESG review Date: Sun, 13 Jan 2008 17:17:41 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit The new revision of this I-D is to address comments made during IESG review as below. Thanks, Adrian === Section 3 New paragraph at end of section ADD The functional requirements for GMPLS-MPLS interworking described in this section must be met by any device participating in the interworking. This may include routers, servers, network management devices, path computation elements, etc. === Section 3.2 New paragraphs at end of section ADD Note that multiple GMPLS LSPs may be set up between a given pair of Border Routers in support of connectivity in the MPLS client network. If these LSPs are advertised as TE links in the client network, the use of link bundling [RFC4201] can reduce any scaling concerns associated with the advertisements. The application of the Path Computation Element (PCE) [RFC4655] in the context of an inter-layer network [PCE-INTER-LAYER] may be considered to determine an end-to-end LSP with triggered GMPLS segment or tunnel. === Section 3.5 New paragraph at end of section ADD The use of PCE [RFC4655] may provide a solution for non-PSC GMPLS networks supporting PSC MPLS networks. === Section 8.1 ADD [RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling in MPLS Traffic Engineering (TE)", RFC 4201, October 2005. === Section 8.2 ADD [RFC4655] A. Farrel, JP. Vasseur and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006. Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 13 Jan 2008 16:12:52 +0000 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D Action:draft-ietf-ccamp-mpls-gmpls-interwork-reqts-04.txt Message-Id: Date: Sun, 13 Jan 2008 11:10:01 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Interworking Requirements to Support operation of MPLS-TE over GMPLS Networks Author(s) : K. Kumaki, et al. Filename : draft-ietf-ccamp-mpls-gmpls-interwork-reqts-04.txt Pages : 13 Date : 2008-01-13 Operation of a Multiprotocol Label Switching (MPLS) traffic engineering (TE) network as a client network to a Generalized MPLS (GMPLS) network has enhanced operational capabilities compared to those provided by a co-existent protocol model (i.e., operation of MPLS-TE over an independently managed transport layer). The GMPLS network may be a packet or a non-packet network, and may itself be a multi-layer network supporting both packet and non-packet technologies. A MPLS-TE Label Switched Path (LSP) originates and terminates on an MPLS Label Switching Router (LSR). The GMPLS network provides transparent transport for the end-to-end MPLS-TE LSP. This document describes a framework and Service Provider requirements for operating MPLS-TE networks over GMPLS networks. K.Kumaki et al. [page 1] draft-ietf-ccamp-mpls-gmpls-interwork-reqts-04 January 2008 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-mpls-gmpls-interwork-reqts-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-mpls-gmpls-interwork-reqts-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-mpls-gmpls-interwork-reqts-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2008-01-13110353.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-mpls-gmpls-interwork-reqts-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-mpls-gmpls-interwork-reqts-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-01-13110353.I-D\@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 13 Jan 2008 11:26:27 +0000 Message-ID: <04ea01c855d7$0b510d90$0200a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "Ross Callon" , , , "Kohei Shiomoto" , "Brungard, Deborah A, ALABS" Subject: draft-ietf-ccamp-mpls-gmple-framework updated after IESG review Date: Sun, 13 Jan 2008 11:25:43 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Hi, Changes are below (as approved by the IESG). Thanks, Adrian == Section 4.3 Replace final paragraph OLD Interoperability concerns, though, are exacerbated by this migration model, unless all LSRs in the network are updated simultaneously and there is a clear understanding of which subset of features are to be included in the hybrid LSRs. Interworking between a hybrid LSR and an unchanged MPLS LSR would put the hybrid LSR in the role of a GMPLS LSR as described in the previous sections and puts the unchanged LSR in the role of an MPLS LSR. The potential for different hybrids within the network will complicate matters considerably. NEW Interoperability concerns though are exacerbated by this migration model, unless all LSRs in the network are updated simultaneously and there is a clear understanding of which subset of features are to be included in the hybrid LSRs. Interworking between a hybrid LSR and an unchanged MPLS LSR would put the hybrid LSR in the role of a GMPLS LSR as described in the previous sections and puts the unchanged LSR in the role of an MPLS LSR. The potential for different hybrids within the network will complicate matters considerably. This model is, therefore, only appropriate for use when the set of new features to be deployed is well known and limited, and where there is a clear understanding of and agreement on this set of features by the network operators of the ISP(s) involved as well as all vendors whose equipment will be involved in the migration. === Section 5 Update 4th paragraph OLD The second strategy for PSC and non-PSC networks is to migrate from the PSC network to GMPLS, first, and then enable GMPLS within the non-PSC network. The PSC network is migrated as described before, and when the entire PSC network is completely converted to GMPLS, GMPLS- based non-PSC devices and networks may be introduced without any issues of interworking between MPLS and GMPLS. NEW The second strategy is to migrate the PSC network to GMPLS first, and then enable GMPLS within the non-PSC network. The PSC network is migrated as described before, and when the entire PSC network is completely converted to GMPLS, GMPLS-based non-PSC devices and networks may be introduced without any issues of interworking between MPLS and GMPLS. === Section 5.1.4 New section ADD 5.1.4. Path Computation Element The Path Computation Element (PCE) [RFC4655] may provide an additional tool to aid MPLS to GMPLS migration. If a layered network approach (Section 5.1.1) is used, PCEs may be used to facilitate the computation of paths for LSPs in the different layers [PCE-INTER-LAYER]. === Section 12.2 Add new references ADD [RFC4655] A. Farrel, JP. Vasseur and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006. [PCE-INTER-LAYER] Oki, E., Le Roux , J-L,. and Farrel, A., "Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic Engineering," draft-ietf-pce-inter-layer-frwk, work in progress. === Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 13 Jan 2008 11:23:29 +0000 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D Action:draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-05.txt Message-Id: Date: Sun, 13 Jan 2008 06:20:02 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Framework for MPLS-TE to GMPLS migration Author(s) : K. Shiomoto, et al. Filename : draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-05.txt Pages : 19 Date : 2008-01-13 The migration from Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) to Generalized MPLS (GMPLS) is the process of evolving an MPLS-TE control plane to a GMPLS control plane. An appropriate migration strategy will be selected based on various factors including the service provider's network deployment plan, customer demand, and operational policy. This document presents several migration models and strategies for migrating from MPLS-TE to GMPLS. In the course of migration, MPLS-TE and GMPLS devices, or networks, may coexist which may require interworking between MPLS-TE and GMPLS protocols. Aspects of the interworking required are discussed as it will influence the choice of a migration strategy. This framework document provides a migration toolkit to aid the operator in selection of an appropriate strategy. This framework document also lists a set of solutions that may aid in interworking, and highlights a set of potential issues. Shiomoto et al. [page 1] draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-05 January 2008 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2008-01-13061248.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-01-13061248.I-D\@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 11 Jan 2008 02:35:31 +0000 Message-ID: <015301c853fa$6174c0b0$0200a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Re: Moving forward with VCAT/LCAS... Date: Fri, 11 Jan 2008 02:33:39 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Stephen, In this architecture, can a connection exist outside a call and then be designated as a connection that fulfils the service identified by the call? Thanks, Adrian ----- Original Message ----- From: "Stephen Shew" To: Sent: Thursday, January 10, 2008 3:04 PM Subject: RE: Moving forward with VCAT/LCAS... Greg, I support these requirements. In transport architecture, layers are separated and this allows a business separation of service. The relationship between the client layer (VCAT in this case) and server layer should be policy driven. That is, the setup/teardown of server layer LSPs in response to client layer requests, should not be automatically coded in a protocol/implementation, but be subject to a policy decision. An additional requirement that's similar to (a), would be to be able to use an existing LSP in response to a VCAT setup. Stephen -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Greg Bernstein Sent: January 8, 2008 12:28 To: ccamp@ops.ietf.org Subject: Moving forward with VCAT/LCAS... Hi CCAMPers, at the Vancouver meeting the status of the VCAT/LCAS draft was discussed and there seemed to be two possible additions to the requirements section of the draft. From the slide presentation these were: (a) Be able to set up member LSPs (and data plane LSPs -- server connections) prior to creation of VCG (Virtual Concatenation Group). (b) "Member" LSPs (data plane and control plane) can exist after a VCG using them has been removed. For those interested in VCAT/LCAS what is your opinion on these additional requirements? This is a WG draft so polling of the list is required (right Adrian?). I'll clean up the language if there is a desire to add these to the current draft. Note that these requirements may break or require rework of the current "multiple co-signaled member sets" solution in the draft. Regards Greg B. -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 10 Jan 2008 17:22:43 +0000 Message-ID: <4786541A.2070509@grotto-networking.com> Date: Thu, 10 Jan 2008 09:21:30 -0800 From: Greg Bernstein User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Huub van Helvoort CC: ccamp@ops.ietf.org Subject: Re: Moving forward with VCAT/LCAS... Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi Huub, I think you hit the crux of the issue. We (well I) outlined a possible solution to a particular "member sharing" scenario in the draft. Whether that is the right scenario and solution seems to be the discussion. See below for more comments. Cheers Greg B. Huub van Helvoort wrote: > Hello Greg, > > You wrote: > >> Hi CCAMPers, at the Vancouver meeting the status of the VCAT/LCAS >> draft was discussed and there seemed to be two possible additions to >> the requirements section of the draft. From the slide presentation >> these were: >> >> (a) Be able to set up member LSPs (and data plane LSPs -- server >> connections) prior to creation of VCG (Virtual Concatenation Group). > > If there are more such members would they have a relation with > each other? e.g. a "pool" of member LSPs for a single VCG or for > multiple VCGs that exist between the same end-points. --> The solution that we (okay I'll take the blame) outlined in the draft assumes that we know ahead of time that we are going to do such a thing and we setup a "call" that can contain multiple VCGs and then can throw all the "pool LSPs" into that call to be shared amongst the different VCGs under control of a modified Notify message (we didn't furnish details, just sketched how this could be done if someone really wanted to do this...) Some folks find the notion of multiple VCGs per call somewhat objectionable... > >> (b) “Member” LSPs (data plane and control plane) can exist after a >> VCG using them has been removed. > > Will they be returned to the "pool" (if the previous answer is yes). --> I don't know. I guess that they could be used for other things. In the member sharing case that we (okay I) outlined in the draft they could be either returned to the pool or torn down (i.e. the pool size could change). > >> For those interested in VCAT/LCAS what is your opinion on these >> additional requirements? This is a WG draft so polling of the list is >> required (right Adrian?). I'll clean up the language if there is a >> desire to add these to the current draft. Note that these >> requirements may break or require rework of the current "multiple >> co-signaled member sets" solution in the draft. > > Cheers, Huub. > -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 10 Jan 2008 16:57:54 +0000 Message-ID: <47864E2C.9090606@chello.nl> Date: Thu, 10 Jan 2008 17:56:12 +0100 From: Huub van Helvoort User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Greg Bernstein CC: ccamp@ops.ietf.org Subject: Re: Moving forward with VCAT/LCAS... Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hello Greg, You wrote: > Hi CCAMPers, at the Vancouver meeting the status of the VCAT/LCAS > draft was discussed and there seemed to be two possible additions to > the requirements section of the draft. From the slide presentation > these were: > > (a) Be able to set up member LSPs (and data plane LSPs -- server > connections) prior to creation of VCG (Virtual Concatenation Group). If there are more such members would they have a relation with each other? e.g. a "pool" of member LSPs for a single VCG or for multiple VCGs that exist between the same end-points. > (b) “Member” LSPs (data plane and control plane) can exist after a > VCG using them has been removed. Will they be returned to the "pool" (if the previous answer is yes). > For those interested in VCAT/LCAS what is your opinion on these > additional requirements? This is a WG draft so polling of the list is > required (right Adrian?). I'll clean up the language if there is a > desire to add these to the current draft. Note that these > requirements may break or require rework of the current "multiple > co-signaled member sets" solution in the draft. Cheers, Huub. -- ================================================================ http://www.van-helvoort.eu/ ================================================================ Always remember that you are unique...just like everyone else... Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 10 Jan 2008 15:06: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: Moving forward with VCAT/LCAS... Date: Thu, 10 Jan 2008 10:04:55 -0500 Message-ID: <29D15BBCA340DA4D8146D38B4924FC7A10C79C24@zcarhxm0.corp.nortel.com> Thread-Topic: Moving forward with VCAT/LCAS... Thread-Index: AchSHZqOG/WxMonCTbua4PzOpcZPfwBen43g From: "Stephen Shew" To: Greg, I support these requirements. In transport architecture, layers are separated and this allows a business separation of service. The relationship between the client layer (VCAT in this case) and server layer should be policy driven. That is, the setup/teardown of server layer LSPs in response to client layer requests, should not be automatically coded in a protocol/implementation, but be subject to a policy decision. An additional requirement that's similar to (a), would be to be able to use an existing LSP in response to a VCAT setup. Stephen -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Greg Bernstein Sent: January 8, 2008 12:28 To: ccamp@ops.ietf.org Subject: Moving forward with VCAT/LCAS... Hi CCAMPers, at the Vancouver meeting the status of the VCAT/LCAS draft was discussed and there seemed to be two possible additions to the requirements section of the draft. From the slide presentation these were: (a) Be able to set up member LSPs (and data plane LSPs -- server connections) prior to creation of VCG (Virtual Concatenation Group). (b) "Member" LSPs (data plane and control plane) can exist after a VCG using them has been removed. For those interested in VCAT/LCAS what is your opinion on these additional requirements? This is a WG draft so polling of the list is required (right Adrian?). I'll clean up the language if there is a desire to add these to the current draft. Note that these requirements may break or require rework of the current "multiple co-signaled member sets" solution in the draft. Regards Greg B. -- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=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 Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 10 Jan 2008 11:17:51 +0000 Message-ID: <047701c8537a$206c67b0$0200a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "Ross Callon" , , "Scott Bradner" Subject: Draft liaison response to ITU-T on T-MPLS ring protection Date: Thu, 10 Jan 2008 11:14:56 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit Hi, Here is a brief draft response to the ITU-T's liaison that you can see at https://datatracker.ietf.org/documents/LIAISON/file502.pdf Any comments? Thanks, Adrian === To: ITU-T Q9/15 Cc: Steven Trowbridge, Ghani Abbas, Ross Callon, Dave Ward, Scott Bradner, CCAMP Mailing List From: IETF CCAMP Working Group Subject: Response to Your Liaison on T-MPLS Ring Protection In Response Dear Ghani, Thank you for your liaison from your Madeira interim meeting on T-MPLS Ring Protection, and for taking the time to keep us informed. At the moment, it appears that your work is limited to the MPLS forwarding plane with control from the Management Plane with coordination with MPLS OAM. As such, this work falls within the remit of the IETF's MPLS and PWE3 working groups. You will also be aware that the IAB has set up a design team to address issues in preparation of the potential cooperation between IETF and ITU-T on T-MPLS; we trust that you have appropriately consulted this team in keeping with the spirit of cooperation between the ITU-T and the IETF. At such time as your work on T-MPLS ring protection (or indeed on any aspect of T-MPLS) extends to requirements or solutions for a control plane, we request that you communicate with us early in the process so that we may ensure that the industry arrives at a single and fully compatible solution. Best regards, Adrian Farrel and Deborah Brungard IETF CCAMP Working Group Co-Chairs Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 10 Jan 2008 09:31:31 +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: Moving forward with VCAT/LCAS... Date: Thu, 10 Jan 2008 10:28:24 +0100 Message-ID: <0428AC48A879ED46A94F39D5665DF684F524E2@esealmw110.eemea.ericsson.se> Thread-Topic: Moving forward with VCAT/LCAS... Thread-Index: AchSHPxCI0PYTObSTnyeKGOcZZyK4wBThRtA From: "Diego Caviglia" To: "Greg Bernstein" , Hi Greg, I think are good requirements and should be included on the ID = may be not as mandatory requirements. BR Diego > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On = Behalf > Of Greg Bernstein > Sent: marted=EC 8 gennaio 2008 18.28 > To: ccamp@ops.ietf.org > Subject: Moving forward with VCAT/LCAS... >=20 > Hi CCAMPers, at the Vancouver meeting the status of the VCAT/LCAS = draft > was discussed and there seemed to be two possible additions to the > requirements section of the draft. From the slide presentation these = were: >=20 > (a) Be able to set up member LSPs (and data plane LSPs -- server > connections) prior to creation of VCG (Virtual Concatenation Group). > (b) "Member" LSPs (data plane and control plane) can exist after a VCG > using them has been removed. >=20 > For those interested in VCAT/LCAS what is your opinion on these > additional requirements? This is a WG draft so polling of the list is > required (right Adrian?). I'll clean up the language if there is a > desire to add these to the current draft. Note that these requirements > may break or require rework of the current "multiple co-signaled = member > sets" solution in the draft. >=20 > Regards >=20 > Greg B. >=20 > -- > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D > Dr Greg Bernstein, Grotto Networking (510) 573-2237 >=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 08 Jan 2008 19:24:37 +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: Moving forward with VCAT/LCAS... Date: Tue, 8 Jan 2008 14:23:17 -0500 Message-ID: <23F9E58A916663488B3D12D1FE1A999FBD49D8@mdmxm03.ciena.com> Thread-Topic: Moving forward with VCAT/LCAS... Thread-Index: AchSHHTQqCBIuQQmTUWQvXnCNtXMZQAD12Xg From: "Ong, Lyndon" To: "Greg Bernstein" , Hi Greg, As you might expect, I support adding these as requirements for the VCAT/LCAS work. Cheers, Lyndon=20 -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Greg Bernstein Sent: Tuesday, January 08, 2008 9:28 AM To: ccamp@ops.ietf.org Subject: Moving forward with VCAT/LCAS... Hi CCAMPers, at the Vancouver meeting the status of the VCAT/LCAS draft was discussed and there seemed to be two possible additions to the requirements section of the draft. From the slide presentation these were: (a) Be able to set up member LSPs (and data plane LSPs -- server connections) prior to creation of VCG (Virtual Concatenation Group). (b) "Member" LSPs (data plane and control plane) can exist after a VCG using them has been removed. For those interested in VCAT/LCAS what is your opinion on these additional requirements? This is a WG draft so polling of the list is required (right Adrian?). I'll clean up the language if there is a desire to add these to the current draft. Note that these requirements may break or require rework of the current "multiple co-signaled member sets" solution in the draft. Regards Greg B. -- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=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 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 08 Jan 2008 17:29:58 +0000 Message-ID: <4783B29F.2010405@grotto-networking.com> Date: Tue, 08 Jan 2008 09:27:59 -0800 From: Greg Bernstein User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: ccamp@ops.ietf.org Subject: Moving forward with VCAT/LCAS... Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi CCAMPers, at the Vancouver meeting the status of the VCAT/LCAS draft was discussed and there seemed to be two possible additions to the requirements section of the draft. From the slide presentation these were: (a) Be able to set up member LSPs (and data plane LSPs -- server connections) prior to creation of VCG (Virtual Concatenation Group). (b) “Member” LSPs (data plane and control plane) can exist after a VCG using them has been removed. For those interested in VCAT/LCAS what is your opinion on these additional requirements? This is a WG draft so polling of the list is required (right Adrian?). I'll clean up the language if there is a desire to add these to the current draft. Note that these requirements may break or require rework of the current "multiple co-signaled member sets" solution in the draft. Regards Greg B. -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 07 Jan 2008 15:48:35 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Mon, 07 Jan 2008 10:45:16 -0500 Subject: Re: ccamp minutes From: JP Vasseur To: "BRUNGARD, DEBORAH A, ATTLABS" , Message-ID: Thread-Topic: ccamp minutes Thread-Index: AchL3LavtAcbaFe7SBuEfoCOVPhztQACaSHQAVd8R4A= Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3282547517_729358" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3297; t=1199720740; x=1200584740; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20ccamp=20minutes |Sender:=20 |To:=20=22BRUNGARD,=20DEBORAH=20A,=20ATTLABS=22=20,=20; bh=ZUYjEtq8jYJ6CfGJ2gqjK6hqR6j8Qfv9RjntkycdrHk=; b=ya6tzQNLLAyWT6YhBJhIgaBd2IjZB4cULV5pBEtMYqlgT3jDOfGE+oKOkQ TMRdnz+KW/A8BTbPtETDx+D2XzI/zuOhcSYwDMOZVl2b3JJQG6jJd9fnEYow PtO+Wfl51N; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3282547517_729358 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hi, From: "BRUNGARD, DEBORAH A, ATTLABS" Date: Mon, 31 Dec 2007 14:54:07 -0500 To: Conversation: ccamp minutes Subject: RE: ccamp minutes Try this version - there were an excessive number of typos introduced in the other uploaded version: http://www3.ietf.org/proceedings/07dec/minutes/ccamp.txt And thanks to our note takers - Dimitri, Martin, and Dan! From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of BRUNGARD, DEBORAH A, ATTLABS Sent: Monday, December 31, 2007 1:41 PM To: ccamp@ops.ietf.org Subject: ccamp minutes Hi CCAMP, The minutes have been uploaded: http://www3.ietf.org/proceedings/07dec/minutes/ccamp.htm Let us know if any changes/additions. Happy 2008! Adrian and Deborah --B_3282547517_729358 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Re: ccamp minutes Hi,

From: "BRUNGARD, DEBORAH = A, ATTLABS" <dbrungard@att.com>
Date: Mon, 31 Dec 2007 14:54:07 -0500
To: <ccamp@ops.ietf.org>
Conversation: ccamp minutes
Subject: RE: ccamp minutes

Try this version - there were an excessive number of typos introd= uced in the other uploaded version:
http://w= ww3.ietf.org/proceedings/07dec/minutes/ccamp.txt
And thanks to our note take= rs - Dimitri, Martin, and Dan!

From:<= /B> owner-ccamp@ops.ietf.org [mai= lto:owner-ccamp@ops.ietf.org] On Behalf Of BRUNGARD, DEBORAH A, A= TTLABS
Sent: Monday, December 31, 2007 1:41 PM
To: ccamp@ops.ietf.org
Subject: ccamp minutes

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

--B_3282547517_729358-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 03 Jan 2008 11:34:54 +0000 Message-ID: <00a001c84dfc$82bb27e0$0200a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: , "Ross Callon" , , "Brungard, Deborah A, ALABS" , Subject: Response to Your Questions about GMPLS Protocol Usage Date: Thu, 3 Jan 2008 11:33:44 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Dear Lyndon, Thanks for your communication dated 29th November 2007 and your subsequent email exchange with clarifications. Please find below responses from CCAMP experts to the questions you posed. May we take this opportunity to stress that we are open to receiving such questions in a less formal way either directly or through the CCAMP mailing list, and may be able to provide timely responses during the course of your testing events. > 1) One of the features provided in the OIF UNI 2.0 is the ability to > non-disruptively modify service attributes associated with an LSP. The > modification of the service attributes is limited to LSPs that were > initiated using Shared Explicit filter style. Modification is performed > by signaling a new LSP that utilizes the same Tunnel ID as the original > LSP but with the new service parameters. Once the new LSP state is > established, the original LSP state is removed. There are two distinct options for modifying an LSP. The first is "in-place" modification where a new trigger Path message is sent for an existing LSP. The second is the "make-before-break" approach to tunnel/service modification first introduced in RFC 3209. You appear to be referring to the latter case since you mention a new LSP. > Non-disruptive modification was demonstrated in the 2007 > interoperability test by modifying the bandwidth of an LSP realized by a > SONET/SDH VCAT group. In the process of testing, a number of questions > arose regarding the RESV message flow. These questions included: > > - How many RESV messages are expected to be generated? Is it one since > the resources in use by both LSPs are the same, or two since the LSPs > are handled through separate signaling sessions. In make-before-break, each LSP is signaled independently. Per LSP Resv messages should be expected. Assuming the old LSP is in-place at the time of signaling the new LSP, and only one Path message is issued, then only one Resv would be expected. That is, a Resv for the new LSP, but no further Resv for the existing LSP. When the old LSP is also modified as part of the make-before-break, e.g., to update administrative status prior to alarm-free tear-down, then a Resv message on the old LSP may also be generated. > - What is the bandwidth amount that should be reflected in the RESV > messages? If separate RESV messages are generated for both LSPs, is it > the bandwidth requested in the corresponding PATH message? Or is it > the actual bandwidth being provided by the connection at the time the > RESV message is generated? According to RFC 4606: For a particular sender in a session, the contents of the FLOWSPEC object received in a Resv message SHOULD be identical to the contents of the SENDER_TSPEC object received in the corresponding Path message. If the objects do not match, a ResvErr message with a "Traffic Control Error/Bad Flowspec value" error SHOULD be generated. Again, in make-before-break, each LSP is signaled independently. > In the interop test both approaches were observed. To facilitate the > subsequent demonstration, receivers were expected to handle both cases. > > 2) In the process of testing, we found that not all implementations > included Explicit Route Objects (ERO) in PATH messages when performing > graceful deletion, even though earlier PATH messages for the LSP had > included an ERO. For some intermediate node implementations, the lack of > the ERO was seen as removing the 'pinned' nature of the connection, > causing the node to interpret the PATH message as requiring a new path > computation which may end up using a different route. Other > implementations utilized the Session and Sender Template to relate the > received PATH message with the existing connection thereby identifying > the path the message should be forwarded on. This approach was taken by > these implementations since inclusion of an ERO is not mandatory. We > would appreciate CCAMP's thoughts on what the behavior should be. As described in RFC 2205, Path and Resv messages are idempotent. This means that any Path message reflects full state, and differences between one Path message and a subsequent Path message may be reasonably considered an explicit change. Therefore, while there is no explicit requirement stated in RFC 3473, it is typical to only modify the Admin Status Object in Path messages sent in connection to RFC 3473 section 7.2.1. deletion procedures (i.e. to include the full ERO as on previous Path messages). It may be observed, however, that while an implementation detecting a change in ERO (such as the removal of the ERO) may legitimately opt to reroute, that implementation should also note the change in Admin Status associated with the graceful deletion and may "assume" that such a reroute would be a waste of time. Further, in a transport system, implementations should only perform local reroutes (deviating from in-place LSPs) with extreme caution since these risk impacting traffic. > 3) In the process of testing, we found cases where the update of a > link's attributes (i.e. available capacity) was not being done by > advertising an updated LSA using the same LSAid, but by flushing the old > LSA followed by generation of a new LSA with a new LSAid. Since the > LSAid for Opaque LSAs is not tied to the resource being advertised > (i.e. the resource is identified using TLVs in the Opaque LSA, not using > the LSAid as is done with IPv4 OSPF LSAs), this can cause a problem as > it causes the order that the LSAs are processed to become important. We > would appreciate CCAMP's thoughts on what the behavior should be. The OSPF WG, is the proper WG to respond to this as they are the authoritative source on OSPF technology. From our perspective, RFC 2328 dictates the use of the same Link State ID when advertising a change in information about a link, and RFC 3630 states "The LSA ID has no topological significance." While it is certainly possible to advertise a change via issuing an LSA with a new Link State ID and flushing old state, from the perspective of OSPF this is not a change in link state, rather a completely new link. In fact, when there are key changes to the information advertised about a link (for example, a change to the Link Type or Link ID), the advertising router should recognise that these changes represent the advertisement of a new link and should use a new LSA with a new Link State ID. However, where the change is clearly a change to the link state of an existing link, the advertising router should use the same Link State ID. > 4) Finally, in the process of testing, we found cases where established > connections were deleted based on node restart procedures in RFC > 3473. R163 of the OIF Carrier requirements (liaised to IETF in 12/2006) > states deletion of established connections as the result of control > plane failure (including node restart) shall not occur. It has been > identified this could also occur when a number of cascaded nodes restart > at the same time. We would appreciate CCAMP's thoughts on ways to > prevent deletion of established connections from occurring when a node > restarts. Without specific details, it's impossible to address the found cases or to identify if they were due to implementation or specification issues. More broadly, RFC 3473 does not require the removal of forwarding state, even in the case of state synchronization errors, and implementations may take different action (such as reporting the condition to a management station). An implementation at a restarting node may consider that the lack of control plane state at its (fully functional) neighbor indicates that the removal of forwarding plane state has been attempted through the control plane while the restarting node was down and should follow local policy in determining how to react. We would also like to direct you to RFC 5063 and draft-ietf-ccamp-gr-description which may provide additional relevant information. We hope this addresses your questions. Best regards, Adrian Farrel and Deborah Brungard IETF CCAMP working group co-chairs Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 03 Jan 2008 11:26:09 +0000 Message-ID: <008901c84dfb$266d0c70$0200a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Greg Bernstein" , Subject: Re: WSON framework draft and ccamp minutes Date: Thu, 3 Jan 2008 11:24:01 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Hi Greg, >> "a. Framework (Greg 10, 65/120) >> Adrian: Who thinks that the WSON is relevant to us? Not a unanimous show >> of hands, >> but still a good show of hands. We will go to list to see if this is the >> right draft >> for the framework." > > If I recall there was also no opposition to the framework moving forward > as a working group draft. However, > proper procedures require that we always ask the question on the list > (right?). Do the chairs then poll the CCAMP list or > do I as an author? The chairs. In due course (i.e., when they dig out of the snow) Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 02 Jan 2008 16:23:58 +0000 Message-ID: <477BB9FB.2010101@grotto-networking.com> Date: Wed, 02 Jan 2008 09:21:15 -0700 From: Greg Bernstein User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: ccamp@ops.ietf.org Subject: WSON framework draft and ccamp minutes Content-Type: multipart/alternative; boundary="------------010006040202010502050906" This is a multi-part message in MIME format. --------------010006040202010502050906 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Happy 2008, Adrian, Deborah and CCAMP. The meeting minutes said: > Try this version - there were an excessive number of typos introduced > in the other uploaded version: > http://www3.ietf.org/proceedings/07dec/minutes/ccamp.txt > "a. Framework (Greg 10, 65/120) Adrian: Who thinks that the WSON is relevant to us? Not a unanimous show of hands, but still a good show of hands. We will go to list to see if this is the right draft for the framework." If I recall there was also no opposition to the framework moving forward as a working group draft. However, proper procedures require that we always ask the question on the list (right?). Do the chairs then poll the CCAMP list or do I as an author? In either case the formal question is the whether the WSON Framework draft http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-switched-02.txt should be adopted as a working group document. The document is aligned with the CCAMP charter, hits an area that GMPLS was originally intended to cover, and covers subsystems and processes currently used in industry but desiring GMPLS automation and restoration. Hence I hope that the support on the list for this draft becoming a WG document is as strong as the support we saw at the Vancouver meeting. Regards Greg B. -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 --------------010006040202010502050906 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Happy 2008, Adrian, Deborah and CCAMP.  The meeting minutes said:
Try this version - there were an excessive number of typos introduced in the other uploaded version:

"a. Framework (Greg 10, 65/120)
Adrian: Who thinks that the WSON is relevant to us?  Not a unanimous show of hands,
but still a good show of hands. We will go to list to see if this is the right draft
for the framework."

If I recall there was also no opposition to the framework moving forward as a working group draft.  However, 
proper procedures require that we always ask the question on the list (right?). Do the chairs then poll the CCAMP list or 
do I as an author?

In either case the formal question is the whether the WSON Framework draft 
http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-switched-02.txt
should be adopted as a working group document. 

The document is aligned with the CCAMP charter, hits an area that GMPLS was originally intended to cover, and covers subsystems and processes currently used in industry but desiring GMPLS automation and restoration. Hence I hope that the support on the list for this draft becoming a WG document is as strong as the support we saw at the Vancouver meeting.

Regards

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